Re: panic: _mtx_lock_sleep: recursed on non-recursive mutex em0 @ /usr/src/sys/dev/e1000/if_lem.c:881
* Garrett Cooper yaneg...@gmail.com [2012-07-28 18:43 -0400]: On Sat, Jul 28, 2012 at 2:41 PM, Arnaud Lacombe lacom...@gmail.com wrote: Close, but you missed a spot. The attached patch (based on your's) works, i.e. no longer panics at boot on my vbox instance. Thanks! FYI - The patch works for me as well, thank you! -- dave [ please don't CC me ] pgpj5dArvxxnE.pgp Description: PGP signature
Re: panic: _mtx_lock_sleep: recursed on non-recursive mutex em0 @ /usr/src/sys/dev/e1000/if_lem.c:881
Hi, On Fri, Jul 27, 2012 at 4:31 PM, Adrian Chadd adr...@freebsd.org wrote: It looks like a case of lock held during call up the stack. This is bad for so many reasons. It also makes writing correctly locked drivers a pain in the ass as the moment you unlock the driver before calling ether_input() / ieee80211_input(), you allow things to change state. So no, although you shouldn't use long-held locks to protect things, apparently this is all the rage. iwn(4) does this. ath(4) does not. I'm having a right painful time trying to fine-grain lock things. I'm at the point where I'm about to not care, rip out all the locks and replace with a single ATH_LOCK(). How would a single ATH_LOCK() helps here ? AFAICS, the panic seem to be a classical fallout from direct dispatch where you can re-enter the driver from the driver itself through the network stack. - Arnaud Adrian On 27 July 2012 11:47, Dimitry Andric d...@freebsd.org wrote: On 2012-07-26 17:46, David Wolfskill wrote: This is at r238795; cut/paste of backtrace: KDB: enter: panic [ thread pid 12 tid 100026 ] Stopped at kdb_enter+0x3d: movl$0,kdb_why db bt Tracing pid 12 tid 100026 td 0xc6755000 kdb_enter(c0f93c5f,c0f93c5f,c0f91e21,f08398f0,c1825c80,...) at kdb_enter+0x3d panic(c0f91e21,c66739a0,c0f20db8,371,c6755000,...) at panic+0x1c4 _mtx_lock_sleep(c68b8560,c6755000,c0f20db8,c0f20db8,371,...) at _mtx_lock_sleep+0x35e _mtx_lock_flags(c68b8560,0,c0f20db8,371,0,...) at _mtx_lock_flags+0xdb lem_start(c68ba000,0,c0fa806c,d20,2a,...) at lem_start+0x33 if_transmit(c68ba000,c93d9000,6,c6755000,c65da588,...) at if_transmit+0x129 ether_output(c68ba000,c93d9000,f0839aa4,0,0,...) at ether_output+0x5df arpintr(c93d9000,8,c0f50314,153,0,...) at arpintr+0x108c netisr_dispatch_src(7,0,c93d9000,c93d9000,c68ba000,c93d0806) at netisr_dispatch_src+0xa7 netisr_dispatch(7,c93d9000,c93d9000,10,3,...) at netisr_dispatch+0x20 ether_demux(c68ba000,c93d9000,3,0,3,...) at ether_demux+0x133 ether_nh_input(c93d9000,c8f012c8,644d6000,c9492d00,0,...) at ether_nh_input+0x329 netisr_dispatch_src(9,0,c93d9000,e2e,2,1) at netisr_dispatch_src+0xa7 netisr_dispatch(9,c93d9000) at netisr_dispatch+0x20 ether_input(c68ba000,c93d9000,c0f20db8,e2e,c11454c0,...) at ether_input+0x21 lem_intr(c68b6000,8,c0f8e00d,561,0,...) at lem_intr+0x567 intr_event_execute_handlers(c11454c0,c6626200,c0f8e00d,561,c6755000,...) at intr_event_execute_handlers+0xc5 ithread_loop(c6627730,f0839d08,c0f8dd64,3db,0,...) at ithread_loop+0xe2 fork_exit(c0a2dcb0,c6627730,f0839d08) at fork_exit+0x7c fork_trampoline() at fork_trampoline+0x8 --- trap 0, eip = 0, esp = 0xf0839d40, ebp = 0 --- db show locks exclusive sleep mutex em0 (EM TX Lock) r = 0 (0xc68b8560) locked @ /usr/src/sys/dev/e1000/if_lem.c:1324 exclusive sleep mutex em0 (EM Core Lock) r = 0 (0xc68b854c) locked @ /usr/src/sys/dev/e1000/if_lem.c:1302 db I need to head off to a meeting; I can poke at the machine a bit more in a couple of hours or so. I get the same panic and backtrace here, while running as a VMware guest. At least, as soon something actually happens with the network. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: panic: _mtx_lock_sleep: recursed on non-recursive mutex em0 @ /usr/src/sys/dev/e1000/if_lem.c:881
On 28 July 2012 12:09, Arnaud Lacombe lacom...@gmail.com wrote: How would a single ATH_LOCK() helps here ? AFAICS, the panic seem to be a classical fallout from direct dispatch where you can re-enter the driver from the driver itself through the network stack. Take a look at iwn. It has a single lock - IWN_LOCK() - which it releases before punting the frame up the stack. Adrian ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: panic: _mtx_lock_sleep: recursed on non-recursive mutex em0 @ /usr/src/sys/dev/e1000/if_lem.c:881
Hi, On Sat, Jul 28, 2012 at 4:04 PM, Adrian Chadd adr...@freebsd.org wrote: On 28 July 2012 12:09, Arnaud Lacombe lacom...@gmail.com wrote: How would a single ATH_LOCK() helps here ? AFAICS, the panic seem to be a classical fallout from direct dispatch where you can re-enter the driver from the driver itself through the network stack. Take a look at iwn. It has a single lock - IWN_LOCK() - which it releases before punting the frame up the stack. oh, I see. So, what happens in lem(4) is that we enter the stack with RX unlocked, but TX and CORE are still locked. The whole locking of lem(4) seems rather inconsistent. Through DEVICE_POLLING, lem_rxeof() is called with TX and CORE unlocked. Through EN_LEGACY_IRQ it is called with TX and CORE locked, and from MSI interrupt handler, is is caller with TX unlocked (CORE assumed to be unlock). I'd assume that lem(4) is just poorly maintained[0]... I would make a huge shot in the dark by proposing the completely untested attached patch :/ - Arnaud [0]: like code claiming support for Intel 82574 when this chipset *cannot* be used by lem(4), as there is no E1000_DEV_ID_82574* entries in `lem_vendor_info_array'. if_lem.c.diff Description: Binary data ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: panic: _mtx_lock_sleep: recursed on non-recursive mutex em0 @ /usr/src/sys/dev/e1000/if_lem.c:881
On Sat, Jul 28, 2012 at 2:41 PM, Arnaud Lacombe lacom...@gmail.com wrote: Hi, On Sat, Jul 28, 2012 at 4:04 PM, Adrian Chadd adr...@freebsd.org wrote: On 28 July 2012 12:09, Arnaud Lacombe lacom...@gmail.com wrote: How would a single ATH_LOCK() helps here ? AFAICS, the panic seem to be a classical fallout from direct dispatch where you can re-enter the driver from the driver itself through the network stack. Take a look at iwn. It has a single lock - IWN_LOCK() - which it releases before punting the frame up the stack. oh, I see. So, what happens in lem(4) is that we enter the stack with RX unlocked, but TX and CORE are still locked. The whole locking of lem(4) seems rather inconsistent. Through DEVICE_POLLING, lem_rxeof() is called with TX and CORE unlocked. Through EN_LEGACY_IRQ it is called with TX and CORE locked, and from MSI interrupt handler, is is caller with TX unlocked (CORE assumed to be unlock). I'd assume that lem(4) is just poorly maintained[0]... I would make a huge shot in the dark by proposing the completely untested attached patch :/ - Arnaud [0]: like code claiming support for Intel 82574 when this chipset *cannot* be used by lem(4), as there is no E1000_DEV_ID_82574* entries in `lem_vendor_info_array'. Close, but you missed a spot. The attached patch (based on your's) works, i.e. no longer panics at boot on my vbox instance. Thanks! -Garrett fix-if_lem-panic-at-boot.patch Description: Binary data ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: panic: _mtx_lock_sleep: recursed on non-recursive mutex em0 @ /usr/src/sys/dev/e1000/if_lem.c:881
On 2012-07-26 17:46, David Wolfskill wrote: This is at r238795; cut/paste of backtrace: KDB: enter: panic [ thread pid 12 tid 100026 ] Stopped at kdb_enter+0x3d: movl$0,kdb_why db bt Tracing pid 12 tid 100026 td 0xc6755000 kdb_enter(c0f93c5f,c0f93c5f,c0f91e21,f08398f0,c1825c80,...) at kdb_enter+0x3d panic(c0f91e21,c66739a0,c0f20db8,371,c6755000,...) at panic+0x1c4 _mtx_lock_sleep(c68b8560,c6755000,c0f20db8,c0f20db8,371,...) at _mtx_lock_sleep+0x35e _mtx_lock_flags(c68b8560,0,c0f20db8,371,0,...) at _mtx_lock_flags+0xdb lem_start(c68ba000,0,c0fa806c,d20,2a,...) at lem_start+0x33 if_transmit(c68ba000,c93d9000,6,c6755000,c65da588,...) at if_transmit+0x129 ether_output(c68ba000,c93d9000,f0839aa4,0,0,...) at ether_output+0x5df arpintr(c93d9000,8,c0f50314,153,0,...) at arpintr+0x108c netisr_dispatch_src(7,0,c93d9000,c93d9000,c68ba000,c93d0806) at netisr_dispatch_src+0xa7 netisr_dispatch(7,c93d9000,c93d9000,10,3,...) at netisr_dispatch+0x20 ether_demux(c68ba000,c93d9000,3,0,3,...) at ether_demux+0x133 ether_nh_input(c93d9000,c8f012c8,644d6000,c9492d00,0,...) at ether_nh_input+0x329 netisr_dispatch_src(9,0,c93d9000,e2e,2,1) at netisr_dispatch_src+0xa7 netisr_dispatch(9,c93d9000) at netisr_dispatch+0x20 ether_input(c68ba000,c93d9000,c0f20db8,e2e,c11454c0,...) at ether_input+0x21 lem_intr(c68b6000,8,c0f8e00d,561,0,...) at lem_intr+0x567 intr_event_execute_handlers(c11454c0,c6626200,c0f8e00d,561,c6755000,...) at intr_event_execute_handlers+0xc5 ithread_loop(c6627730,f0839d08,c0f8dd64,3db,0,...) at ithread_loop+0xe2 fork_exit(c0a2dcb0,c6627730,f0839d08) at fork_exit+0x7c fork_trampoline() at fork_trampoline+0x8 --- trap 0, eip = 0, esp = 0xf0839d40, ebp = 0 --- db show locks exclusive sleep mutex em0 (EM TX Lock) r = 0 (0xc68b8560) locked @ /usr/src/sys/dev/e1000/if_lem.c:1324 exclusive sleep mutex em0 (EM Core Lock) r = 0 (0xc68b854c) locked @ /usr/src/sys/dev/e1000/if_lem.c:1302 db I need to head off to a meeting; I can poke at the machine a bit more in a couple of hours or so. I get the same panic and backtrace here, while running as a VMware guest. At least, as soon something actually happens with the network. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: panic: _mtx_lock_sleep: recursed on non-recursive mutex em0 @ /usr/src/sys/dev/e1000/if_lem.c:881
It looks like a case of lock held during call up the stack. This is bad for so many reasons. It also makes writing correctly locked drivers a pain in the ass as the moment you unlock the driver before calling ether_input() / ieee80211_input(), you allow things to change state. So no, although you shouldn't use long-held locks to protect things, apparently this is all the rage. iwn(4) does this. ath(4) does not. I'm having a right painful time trying to fine-grain lock things. I'm at the point where I'm about to not care, rip out all the locks and replace with a single ATH_LOCK(). Adrian On 27 July 2012 11:47, Dimitry Andric d...@freebsd.org wrote: On 2012-07-26 17:46, David Wolfskill wrote: This is at r238795; cut/paste of backtrace: KDB: enter: panic [ thread pid 12 tid 100026 ] Stopped at kdb_enter+0x3d: movl$0,kdb_why db bt Tracing pid 12 tid 100026 td 0xc6755000 kdb_enter(c0f93c5f,c0f93c5f,c0f91e21,f08398f0,c1825c80,...) at kdb_enter+0x3d panic(c0f91e21,c66739a0,c0f20db8,371,c6755000,...) at panic+0x1c4 _mtx_lock_sleep(c68b8560,c6755000,c0f20db8,c0f20db8,371,...) at _mtx_lock_sleep+0x35e _mtx_lock_flags(c68b8560,0,c0f20db8,371,0,...) at _mtx_lock_flags+0xdb lem_start(c68ba000,0,c0fa806c,d20,2a,...) at lem_start+0x33 if_transmit(c68ba000,c93d9000,6,c6755000,c65da588,...) at if_transmit+0x129 ether_output(c68ba000,c93d9000,f0839aa4,0,0,...) at ether_output+0x5df arpintr(c93d9000,8,c0f50314,153,0,...) at arpintr+0x108c netisr_dispatch_src(7,0,c93d9000,c93d9000,c68ba000,c93d0806) at netisr_dispatch_src+0xa7 netisr_dispatch(7,c93d9000,c93d9000,10,3,...) at netisr_dispatch+0x20 ether_demux(c68ba000,c93d9000,3,0,3,...) at ether_demux+0x133 ether_nh_input(c93d9000,c8f012c8,644d6000,c9492d00,0,...) at ether_nh_input+0x329 netisr_dispatch_src(9,0,c93d9000,e2e,2,1) at netisr_dispatch_src+0xa7 netisr_dispatch(9,c93d9000) at netisr_dispatch+0x20 ether_input(c68ba000,c93d9000,c0f20db8,e2e,c11454c0,...) at ether_input+0x21 lem_intr(c68b6000,8,c0f8e00d,561,0,...) at lem_intr+0x567 intr_event_execute_handlers(c11454c0,c6626200,c0f8e00d,561,c6755000,...) at intr_event_execute_handlers+0xc5 ithread_loop(c6627730,f0839d08,c0f8dd64,3db,0,...) at ithread_loop+0xe2 fork_exit(c0a2dcb0,c6627730,f0839d08) at fork_exit+0x7c fork_trampoline() at fork_trampoline+0x8 --- trap 0, eip = 0, esp = 0xf0839d40, ebp = 0 --- db show locks exclusive sleep mutex em0 (EM TX Lock) r = 0 (0xc68b8560) locked @ /usr/src/sys/dev/e1000/if_lem.c:1324 exclusive sleep mutex em0 (EM Core Lock) r = 0 (0xc68b854c) locked @ /usr/src/sys/dev/e1000/if_lem.c:1302 db I need to head off to a meeting; I can poke at the machine a bit more in a couple of hours or so. I get the same panic and backtrace here, while running as a VMware guest. At least, as soon something actually happens with the network. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
panic: _mtx_lock_sleep: recursed on non-recursive mutex em0 @ /usr/src/sys/dev/e1000/if_lem.c:881
This is at r238795; cut/paste of backtrace: KDB: enter: panic [ thread pid 12 tid 100026 ] Stopped at kdb_enter+0x3d: movl$0,kdb_why db bt Tracing pid 12 tid 100026 td 0xc6755000 kdb_enter(c0f93c5f,c0f93c5f,c0f91e21,f08398f0,c1825c80,...) at kdb_enter+0x3d panic(c0f91e21,c66739a0,c0f20db8,371,c6755000,...) at panic+0x1c4 _mtx_lock_sleep(c68b8560,c6755000,c0f20db8,c0f20db8,371,...) at _mtx_lock_sleep+0x35e _mtx_lock_flags(c68b8560,0,c0f20db8,371,0,...) at _mtx_lock_flags+0xdb lem_start(c68ba000,0,c0fa806c,d20,2a,...) at lem_start+0x33 if_transmit(c68ba000,c93d9000,6,c6755000,c65da588,...) at if_transmit+0x129 ether_output(c68ba000,c93d9000,f0839aa4,0,0,...) at ether_output+0x5df arpintr(c93d9000,8,c0f50314,153,0,...) at arpintr+0x108c netisr_dispatch_src(7,0,c93d9000,c93d9000,c68ba000,c93d0806) at netisr_dispatch_src+0xa7 netisr_dispatch(7,c93d9000,c93d9000,10,3,...) at netisr_dispatch+0x20 ether_demux(c68ba000,c93d9000,3,0,3,...) at ether_demux+0x133 ether_nh_input(c93d9000,c8f012c8,644d6000,c9492d00,0,...) at ether_nh_input+0x329 netisr_dispatch_src(9,0,c93d9000,e2e,2,1) at netisr_dispatch_src+0xa7 netisr_dispatch(9,c93d9000) at netisr_dispatch+0x20 ether_input(c68ba000,c93d9000,c0f20db8,e2e,c11454c0,...) at ether_input+0x21 lem_intr(c68b6000,8,c0f8e00d,561,0,...) at lem_intr+0x567 intr_event_execute_handlers(c11454c0,c6626200,c0f8e00d,561,c6755000,...) at intr_event_execute_handlers+0xc5 ithread_loop(c6627730,f0839d08,c0f8dd64,3db,0,...) at ithread_loop+0xe2 fork_exit(c0a2dcb0,c6627730,f0839d08) at fork_exit+0x7c fork_trampoline() at fork_trampoline+0x8 --- trap 0, eip = 0, esp = 0xf0839d40, ebp = 0 --- db show locks exclusive sleep mutex em0 (EM TX Lock) r = 0 (0xc68b8560) locked @ /usr/src/sys/dev/e1000/if_lem.c:1324 exclusive sleep mutex em0 (EM Core Lock) r = 0 (0xc68b854c) locked @ /usr/src/sys/dev/e1000/if_lem.c:1302 db I need to head off to a meeting; I can poke at the machine a bit more in a couple of hours or so. Peace, david -- David H. Wolfskill da...@catwhisker.org Depriving a girl or boy of an opportunity for education is evil. See http://www.catwhisker.org/~david/publickey.gpg for my public key. pgppaAxnJyDYV.pgp Description: PGP signature
Re: panic: _mtx_lock_sleep: recursed on non-recursive mutex em0 @ /usr/src/sys/dev/e1000/if_lem.c:881
On Thu, Jul 26, 2012 at 8:46 AM, David Wolfskill da...@catwhisker.org wrote: This is at r238795; cut/paste of backtrace: KDB: enter: panic [ thread pid 12 tid 100026 ] Stopped at kdb_enter+0x3d: movl$0,kdb_why db bt Tracing pid 12 tid 100026 td 0xc6755000 kdb_enter(c0f93c5f,c0f93c5f,c0f91e21,f08398f0,c1825c80,...) at kdb_enter+0x3d panic(c0f91e21,c66739a0,c0f20db8,371,c6755000,...) at panic+0x1c4 _mtx_lock_sleep(c68b8560,c6755000,c0f20db8,c0f20db8,371,...) at _mtx_lock_sleep+0x35e _mtx_lock_flags(c68b8560,0,c0f20db8,371,0,...) at _mtx_lock_flags+0xdb lem_start(c68ba000,0,c0fa806c,d20,2a,...) at lem_start+0x33 if_transmit(c68ba000,c93d9000,6,c6755000,c65da588,...) at if_transmit+0x129 ether_output(c68ba000,c93d9000,f0839aa4,0,0,...) at ether_output+0x5df arpintr(c93d9000,8,c0f50314,153,0,...) at arpintr+0x108c netisr_dispatch_src(7,0,c93d9000,c93d9000,c68ba000,c93d0806) at netisr_dispatch_src+0xa7 netisr_dispatch(7,c93d9000,c93d9000,10,3,...) at netisr_dispatch+0x20 ether_demux(c68ba000,c93d9000,3,0,3,...) at ether_demux+0x133 ether_nh_input(c93d9000,c8f012c8,644d6000,c9492d00,0,...) at ether_nh_input+0x329 netisr_dispatch_src(9,0,c93d9000,e2e,2,1) at netisr_dispatch_src+0xa7 netisr_dispatch(9,c93d9000) at netisr_dispatch+0x20 ether_input(c68ba000,c93d9000,c0f20db8,e2e,c11454c0,...) at ether_input+0x21 lem_intr(c68b6000,8,c0f8e00d,561,0,...) at lem_intr+0x567 intr_event_execute_handlers(c11454c0,c6626200,c0f8e00d,561,c6755000,...) at intr_event_execute_handlers+0xc5 ithread_loop(c6627730,f0839d08,c0f8dd64,3db,0,...) at ithread_loop+0xe2 fork_exit(c0a2dcb0,c6627730,f0839d08) at fork_exit+0x7c fork_trampoline() at fork_trampoline+0x8 --- trap 0, eip = 0, esp = 0xf0839d40, ebp = 0 --- db show locks exclusive sleep mutex em0 (EM TX Lock) r = 0 (0xc68b8560) locked @ /usr/src/sys/dev/e1000/if_lem.c:1324 exclusive sleep mutex em0 (EM Core Lock) r = 0 (0xc68b854c) locked @ /usr/src/sys/dev/e1000/if_lem.c:1302 db I need to head off to a meeting; I can poke at the machine a bit more in a couple of hours or so. Probably fallout from Luigi enabling legacy interrupts by default in r238765. -Garrett ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: panic: _mtx_lock_sleep: recursed on non-recursive mutex em0 @ /usr/src/sys/dev/e1000/if_lem.c:881
On Thu, Jul 26, 2012 at 09:01:18AM -0700, Garrett Cooper wrote: On Thu, Jul 26, 2012 at 8:46 AM, David Wolfskill da...@catwhisker.org wrote: This is at r238795; cut/paste of backtrace: KDB: enter: panic [ thread pid 12 tid 100026 ] Stopped at kdb_enter+0x3d: movl$0,kdb_why db bt Tracing pid 12 tid 100026 td 0xc6755000 kdb_enter(c0f93c5f,c0f93c5f,c0f91e21,f08398f0,c1825c80,...) at kdb_enter+0x3d panic(c0f91e21,c66739a0,c0f20db8,371,c6755000,...) at panic+0x1c4 _mtx_lock_sleep(c68b8560,c6755000,c0f20db8,c0f20db8,371,...) at _mtx_lock_sleep+0x35e _mtx_lock_flags(c68b8560,0,c0f20db8,371,0,...) at _mtx_lock_flags+0xdb lem_start(c68ba000,0,c0fa806c,d20,2a,...) at lem_start+0x33 if_transmit(c68ba000,c93d9000,6,c6755000,c65da588,...) at if_transmit+0x129 ether_output(c68ba000,c93d9000,f0839aa4,0,0,...) at ether_output+0x5df arpintr(c93d9000,8,c0f50314,153,0,...) at arpintr+0x108c netisr_dispatch_src(7,0,c93d9000,c93d9000,c68ba000,c93d0806) at netisr_dispatch_src+0xa7 netisr_dispatch(7,c93d9000,c93d9000,10,3,...) at netisr_dispatch+0x20 ether_demux(c68ba000,c93d9000,3,0,3,...) at ether_demux+0x133 ether_nh_input(c93d9000,c8f012c8,644d6000,c9492d00,0,...) at ether_nh_input+0x329 netisr_dispatch_src(9,0,c93d9000,e2e,2,1) at netisr_dispatch_src+0xa7 netisr_dispatch(9,c93d9000) at netisr_dispatch+0x20 ether_input(c68ba000,c93d9000,c0f20db8,e2e,c11454c0,...) at ether_input+0x21 lem_intr(c68b6000,8,c0f8e00d,561,0,...) at lem_intr+0x567 intr_event_execute_handlers(c11454c0,c6626200,c0f8e00d,561,c6755000,...) at intr_event_execute_handlers+0xc5 ithread_loop(c6627730,f0839d08,c0f8dd64,3db,0,...) at ithread_loop+0xe2 fork_exit(c0a2dcb0,c6627730,f0839d08) at fork_exit+0x7c fork_trampoline() at fork_trampoline+0x8 --- trap 0, eip = 0, esp = 0xf0839d40, ebp = 0 --- db show locks exclusive sleep mutex em0 (EM TX Lock) r = 0 (0xc68b8560) locked @ /usr/src/sys/dev/e1000/if_lem.c:1324 exclusive sleep mutex em0 (EM Core Lock) r = 0 (0xc68b854c) locked @ /usr/src/sys/dev/e1000/if_lem.c:1302 db I need to head off to a meeting; I can poke at the machine a bit more in a couple of hours or so. Probably fallout from Luigi enabling legacy interrupts by default in r238765. yes. I'll investigate with David then he returns from the meeting, and either we find a fix or i will backout the change and add a note in the source about this problem, should people want to look at it in the future. cheers luigi on the ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
