From owner-svn-src-all@FreeBSD.ORG Sat Mar 2 06:34:50 2013 Return-Path: Delivered-To: svn-src-all@FreeBSD.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id F1EBDC39; Sat, 2 Mar 2013 06:34:49 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from fallbackmx08.syd.optusnet.com.au (fallbackmx08.syd.optusnet.com.au [211.29.132.10]) by mx1.freebsd.org (Postfix) with ESMTP id 90578D44; Sat, 2 Mar 2013 06:34:48 +0000 (UTC) Received: from mail09.syd.optusnet.com.au (mail09.syd.optusnet.com.au [211.29.132.190]) by fallbackmx08.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id r226Yes6030356; Sat, 2 Mar 2013 17:34:40 +1100 Received: from c211-30-173-106.carlnfd1.nsw.optusnet.com.au (c211-30-173-106.carlnfd1.nsw.optusnet.com.au [211.30.173.106]) by mail09.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id r226YRvk006040 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 2 Mar 2013 17:34:31 +1100 Date: Sat, 2 Mar 2013 17:34:27 +1100 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: Marius Strobl Subject: Re: svn commit: r247600 - in head/sys: conf sparc64/pci In-Reply-To: <201303020037.r220bWJg057328@svn.freebsd.org> Message-ID: <20130302153017.O1121@besplex.bde.org> References: <201303020037.r220bWJg057328@svn.freebsd.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Optus-CM-Score: 0 X-Optus-CM-Analysis: v=2.0 cv=DdhPMYRW c=1 sm=1 a=OATcr5XPpMsA:10 a=kj9zAlcOel0A:10 a=PO7r1zJSAAAA:8 a=JzwRw_2MAAAA:8 a=s5sLUIhH2asA:10 a=nh50T69upB6EW8B8ixgA:9 a=CjuIK1q_8ugA:10 a=TEtd8y5WR3g2ypngnwZWYw==:117 Cc: svn-src-head@FreeBSD.org, svn-src-all@FreeBSD.org, src-committers@FreeBSD.org X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Mar 2013 06:34:50 -0000 On Sat, 2 Mar 2013, Marius Strobl wrote: > Log: > - While Netra X1 generally show no ill effects when registering a power > fail interrupt handler, there seems to be either a broken batch of them > or a tendency to develop a defect which causes this interrupt to fire > inadvertedly. Given that apart from this problem these machines work > just fine, add a tunable allowing the setup of the power fail interrupt > to be disabled. > While at it, remove the DEBUGGER_ON_POWERFAIL compile time option and > make that behavior also selectable via the newly added tunable. > - Apparently, it's no longer a problem to call shutdown_nice(9) from within > an interrupt filter (some other drivers in the tree do the same). So > change the power fail interrupt from an handler in order to simplify the > code and get rid of a !INTR_MPSAFE handler. Gak! It it is any error to call any() from within a fast interrupt handler. Even with fast interrupt handlers broken to be interrupt filters, it is an error to call almost any(). shutdown_nice() is an especially invalid any(). It sends a signal to init, and uses many sleep locks for this. So you have the interrupt filter which is locked by critical_enter() and probably also by hard-disabling interrupts on the current CPU, calling up to code locked by sleep mutexes. This asks for deadlock, and gets it when the interrupt preempts code holding one of the sleep locks that is wandered into. The other broken drivers that do this seem to be mainly serial console drivers. Their debugger entry was subverted into calling panic() or shutdown_nice() according to an escape sequence. Even the debugger entry part of this was broken by changing it from a hard breakpoint to a kdb_enter() call which does invalid things (it accesses global state without locking, and calls printf() before entering debugger context). shutdown_nice() is also called from acpi and from syscons. I think the latter still uses an ordinary (Giant locked) interrupt handler. Calling shutdown_nice() from there has a chance of never deadlocking. It would just have to wait if the interrupt interrupted something holding shutdown_nice()'s locks. The dangerous calls in syscons are actually from scgetc(). I think they are reachable in debugger mode too. Then they are invalid. So are ddb's commands for rebooting and panicing. You can't call any() from ddb either, but these commands do. A non-broken version of these commands (or "call any()) would exit from ddb context after arranging to make the call using a trampoline. The call might fail, but then it is not the fault of ddb's context. The trampoline is needed to regain control if the call can return. The reboot and panic commands are safer than most of the unsafe ones since they are supposed to give an unclean shutdown and if they don't work then nothing much worse than a recursive unclean shutdown can happen. Bruce