Re: em0 panic: mutex em0 not owned

Jack Vogel wrote:

> On Nov 26, 2007 2:31 PM, Attilio Rao <attilio_at_freebsd.org> wrote:
>> 2007/11/26, Benjamin Close <Benjamin.Close_at_clearchain.com>:
>>
>> > Attilio Rao wrote:
>> > > 2007/11/22, Attilio Rao <attilio_at_freebsd.org>:
>> > >
>> > >> 2007/11/22, Benjamin Close <Benjamin.Close_at_clearchain.com>:
>> > >>
>> > >>> Hi Folks,
>> > >>>     With a recent current I'm now getting panics when em0 tries to
>> > >>>     come up:
>> > >>>
>> > >>> panic: mutex em0 not owned at ../../../kern/kern_mutex.c:144
>> > >>>
>> > >>> _mtx_assert() + 0xdc
>> > >>> _callout_stop_safe()+0x5d
>> > >>> em_stop() + 0x50 (if_em.c:2546)
>> > >>> em_init_locked()+0x47 (if_em.c:1256)
>> > >>> em_ioctl()+0x466
>> > >>> ifhwioctl() + 0x75f
>> > >>> ifioctl() +0xb0
>> > >>> kern_ioctl() + 0xa3
>> > >>>
>> > >>> This is even after atillos, latest patch.
>> > >>>
>> > >> Yes, this is a race access to callout_stop() in em driver.
>> > >> callout_stop() needs to be called with callout-specific lock held
>> > >> otherwise you can get a race and this seems not happening. I just
>> > >> inserted this assertions in order to catch bugs like these.
>> > >> I have no time to double-check it, can you do?
>> > >>
>> > >
>> > > Ok, basically em_stop() both wants to stop core callout and tx
>> > > channel callout but it only holds core lock. It needs to hold both in
>> > > order to stop both. As I'm not sure about lock ordering there I can't
>> > > produce a patch now so the ball is in jfv_at_ court (CC'ed).
>> > >
>> > The attached patch fixes the panic at the cost of a lock order
>> > reversal:
>>
>> jfv_at_ today should have fixed it.
>> Please cvsup and try again.
>>
>>
>> Attilio
> 
> Yup, version 1.188 is the fix for this.
> 
> Cheers,
> 
> Jack
> _______________________________________________
> freebsd-current_at_freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscribe_at_freebsd.org"

Is this expected after the fix?

acquiring duplicate lock of same type: "network driver"
 1st em0 _at_ /usr/src/sys/dev/em/if_em.c:1018
 2nd em0 _at_ /usr/src/sys/dev/em/if_em.c:1252
KDB: stack backtrace:
db_trace_self_wrapper(c0acd130,e6685a60,c07a6d26,c0acf51e,c40328d0,...) at
db_trace_self_wrapper+0x26
kdb_backtrace(c0acf51e,c40328d0,c0a9becd,4e4,e6685a48,...) at
kdb_backtrace+0x29
witness_checkorder(c40022d8,9,c0a9becd,4e4,38,...) at
witness_checkorder+0x6d6
_mtx_lock_flags(c40022d8,0,c0a9becd,4e4,c4031800,...) at
_mtx_lock_flags+0xbc
em_init_locked(c40022c0,0,c0a9becd,3fa,c40ab400,...) at em_init_locked+0x65
em_ioctl(c4031800,8020690c,c40ab400,c0796b96,a057b1ef,...) at em_ioctl+0xe3
in_ifinit(0,c40ab400,0,0,c0ad68ef,...) at in_ifinit+0x292
in_control(c4300dec,8040691a,c422ea40,c4031800,c42ffcc0,...) at
in_control+0xa83
ifioctl(c4300dec,8040691a,c422ea40,c42ffcc0,c42ffcc0,...) at ifioctl+0x333
soo_ioctl(c4297708,8040691a,c422ea40,c3f0d800,c42ffcc0,...) at
soo_ioctl+0x3e2
kern_ioctl(c42ffcc0,3,8040691a,c422ea40,0,...) at kern_ioctl+0x253
ioctl(c42ffcc0,e6685cfc,c,c0afca45,c0b7b510,...) at ioctl+0x13f
syscall(e6685d38) at syscall+0x2f3
Xint0x80_syscall() at Xint0x80_syscall+0x20
--- syscall (54, FreeBSD ELF32, ioctl), eip = 0x2816b213, esp = 0xbfbfe60c,
ebp = 0xbfbfe638 ---
#
em0: Link is up 1000 Mbps Full Duplex


# pciconf -v -l | grep ^em -A4
em0_at_pci0:3:0:0: class=0x020000 card=0x61801462 chip=0x108b8086 rev=0x03
hdr=0x00
    vendor     = 'Intel Corporation'
    device     = 'PC82573V Intel network controller (PCIE Gigabit Ethernet)'
    class      = network
    subclass   = ethernet
em1_at_pci0:4:0:0: class=0x020000 card=0x61801462 chip=0x108b8086 rev=0x00
hdr=0x00
    vendor     = 'Intel Corporation'
    device     = 'PC82573V Intel network controller (PCIE Gigabit Ethernet)'
    class      = network
    subclass   = ethernet

-- 
Mark Atkinson
atkin901_at_yahoo.com
(!wired)?(coffee++):(wired);