LOR sleepq/scrlock

[John Baldwin]

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