Date: Mon, 26 Nov 2007 14:34:53 -0800 From: "Jack Vogel" <jfvogel@gmail.com> To: "Attilio Rao" <attilio@freebsd.org> Cc: Jack F Vogel <jfv@freebsd.org>, freebsd-current@freebsd.org, Benjamin Close <Benjamin.Close@clearchain.com> Subject: Re: em0 panic: mutex em0 not owned Message-ID: <2a41acea0711261434u817eb06xe05eba8447afc3ae@mail.gmail.com> In-Reply-To: <3bbf2fe10711261431s1b1bd697n46d370900d5fe9c0@mail.gmail.com> References: <4744EBA4.7020209@clearchain.com> <3bbf2fe10711220408t30136430s15fdba0ebcbbfa66@mail.gmail.com> <3bbf2fe10711220427s38561159k4879d0c792d09694@mail.gmail.com> <474B4876.9020209@clearchain.com> <3bbf2fe10711261431s1b1bd697n46d370900d5fe9c0@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Nov 26, 2007 2:31 PM, Attilio Rao <attilio@freebsd.org> wrote: > 2007/11/26, Benjamin Close <Benjamin.Close@clearchain.com>: > > > Attilio Rao wrote: > > > 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). > > > > > 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?2a41acea0711261434u817eb06xe05eba8447afc3ae>