From owner-acpi-jp@jp.FreeBSD.org Fri Oct 11 03:32:43 2002
Received: (from daemon@localhost)
	by castle.jp.FreeBSD.org (8.11.6+3.4W/8.11.3) id g9AIWho01534;
	Fri, 11 Oct 2002 03:32:43 +0900 (JST)
	(envelope-from owner-acpi-jp@jp.FreeBSD.org)
Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16])
	by castle.jp.FreeBSD.org (8.11.6+3.4W/8.11.3) with ESMTP/inet id g9AIWc301528
	for <acpi-jp@jp.FreeBSD.org>; Fri, 11 Oct 2002 03:32:39 +0900 (JST)
	(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
From: Bruce Evans <bde@zeta.org.au>
X-X-Sender: bde@gamplex.bde.org
To: John Baldwin <jhb@freebsd.org>
cc: David Wolfskill <david@catwhisker.org>, <acpi-jp@jp.FreeBSD.org>,
   <current@freebsd.org>
In-Reply-To: <XFMail.20021010102417.jhb@FreeBSD.org>
Message-ID: <20021011033612.V10030-100000@gamplex.bde.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Reply-To: acpi-jp@jp.FreeBSD.org
Precedence: list
Date: Fri, 11 Oct 2002 04:42:26 +1000
X-Sequence: acpi-jp 1895
Subject: [acpi-jp 1895] RE: panic: blockable sleep lock (sleep mutex) sellck @ /usr/src/
Errors-To: owner-acpi-jp@jp.FreeBSD.org
Sender: owner-acpi-jp@jp.FreeBSD.org
X-Originator: bde@zeta.org.au
X-Distribute: distribute version 2.1 (Alpha) patchlevel 24e+021008

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

