ppp triggers GPF panic

[Lawrence Stewart]

Stefan Bethke wrote:
> Am 11.07.2009 um 20:44 schrieb Lawrence Stewart:
> 
>> Stefan Bethke wrote:
>>> Yesterday's -current, amd64, C2D, 4 GB RAM. Full dmesg below.
>>> Fatal trap 9: general protection fault while in kernel mode
>>> cpuid = 0; apic id = 00
>>> instruction pointer    = 0x20:0xffffffff802fc2ce
>>> stack pointer            = 0x28:0xffffff8000037b10
>>> frame pointer            = 0x28:0xffffff8000037b30
>>> code segment        = base 0x0, limit 0xfffff, type 0x1b
>>>            = DPL 0, pres 1, long 1, def32 0, gran 1
>>> processor eflags    = interrupt enabled, resume, IOPL = 0
>>> current process        = 12 (swi1: netisr 0)
>>> [thread pid 12 tid 100007 ]
>>> Stopped at      _mtx_lock_sleep+0x4e:   movl    0x288(%rcx),%esi
>>> Didn't capture anything else there.  This happened when my ADSL link 
>>> was forced down (24h connection reset).
>>> After fixing the file system (UFS2 + softupdates on /), I got another 
>>> "panic: spin lock held too long" on rebooting.
>>> Then, the GPF panic happened again as ppp was trying to establish the 
>>> connection:
>>
>> 1. Do you have a crash dump?
> 
> Unfortunatly not.
> 
>> 2. Can you try find a sequence of events to deterministically 
>> reproduce this?
> 
> Not if I can help it, this is my main gateway at home.  Sorry.  But I'll 
> try collect as much info as possible if and when it happens again.

You can set debug.debugger_on_panic=0 in /etc/sysctl.conf which will 
make the system automatically dump core and reset instead of sitting at 
the ddb prompt. Alternatively, run "call doadump" from the ddb prompt 
followed by "reset" and that should also get you a usable core file. I'd 
suggest the first option for you though given you don't like the machine 
being down. Let us know if/when it happens again, but without a core 
file there's not much we can help with.

Cheers,
Lawrence