From owner-freebsd-current Thu Oct 10 11:32:27 2002 Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5D4AE37B401; Thu, 10 Oct 2002 11:32:26 -0700 (PDT) Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16]) by mx1.FreeBSD.org (Postfix) with ESMTP id B99D243EAF; Thu, 10 Oct 2002 11:32:24 -0700 (PDT) (envelope-from bde@zeta.org.au) Received: from bde.zeta.org.au (bde.zeta.org.au [203.2.228.102]) by mailman.zeta.org.au (8.9.3/8.8.7) with ESMTP id EAA03651; Fri, 11 Oct 2002 04:32:17 +1000 Date: Fri, 11 Oct 2002 04:42:26 +1000 (EST) From: Bruce Evans X-X-Sender: bde@gamplex.bde.org To: John Baldwin Cc: David Wolfskill , , Subject: RE: panic: blockable sleep lock (sleep mutex) sellck @ /usr/src/ In-Reply-To: Message-ID: <20021011033612.V10030-100000@gamplex.bde.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Thu, 10 Oct 2002, John Baldwin wrote: > On 10-Oct-2002 David Wolfskill wrote: > > I'm including acpi-jp@jp.FreeBSD.org because there may well be some > > interaction with the recently-imported acpica-unix-20021002. Please > > be judicious with respect to where replies are directed. > > This isn't ACPI related I don't think. You got a stray interrupt and > sched_ithd() tried to call printf(). Unfortunately, cpu_unpend() seems > to be executing while it is still in a critical section, so when printf() > calls into select() it breaks. Probably printf() needs work to be made > more intelligent so it doesn't get into select() in that case but defers > it. The printf part of the bug is just the old one that TIOCCONS never actually worked and cannot be made to work. Calling the pty driver from arbitrary interrupt handlers is invalid. Even if it were, the application that reads the pty would not be able to run and print what it read before printf(9) returns, as is required for printfs in some contexts. cpu_unpend() (actually its callee i386_unpend()) enters the critical section itself (and KASSERT()s that it is not already in a critical section). I think this is just to prevent ithread_schedule() switching away from us when we call it (indirectly via sched_ithd()). This lets a single thread clear all the pending interrupts as soon as possible, which is good for various reasons (especially for fast interrupts). Entering the critical region is not necessary from preventing preemption, since we run with interrupts disabled (provided we don't let ithread_schedule() enable them when it switches away from us). Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message