Non-sleepable locks PANIC in sf(4)

[Pyun YongHyeon]

On Wed, Nov 10, 2010 at 04:32:54PM -0800, David O'Brien wrote:
> Script started on Wed Nov 10 15:56:31 2010
> FreeBSD 9.0-CURRENT #644 r215099M: Wed Nov 10 11:45:01 PST 2010
>     obrien at dragon:/usr/obj/4kib/i386/compile/DRAGON-WITNESS i386
> WARNING: WITNESS option enabled, expect reduced performance.
> WARNING: DIAGNOSTIC option enabled, expect reduced performance.
> [..]
> Setting hostname: dragon.NUXI.org.
> sf0: <Adaptec ANA-62044 (rev 1) 10/100BaseTX> port 0x8800-0x88ff mem 0xfa480000-0xfa4fffff irq 26 at device 4.0 on pci3
> miibus1: <MII bus> on sf0
> ukphy0: <Generic IEEE 802.3u media interface> PHY 1 on miibus1
> 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 0x8400-0x84ff mem 0xfa380000-0xfa3fffff irq 27 at device 5.0 on pci3
> miibus2: <MII bus> on sf1
> ukphy1: <Generic IEEE 802.3u media interface> PHY 1 on miibus2
> 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 0x8000-0x80ff mem 0xfa300000-0xfa37ffff irq 24 at device 6.0 on pci3
> miibus3: <MII bus> on sf2
> ukphy2: <Generic IEEE 802.3u media interface> PHY 1 on miibus3
> 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 0x7800-0x78ff mem 0xfa200000-0xfa27ffff irq 25 at device 7.0 on pci3
> miibus4: <MII bus> on sf3
> ukphy3: <Generic IEEE 802.3u media interface> PHY 1 on miibus4
> ukphy3:  10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto
> sf3: Ethernet address: 00:00:d1:ed:81:98
> Expensive timeout(9) function: 0xc061b270(0xc65965a0) 1.987919972 s
> [..]
> Starting Network: lo0 bge0 sf0 em0.
> [..]
> sf0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
> 	options=b<RXCSUM,TXCSUM,VLAN_MTU>
> 	ether 00:00:d1:ed:81:95
> 	inet 74.95.12.85 netmask 0xfffffffc broadcast 74.95.12.87
> 	inet6 fe80::200:d1ff:feed:8195%sf0 prefixlen 64 tentative scopeid 0x5 
> 	nd6 options=29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL>
> 	media: Ethernet autoselect (100baseTX <full-duplex>)
> 	status: active
> [..]
> Kernel page fault with the following non-sleepable locks held:
> exclusive sleep mutex sf0 (network driver) r = 0 (0xc722b584) locked @ /usr/obj/4kib/modules/sf/../../dev/sf/if_sf.c:1862
> KDB: stack backtrace:
> db_trace_self_wrapper(c08870ef,c6be8a80,4,c0a83ba0,c704164c,...) at 0xc04ed726 = db_trace_self_wrapper+0x26
> kdb_backtrace(746,0,ffffffff,c0a83b94,daaa2ac0,...) at 0xc061152a = kdb_backtrace+0x2a
> _witness_debugger(c08898ba,daaa2ad4,4,1,0,...) at 0xc0626256 = _witness_debugger+0x26
> witness_warn(5,0,c08b2265,246,c70415a0,...) at 0xc062776d = witness_warn+0x1fd
> trap(daaa2bac) at 0xc08214bd = trap+0x2ad
> calltrap() at 0xc080b93c = calltrap+0x6
> --- trap 0xc, eip = 0xc08077c4, esp = 0xdaaa2bec, ebp = 0xdaaa2c00 ---
> _bus_dmamap_sync(c6cbac80,c724a000,2,daaa2c28,daaa2c30,...) at 0xc08077c4 = _bus_dmamap_sync+0x54
> sf_newbuf(c722b584,4,c7223bbd,603,c06051d5,...) at 0xc7220173 = sf_newbuf+0xf3
> sf_intr(c722a000,c0947ec0,4,c0882361,c65d4238,...) at 0xc7221c48 = sf_intr+0x248
> intr_event_execute_handlers(c658f7f8,c65d4200,c087ef80,533,c65d4270,...) at 0xc05b47b5 = intr_event_execute_handlers+0x125
> ithread_loop(c65dd830,daaa2d28,c087ed0e,33b,c658f7f8,...) at 0xc05b55ac = ithread_loop+0xac
> fork_exit(c05b5500,c65dd830,daaa2d28) at 0xc05b24e8 = fork_exit+0xb8
> fork_trampoline() at 0xc080b9e4 = fork_trampoline+0x8
> --- trap 0, eip = 0, esp = 0xdaaa2d60, ebp = 0 ---
> 
> 
> Fatal trap 12: page fault while in kernel mode
> cpuid = 0; apic id = 00
> fault virtual address	= 0x400000c
> fault code		= supervisor read, page not present
> instruction pointer	= 0x20:0xc08077c4
> stack pointer	        = 0x28:0xdaaa2bec
> frame pointer	        = 0x28:0xdaaa2c00
> 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		= 12 (irq26: sf0)
> trap number		= 12
> panic: page fault
> cpuid = 0
> KDB: stack backtrace:
> db_trace_self_wrapper(c08870ef,d31206e,2c66000a,70797420,78302065,...) at 0xc04ed726 = db_trace_self_wrapper+0x26
> kdb_backtrace(c08b0bbd,0,c086c89f,daaa2a88,0,...) at 0xc061152a = kdb_backtrace+0x2a
> panic(c086c89f,c08b226c,c7041748,1,1,...) at 0xc05de537 = panic+0x117
> trap_fatal(5,0,c08b2265,246,c70415a0,...) at 0xc0820ee5 = trap_fatal+0x325
> trap(daaa2bac) at 0xc08214ce = trap+0x2be
> calltrap() at 0xc080b93c = calltrap+0x6
> --- trap 0xc, eip = 0xc08077c4, esp = 0xdaaa2bec, ebp = 0xdaaa2c00 ---
> _bus_dmamap_sync(c6cbac80,c724a000,2,daaa2c28,daaa2c30,...) at 0xc08077c4 = _bus_dmamap_sync+0x54
> sf_newbuf(c722b584,4,c7223bbd,603,c06051d5,...) at 0xc7220173 = sf_newbuf+0xf3
> sf_intr(c722a000,c0947ec0,4,c0882361,c65d4238,...) at 0xc7221c48 = sf_intr+0x248
> intr_event_execute_handlers(c658f7f8,c65d4200,c087ef80,533,c65d4270,...) at 0xc05b47b5 = intr_event_execute_handlers+0x125
> ithread_loop(c65dd830,daaa2d28,c087ed0e,33b,c658f7f8,...) at 0xc05b55ac = ithread_loop+0xac
> fork_exit(c05b5500,c65dd830,daaa2d28) at 0xc05b24e8 = fork_exit+0xb8
> fork_trampoline() at 0xc080b9e4 = fork_trampoline+0x8
> --- trap 0, eip = 0, esp = 0xdaaa2d60, ebp = 0 ---
> Uptime: 40s
> Physical memory: 3203 MB
> Dumping 116 MB: (CTRL-C to abort) panic: Trying sleep, but thread marked as sleeping prohibited
> cpuid = 0
> Uptime: 40s
> Automatic reboot in 15 seconds - press a key on the console to abort
> panic: Trying sleep, but thread marked as sleeping prohibited
> cpuid = 0
> Uptime: 40s
> Automatic reboot in 15 seconds - press a key on the console to abort
> panic: Trying sleep, but thread marked as sleeping prohibited
> cpuid = 0
> Uptime: 40s
> [EOT]
> Script done on Wed Nov 10 15:58:52 2010
> 
> thoughts?

Does sf(4) use shared interrupt?