cvs commit: src/sys/i386/i386 vm_machdep.c
nate at root.org
Wed Dec 15 11:59:36 PST 2004
John Baldwin wrote:
> On Tuesday 14 December 2004 07:10 pm, Kris Kennaway wrote:
>>On Tue, Dec 14, 2004 at 02:55:00PM -0800, Nate Lawson wrote:
>>>>Erm, well, that's not always easy since sometimes when you panic you
>>>>can't talk to the other CPUs for whatever reason. Putting back the
>>>>proxy reset doesn't hurt for now but does restore functionality in at
>>>>least some cases. I'd rather have that then certain hard panics not
>>>>get into ddb because we couldn't get onto the BSP to run ddb.
>>>Perhaps you could give me some pointers on what is counted on to be
>>>working when panic() is called? I can't come up with a situation where
>>>the proxy code couldn't be used upon entry to ddb. If there were any
>>>cases like this, the proxy code wouldn't work for cpu_reset() either.
>>>Also, in such a case, it's hard to see how ddb could be usable since it
>>>tries to stop other processors, which requires similar code to the proxy.
>>>Or in other words, if you have enough capability to call panic() or
>>>break to ddb, then you have enough resources to do an IPI and get onto
>>NB: DDB often isn't usable on SMP machines thesedays, and will hang
>>when a panic tries to enter it.
> Try debug.kdb.stop_cpus=0 (sysctl and tunable) to prevent KDB from trying to
> stop the other CPUs. Another possible fix that ups@ has talked about is
> changing IPI_STOP to use an NMI rather than a vector (you can send NMI IPIs
> via the local APIC) so that IPI_STOP is more reliable.
That would be excellent. If that was implemented, would it be
acceptable then to stop the cpus while entering ddb or on panic? I
think it would be reliable enough to always do this.
More information about the cvs-all