Re: [PANIC] after manually issuing 'ifconfig sf0'

On Thursday, December 02, 2010 2:44:00 pm David O'Brien wrote:
> Machine booted, without any mention of sf(4) in rc.conf or loader.conf and
> without sf(4) in the core kernel.  This is without WITNESS or INVARIANTS.
> 
> >From multi-user, I issued 'ifconfig sf0' and got the below panic.
> These are the console messages related to this:
> 
> 
> FreeBSD 9.0-CURRENT #654 r215604M: Sat Nov 20 19:51:27 PST 2010
>     rootk_at_dragon:/sys/i386/compile/DRAGON i386
> [..]
> Thu Dec  2 09:33:50 PST 2010
> sf0: <Adaptec ANA-62044 (rev 1) 10/100BaseTX> port 0x5000-0x50ff mem 0xb0400000-0xb047ffff irq 19 at device 4.0 on pci5
> miibus2: <MII bus> on sf0
> ukphy0: <Generic IEEE 802.3u media interface> PHY 1 on miibus2
> ukphy0:  10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto
> sf0: Ethernet address: 00:00:d1:ed:81:95
> sf1: <Adaptec ANA-62044 (rev 1) 10/100BaseTX> port 0x5400-0x54ff mem 0xb0480000-0xb04fffff irq 16 at device 5.0 on pci5
> miibus3: <MII bus> on sf1
> ukphy1: <Generic IEEE 802.3u media interface> PHY 1 on miibus3
> ukphy1:  10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto
> sf1: Ethernet address: 00:00:d1:ed:81:96
> sf2: <Adaptec ANA-62044 (rev 1) 10/100BaseTX> port 0x5800-0x58ff mem 0xb0500000-0xb057ffff irq 18 at device 6.0 on pci5
> miibus4: <MII bus> on sf2
> ukphy2: <Generic IEEE 802.3u media interface> PHY 1 on miibus4
> ukphy2:  10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto
> sf2: Ethernet address: 00:00:d1:ed:81:97
> sf3: <Adaptec ANA-62044 (rev 1) 10/100BaseTX> port 0x5c00-0x5cff mem 0xb0580000-0xb05fffff irq 17 at device 7.0 on pci5
> miibus5: <MII bus> on sf3
> ukphy3: <Generic IEEE 802.3u media interface> PHY 1 on miibus5
> ukphy3:  10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto
> sf3: Ethernet address: 00:00:d1:ed:81:98
> 
> 
> Fatal trap 12: page fault while in kernel mode
> cpuid = 0; apic id = 00
> fault virtual address	= 0x238
> fault code		= supervisor read, page not present
> instruction pointer	= 0x20:0xc05be315
> stack pointer	        = 0x28:0xe7a5eab4
> frame pointer	        = 0x28:0xe7a5eaf4
> 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		= 2590 (mail.local)
> trap number		= 12
> panic: page fault
> cpuid = 0
> KDB: stack backtrace:
> db_trace_self_wrapper(c0839222,d31206e,2c66000a,70797420,78302065,...) at 0xc04e9ab6 = db_trace_self_wrapper+0x26
> kdb_backtrace(c0857e2a,0,c0822eb2,e7a5e910,0,...) at 0xc05fa2fa = kdb_backtrace+0x2a
> panic(c0822eb2,c0858b68,c59aea18,1,1,...) at 0xc05cd297 = panic+0x117
> trap_fatal(c596d880,0,c0858a20,36b,238,...) at 0xc07dcd65 = trap_fatal+0x325
> trap_pfault(e7a5e9b8,c07fae4d,e7a5e9cc,0,c59ae870,...) at 0xc07dcf40 = trap_pfault+0x1c0
> trap(e7a5ea74) at 0xc07dd5f5 = trap+0x5d5
> calltrap() at 0xc07c8dfc = calltrap+0x6
> --- trap 0xc, eip = 0xc05be315, esp = 0xe7a5eab4, ebp = 0xe7a5eaf4 ---
> _mtx_lock_sleep(c51b8be8,c59ae870,0,c08501a2,a43,...) at 0xc05be315 = _mtx_lock_sleep+0xa5

Doing 'l *_mtx_lock_sleep+0xa5' in gdb of your kernel.debug would be useful.
x/i of the same address would also be useful.  I'm guessing that mtx_lock was
set to something bogus.

-- 
John Baldwin