From owner-freebsd-arch@FreeBSD.ORG Thu Nov 15 17:58:30 2012 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 410E643E; Thu, 15 Nov 2012 17:58:30 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: from mail-lb0-f182.google.com (mail-lb0-f182.google.com [209.85.217.182]) by mx1.freebsd.org (Postfix) with ESMTP id 447438FC0C; Thu, 15 Nov 2012 17:58:28 +0000 (UTC) Received: by mail-lb0-f182.google.com with SMTP id gg13so1891590lbb.13 for ; Thu, 15 Nov 2012 09:58:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=/784YJ7P0phbTjZnjIudSY1gbTQjewTS+Tc82oaldHY=; b=ZYIXLC5POxipwbcNZys+dSrFMEwu1MeF4EZneJo3NuD+9wESecjwsP2rc9aWUgWuDm gER40RsNvquk67EU377fzkbwhp4S9DXY3MktXfH5vAxJASmFII3gPGp9/aKf+cW3DkuN 5rkIwRHJN+Be777VrgVd/9J0/a3YP84khxxUfzE4cDQ+VC5kKUrQRsTvdEmflQF+rS2F jh//SWHM/2Gwr77bnHR3osvT5nhaCp6VTKdJOmcBNcw6oUbZkDVrNI3HJt+bdFz95nmB ezUHQMk0gYbefFP5Jj1Hc9J9wbfR4szsqpPbdd73XuKsVZC2LVhQMsOP8gcMKfMC0WfR RzfQ== MIME-Version: 1.0 Received: by 10.152.110.234 with SMTP id id10mr1866385lab.15.1353002307844; Thu, 15 Nov 2012 09:58:27 -0800 (PST) Sender: asmrookie@gmail.com Received: by 10.112.134.5 with HTTP; Thu, 15 Nov 2012 09:58:27 -0800 (PST) In-Reply-To: <47374EC3-5022-49AC-A17E-7F234A88B5C6@bsdimp.com> References: <1353001175.1217.153.camel@revolution.hippie.lan> <47374EC3-5022-49AC-A17E-7F234A88B5C6@bsdimp.com> Date: Thu, 15 Nov 2012 17:58:27 +0000 X-Google-Sender-Auth: jS2zDfgxw6VU2nTA6v7jwLNjc20 Message-ID: Subject: Re: [RFQ] make witness panic an option From: Attilio Rao To: Warner Losh Content-Type: text/plain; charset=UTF-8 Cc: Ian Lepore , Adrian Chadd , freebsd-arch@freebsd.org, freebsd-hackers@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: attilio@FreeBSD.org List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Nov 2012 17:58:30 -0000 On 11/15/12, Warner Losh wrote: > > On Nov 15, 2012, at 10:47 AM, Attilio Rao wrote: > >> On 11/15/12, Ian Lepore 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. Without WITNESS_KDB the kernel won't panic if this is really the case, if it is only about LOR yelling. Otherwise the breakage is more serious and I would like to see a real case example. Attilio -- Peace can only be achieved by understanding - A. Einstein