Re: em0 panic: mutex em0 not owned
- From: "Attilio Rao" <attilio@xxxxxxxxxxx>
- Date: Thu, 22 Nov 2007 13:27:16 +0100
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).
Thanks,
Attilio
--
Peace can only be achieved by understanding - A. Einstein
_______________________________________________
freebsd-current@xxxxxxxxxxx mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscribe@xxxxxxxxxxx"
- Follow-Ups:
- Re: em0 panic: mutex em0 not owned
- From: Benjamin Close
- Re: em0 panic: mutex em0 not owned
- References:
- em0 panic: mutex em0 not owned
- From: Benjamin Close
- Re: em0 panic: mutex em0 not owned
- From: Attilio Rao
- em0 panic: mutex em0 not owned
- Prev by Date: Re: em0 panic: mutex em0 not owned
- Next by Date: Re: boot-time crash in today's -current, and other threading problems
- Previous by thread: Re: em0 panic: mutex em0 not owned
- Next by thread: Re: em0 panic: mutex em0 not owned
- Index(es):
Relevant Pages
|
|