cvs commit: src/sys/i386/i386 vm_machdep.c

[Nate Lawson]

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
>>>the BSP.
>>
>>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.

-- 
Nate