Date: Thu, 10 Apr 2008 16:51:24 -0400 From: John Baldwin <jhb@freebsd.org> To: freebsd-stable@freebsd.org Cc: bzeeb+freebsd+lor@zabbadoz.net, Jurgen Weber <jurgen@ish.com.au> Subject: Re: LOR sleepq/scrlock Message-ID: <200804101651.24852.jhb@freebsd.org> In-Reply-To: <3DDEAB7E-F6FF-48C6-A19E-E6D96D365D8E@ish.com.au> References: <77E81AD6-FBCC-4D30-A5CB-A9B918D4793F@ish.com.au> <200804080959.46961.jhb@freebsd.org> <3DDEAB7E-F6FF-48C6-A19E-E6D96D365D8E@ish.com.au>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tuesday 08 April 2008 07:46:41 pm Aristedes Maniatis wrote: > > On 08/04/2008, at 11:59 PM, John Baldwin wrote: > > On Tuesday 08 April 2008 04:06:24 am Aristedes Maniatis wrote: > >> FreeBSD dash.ish.com.au 7.0-RELEASE FreeBSD 7.0-RELEASE #10 > >> i386 with PAE (5Gb RAM) > >> > >> > >> We've had fairly reproducible freezes. After several hours of stress > >> testing or even overnight not doing anything, everything locks up > >> including the console. > >> > >> We then installed a debugging kernel (without INVARIANTS since that > >> prevented the kernel from compiling at all) and obtained this LOR > >> when > >> it froze: > >> > >> LOR: > >> 1st 0x807d3d90 sleepq chain (sleepq chain) @/usr/src/sys/kern/ > >> subr_sleepqueue.c:773 > >> 2nd 0x807c8110 scrlock (scrlock) @/usr/src/sys/dev/syscons/syscons.c: > >> 2526 > >> > >> I have taken photographs of the KDB output following this but have > >> not > >> transcribed it until someone says that it will be useful to them. I > >> could put it up as slightly fuzzy screen photographs on our web site. > > > > The stack trace info would be useful. A photo would be fine. > > > > -- > > John Baldwin > > > Sorry for the quality, these were the best I could do with the camera > I had: > > http://www.ish.com.au/s/LOR/1.jpg > http://www.ish.com.au/s/LOR/2.jpg > http://www.ish.com.au/s/LOR/3.jpg (this overlaps with [2]) These are all garbage in kuickshow. :( > Do you have any hunch about what driver/system might be causing this? > Could it be related to the use of PAE? Because if so, I'd be happy to > leave this server accessible somewhere for FreeBSD developers to work > with and go replace it with a new 64bit system tomorrow for our > production use. Not PAE. If there was a panic or printf inside the kernel sleep queue code itself then you might get this LOR as a side effect, but the real problem would be the original panic or printf. -- John Baldwin
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200804101651.24852.jhb>