Date: Thu, 15 Jan 2009 17:05:06 -0500 From: John Baldwin <jhb@freebsd.org> To: Robert Watson <rwatson@freebsd.org> Cc: freebsd-stable@freebsd.org, drosih@rpi.edu, Pete French <petefrench@ticketswitch.com>, rblayzor.bulk@inoc.net Subject: Re: Big problems with 7.1 locking up :-( Message-ID: <200901151705.06989.jhb@freebsd.org> In-Reply-To: <alpine.BSF.2.00.0901151747461.45995@fledge.watson.org> References: <E1LNVsF-0000WG-0T@dilbert.ticketswitch.com> <alpine.BSF.2.00.0901151747461.45995@fledge.watson.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thursday 15 January 2009 12:49:11 pm Robert Watson wrote: > On Thu, 15 Jan 2009, Pete French wrote: > > >> desirable. You might want to give the NMI a test run just to make sure it > >> behaves as you think it should, though -- be aware that if DDB/KDB aren't > >> compiled into the kernel, then an NMI will panic the box. > > > > Unfortunately it does this... > > > > http://toybox.twisted.org.uk/~pete/71_nmi1.png > > > > That is locked up too - hitting return does nothing. I was hoping it was > > just garbled output but had actually gone to the debugger. Apparently not. > > > > Thats with a config file containing KDB, DDB and BREAK_TO_DEBUGGER, which > > does work as I have tested it with CTRL_ALT_ESC. > > Er, that's rather upsetting. John, do you have any ideas about this? The rest of the thread I have no context on still. The garbage is due to competing panics I think. The problem is we don't single thread the printf's in 'trap_fatal()'. We should probably have some sort of simple spin lock thing in the x86 code to only allow 1 CPU at a time to run through that routine. -- John Baldwin
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200901151705.06989.jhb>