Date: Fri, 11 Oct 2002 04:42:26 +1000 (EST) From: Bruce Evans <bde@zeta.org.au> To: John Baldwin <jhb@FreeBSD.ORG> Cc: David Wolfskill <david@catwhisker.org>, <acpi-jp@jp.FreeBSD.org>, <current@FreeBSD.ORG> Subject: RE: panic: blockable sleep lock (sleep mutex) sellck @ /usr/src/ Message-ID: <20021011033612.V10030-100000@gamplex.bde.org> In-Reply-To: <XFMail.20021010102417.jhb@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20021011033612.V10030-100000>