Re: em0 panic: mutex em0 not owned

Jack Vogel wrote:

On Nov 26, 2007 2:31 PM, Attilio Rao <attilio@xxxxxxxxxxx> wrote:
2007/11/26, Benjamin Close <Benjamin.Close@xxxxxxxxxxxxxx>:

Attilio Rao wrote:
2007/11/22, Attilio Rao <attilio@xxxxxxxxxxx>:

2007/11/22, Benjamin Close <Benjamin.Close@xxxxxxxxxxxxxx>:

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@ court (CC'ed).

The attached patch fixes the panic at the cost of a lock order
reversal:

jfv@ today should have fixed it.
Please cvsup and try again.


Attilio

Yup, version 1.188 is the fix for this.

Cheers,

Jack
_______________________________________________
freebsd-current@xxxxxxxxxxx mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscribe@xxxxxxxxxxx"

Is this expected after the fix?

acquiring duplicate lock of same type: "network driver"
1st em0 @ /usr/src/sys/dev/em/if_em.c:1018
2nd em0 @ /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@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@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@xxxxxxxxx
(!wired)?(coffee++):(wired);

_______________________________________________
freebsd-current@xxxxxxxxxxx mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscribe@xxxxxxxxxxx"

Relevant Pages

  • nvidia driver on recent current?
    ... I've been getting a lot of these panics on recent -current builds that ... spin locks can only use msleep_spin ... print *lock ...
    (freebsd-current)
  • Re: tree may not be buildable for an hour.
    ... v--deadlocks trying to panic, then the other CPU holding the spin lock panics ... KDB: enter: panic ...
    (freebsd-current)
  • Re: Possible UDP related deadlock in 7.1-PRERELEASE
    ... I can trigger this lockup reliably by starting ktorrent. ... also lock up. ... With WITNESS enabled, I now experience panics and could not follow your ...
    (freebsd-stable)
  • sleeping thread
    ... One thread does a setsockopt, grabs a lock in udp_usrreq, calls ... propagate the priority and panics because there is a check in the code ... KDB: stack backtrace: ...
    (freebsd-net)