Re: panic: _mtx_lock_sleep: recursed on non-recursive mutex em0 @ /usr/src/sys/dev/e1000/if_lem.c:881

2012-07-29 Thread David J. Weller-Fahy
* Garrett Cooper [2012-07-28 18:43 -0400]: > On Sat, Jul 28, 2012 at 2:41 PM, Arnaud Lacombe 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! -- dav

Re: panic: _mtx_lock_sleep: recursed on non-recursive mutex em0 @ /usr/src/sys/dev/e1000/if_lem.c:881

2012-07-28 Thread Garrett Cooper
On Sat, Jul 28, 2012 at 2:41 PM, Arnaud Lacombe wrote: > Hi, > > On Sat, Jul 28, 2012 at 4:04 PM, Adrian Chadd wrote: >> On 28 July 2012 12:09, Arnaud Lacombe wrote: >> >>> How would a single ATH_LOCK() helps here ? AFAICS, the panic seem to >>> be a classical fallout from direct dispatch where

Re: panic: _mtx_lock_sleep: recursed on non-recursive mutex em0 @ /usr/src/sys/dev/e1000/if_lem.c:881

2012-07-28 Thread Arnaud Lacombe
Hi, On Sat, Jul 28, 2012 at 4:04 PM, Adrian Chadd wrote: > On 28 July 2012 12:09, Arnaud Lacombe 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

Re: panic: _mtx_lock_sleep: recursed on non-recursive mutex em0 @ /usr/src/sys/dev/e1000/if_lem.c:881

2012-07-28 Thread Adrian Chadd
On 28 July 2012 12:09, Arnaud Lacombe 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_L

Re: panic: _mtx_lock_sleep: recursed on non-recursive mutex em0 @ /usr/src/sys/dev/e1000/if_lem.c:881

2012-07-28 Thread Arnaud Lacombe
Hi, On Fri, Jul 27, 2012 at 4:31 PM, Adrian Chadd 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() / > i

Re: panic: _mtx_lock_sleep: recursed on non-recursive mutex em0 @ /usr/src/sys/dev/e1000/if_lem.c:881

2012-07-27 Thread Adrian Chadd
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 yo

Re: panic: _mtx_lock_sleep: recursed on non-recursive mutex em0 @ /usr/src/sys/dev/e1000/if_lem.c:881

2012-07-27 Thread Dimitry Andric
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,c18

Re: panic: _mtx_lock_sleep: recursed on non-recursive mutex em0 @ /usr/src/sys/dev/e1000/if_lem.c:881

2012-07-26 Thread Luigi Rizzo
On Thu, Jul 26, 2012 at 09:01:18AM -0700, Garrett Cooper wrote: > On Thu, Jul 26, 2012 at 8:46 AM, 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 > >

Re: panic: _mtx_lock_sleep: recursed on non-recursive mutex em0 @ /usr/src/sys/dev/e1000/if_lem.c:881

2012-07-26 Thread Garrett Cooper
On Thu, Jul 26, 2012 at 8:46 AM, 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,

panic: _mtx_lock_sleep: recursed on non-recursive mutex em0 @ /usr/src/sys/dev/e1000/if_lem.c:881

2012-07-26 Thread David Wolfskill
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,c0f20db