Date: Thu, 22 Nov 2007 13:27:16 +0100 From: "Attilio Rao" <attilio@freebsd.org> To: "Benjamin Close" <Benjamin.Close@clearchain.com> Cc: Jack F Vogel <jfv@freebsd.org>, freebsd-current@freebsd.org Subject: Re: em0 panic: mutex em0 not owned Message-ID: <3bbf2fe10711220427s38561159k4879d0c792d09694@mail.gmail.com> In-Reply-To: <3bbf2fe10711220408t30136430s15fdba0ebcbbfa66@mail.gmail.com> References: <4744EBA4.7020209@clearchain.com> <3bbf2fe10711220408t30136430s15fdba0ebcbbfa66@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
2007/11/22, Attilio Rao <attilio@freebsd.org>: > 2007/11/22, Benjamin Close <Benjamin.Close@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@ court (CC'ed). Thanks, Attilio -- Peace can only be achieved by understanding - A. Einstein
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3bbf2fe10711220427s38561159k4879d0c792d09694>