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-hackers@freebsd.org, freebsd-arch@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, >>> >>> 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. >>> >>> This patch (against stable/9) makes the actual panic itself >>> configurable. It still prints the message regardless. >>> >>> 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. >>> >>> I'd like everyone to consider this for FreeBSD-HEAD. >>> >>> Thanks! >> >> I strongly support this, because I'm tired of having to hack it in by >> hand every time I need it. >> >> 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.) > > 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. > > Do you really think that an abusable mechanism will help here rather > than fixing the actual problems? > >> 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. > > 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". > > 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 _______________________________________________ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org"
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?47374EC3-5022-49AC-A17E-7F234A88B5C6>