Date: Thu, 15 Nov 2012 10:56:17 -0700 From: Warner Losh <imp@bsdimp.com> To: attilio@FreeBSD.org Cc: Ian Lepore <freebsd@damnhippie.dyndns.org>, Adrian Chadd <adrian@freebsd.org>, freebsd-arch@freebsd.org, freebsd-hackers@freebsd.org Subject: Re: [RFQ] make witness panic an option Message-ID: <47374EC3-5022-49AC-A17E-7F234A88B5C6@bsdimp.com> In-Reply-To: <CAJ-FndBP5Pi=SCpyBLK3b=HM_gQ9u8M4%2B1tLk9tA5X-gqismVA@mail.gmail.com> References: <CAJ-Vmo=i=Amo_QqHi4GnGie0Gc0YnK3XaRKjvBO-=SFboFYPmA@mail.gmail.com> <1353001175.1217.153.camel@revolution.hippie.lan> <CAJ-FndBP5Pi=SCpyBLK3b=HM_gQ9u8M4%2B1tLk9tA5X-gqismVA@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Nov 15, 2012, at 10:47 AM, Attilio Rao wrote: > On 11/15/12, Ian Lepore <freebsd@damnhippie.dyndns.org> wrote: >> On Wed, 2012-11-14 at 22:15 -0800, Adrian Chadd wrote: >>> Hi all, >>>=20 >>> When debugging and writing wireless drivers/stack code, I like to >>> sprinkle lots of locking assertions everywhere. However, this does >>> cause things to panic quite often during active development. >>>=20 >>> This patch (against stable/9) makes the actual panic itself >>> configurable. It still prints the message regardless. >>>=20 >>> This has allowed me to sprinkle more locking assertions everywhere = to >>> investigate whether particular paths have been hit or not. I don't >>> necessarily want those to panic the kernel. >>>=20 >>> I'd like everyone to consider this for FreeBSD-HEAD. >>>=20 >>> Thanks! >>=20 >> I strongly support this, because I'm tired of having to hack it in by >> hand every time I need it. >>=20 >> You can't boot an arm platform right now (on freebsd 8, 9, or 10) >> without a LOR very early in the boot. Once you get past that, 2 or 3 >> device drivers I use panic way before we even get to mounting root. >> Those panics can clearly be ignored, because we've been shipping >> products for years based on this code. (It's on my to-do list to fix >> them, but more pressing problems are higher on the list.) >=20 > This is a ridicolous motivation. > What are the panics in question? Why they are not fixed yet? > Without WITNESS_KDB you should not panic even in cases where WITNESS > yells. So if you do, it means there is a more subdole breakage going > on here. >=20 > Do you really think that an abusable mechanism will help here rather > than fixing the actual problems? >=20 >> When a new problem crops up that isn't harmless, it totally sucks = that I >> can't just turn on witness without first hacking the code to make the >> known problems non-panicky. >=20 > I really don't understand what are these "harmless problems" here. > I just know one and it is between the dirhash lock and the bufwait > lock for UFS, which is carefully documented in the code comments. All > the others cases haven't been analyzed deeply enough to quantify them > as "harmless". >=20 > Can you please make real examples? It sounds like he's more worried about introducing LoRs into his = wireless code. They are harmless, for him, and he can fix them by = reloading the driver. They are only harmful if he loses a race. Warner=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?47374EC3-5022-49AC-A17E-7F234A88B5C6>