From owner-freebsd-current@FreeBSD.ORG Wed Apr 8 19:38:45 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 020FC10656D7; Wed, 8 Apr 2009 19:38:45 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id CE07E8FC21; Wed, 8 Apr 2009 19:38:44 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by cyrus.watson.org (Postfix) with ESMTPS id 678DD46B51; Wed, 8 Apr 2009 15:38:44 -0400 (EDT) Date: Wed, 8 Apr 2009 20:38:44 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Ed Schouten In-Reply-To: <20090408193319.GK32098@hoeg.nl> Message-ID: References: <20090408170231.K38445@rust.salford.ac.uk> <20090408193319.GK32098@hoeg.nl> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: FreeBSD Current , Ivan Voras Subject: Re: kbdmux vs ATA? (was: ATA related panic during ZFS scrub) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Apr 2009 19:38:47 -0000 On Wed, 8 Apr 2009, Ed Schouten wrote: > * Ivan Voras wrote: >> Hmmm, this shows a lock order problem between ATA and kbdmux's Giant. > > The current state of the input layer is a mess. I guess the policy was to > not pick up any locks while in the debugger. Picking up Giant there is one > of the most awful things that can happen, right? As a general rule, the low-level console interfaces should acquire at most spinlocks in normal operation (cngetc, cnputc, etc), and no locks at all when in the debugger (kdb_active). The reason for the second rule should be obvious, but the reason for the first rule is less obvious: it's called during the boot in all kinds of sensitive places as a result of calls to printf(9), so has to be willing to run under the most sticky of circumstances. Robert N M Watson Computer Laboratory University of Cambridge