ifconfig triggers kernel trap on boot

[Stefan Bethke]

Am 22.05.2009 um 13:53 schrieb Stefan Bethke:

> Am 22.05.2009 um 12:15 schrieb Daichi GOTO:
>
>> I have ifconfig(8) panic issue like you.
>>
>> With current, just do ifconfig(8) like follow leads panic.
>>
>> ifconfig re0 inet xxx.xxx.xxx.xxx netmask yyy.yyy.yyy.yyy
>>
>> I have tried on board re0 and attached fxp0, both have the
>> same result.
>>
>> Anyone has any ideas around these panic issues?   By my
>> little research, kernel/world up until to 12/05/2009 03:00
>> has no problem. At least, kernel/world at 19/05/2009 JST
>> has above panic issue.
>
> I've checked from single-user mode, and the panic is indeed  
> triggered by the address assignment.
>
> # sh ifc
> ifconfig bridge0ke inet 44.128.65.rn1/28
> + ifconfigel bridge0 inet 44 t.128.65.1/28
> rap 9 with interrupts disabled
>
>
> Fatal trap 9: general protection fault while in kernel mode
> cpuid = 0; apic id = 00
> instruction pointer	= 0x20:0xffffffff80323f5b
> stack pointer	        = 0x28:0xffffff8076524760
> frame pointer	        = 0x28:0xffffff8076524770
> code segment		= base 0x0, limit 0xfffff, type 0x1b
> 			= DPL 0, pres 1, long 1, def32 0, gran 1
> processor eflags	= resume, IOPL = 0
> current process		= 48 (ifconfig)
> [thread pid 48 tid 100056 ]
> Stopped at      turnstile_setowner+0x2b:        movq    %rcx, 
> 0x68(%rdx)
>
> A kernel compiled from the same sources with practically identical  
> configuration (GENERIC minus most devices) running inside VMware  
> (but also SMP) does not exhibit this issue.

Using the failing kernel in VMware triggers the same panic, so it does  
appear to be configuration dependant.  I'll see what's different  
between the two configs.


Stefan

-- 
Stefan Bethke <stb at lassitu.de>   Fon +49 151 14070811