Panic when logging out from serial console

Eirik Øverby ltning at anduin.net
Wed Jul 20 11:30:22 GMT 2005


On Apr 10, 2005, at 1:42 PM, Robert Watson wrote:

>
> On Sun, 10 Apr 2005 ltning at anduin.net wrote:
>
>
>> warning: This report might be somewhat vague. For quite a while  
>> now I`ve been plagued with the problem that logging out from a  
>> serial console causes the box to panic. For a while I`ve been sure  
>> this was isolated to one of my boxen, because it`s been acting up  
>> in other ways as well, but today it happened on two other boxes  
>> too! And these boxes have been rock stable for the last two years.
>>
>> I`m running a fairly recent variation of RELENG-5 on all the  
>> boxes; one of them is amd64, the two others - including the one  
>> I`ve pasted from - are plain old p3 machines. They are all dual- 
>> CPU though.
>>
>
> I've seen precisely this panic -- in fact, I saw it yesterday on a  
> RELENG_5 box, and under identical circumstances -- it looks like it  
> happens if a last process in a login session on a serial console  
> closes the tty, and then getty re-opens it while there's console  
> output coming from syslog.  I was able to get a core dump, but  
> haven't made much headway on it yet.  It looks like the tty  
> structure has been released -- the refcount on the tty is 0, and  
> the mutex pointers in the kqueue state have been cleared (hence the  
> null pointer dereference you see).  Now, the question is why --  
> I've added some debugging output to the local box I saw it on, and  
> will see if I can reproduce it.

Did you ever manage to reproduce - or fix - this? I had a rather  
nasty incident recently due to this, even on a very recently updated  
5.4. I sent a message to stable@ about it a few days ago, but have  
received no response.

I personally think that this must be very very (very) bad - serial  
consoles shouldn't do this! ;)

/Eirik


>
> Robert N M Watson
>
>
>>
>> I have no clue what I can do from here; has anyone seen this  
>> before? I can`t
>> always reproduce it, but the risk is fairly high - around 33% I`d  
>> say.
>>
>> Anyone?
>>
>> Thanks for your attention, details below.
>>
>> Fatal trap 12: page fault while in kernel mode
>> cpuid = 1; apic id = 00
>> fault virtual address   = 0x1c
>> fault code              = supervisor write, page not present
>> instruction pointer     = 0x8:0xc0620b5f
>> stack pointer           = 0x10:0xdadbd988
>> frame pointer           = 0x10:0xdadbd994
>> code segment            = base 0x0, limit 0xfffff, type 0x1b
>>                        = DPL 0, pres 1, def32 1, gran 1
>> processor eflags        = interrupt enabled, resume, IOPL = 0
>> current process         = 51999 (getty)
>> trap number             = 12
>> panic: page fault
>> cpuid = 1
>> boot() called on cpu#0
>> Uptime: 66d11h24m50s
>>
>>
>>
>> /Eirik
>>
>> ----------------------------------------------------------------
>> This message was sent using IMP, the Internet Messaging Program.
>>
>> _______________________________________________
>> freebsd-stable at freebsd.org mailing list
>> http://lists.freebsd.org/mailman/listinfo/freebsd-stable
>> To unsubscribe, send any mail to "freebsd-stable- 
>> unsubscribe at freebsd.org"
>>
>>
>
>



More information about the freebsd-stable mailing list