From owner-freebsd-current@FreeBSD.ORG Tue Oct 19 21:53:19 2004 Return-Path: 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 EB63F16A4D1; Tue, 19 Oct 2004 21:53:19 +0000 (GMT) Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8C64243D41; Tue, 19 Oct 2004 21:53:19 +0000 (GMT) (envelope-from robert@fledge.watson.org) Received: from fledge.watson.org (localhost [127.0.0.1]) by fledge.watson.org (8.13.1/8.13.1) with ESMTP id i9JLr7xW082301; Tue, 19 Oct 2004 17:53:07 -0400 (EDT) (envelope-from robert@fledge.watson.org) Received: from localhost (robert@localhost)i9JLr7fC082298; Tue, 19 Oct 2004 17:53:07 -0400 (EDT) (envelope-from robert@fledge.watson.org) Date: Tue, 19 Oct 2004 17:53:07 -0400 (EDT) From: Robert Watson X-Sender: robert@fledge.watson.org To: John Baldwin In-Reply-To: <200410191745.59493.jhb@FreeBSD.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-current@freebsd.org cc: Julian Elischer Subject: Re: Preemption-related bug in propagate_priority(): it's OK to hold Giant but not be running X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 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: Tue, 19 Oct 2004 21:53:20 -0000 On Tue, 19 Oct 2004, John Baldwin wrote: > > it would be relatively simple to put those 'discarded' threads onto a > > single list in the kernel > > and 'c' could put them back on the run queue :-) > > That's a really nasty hack. I almost wonder if we shouldn't just bump > the priority of the thread that panics way up instead, or maybe use a > dedicated thread for handling panics or something. I have to admit I was somewhat surprised to see that a thread was preempted during a panic. I had sort of assumed that as we panicked we disabled interrupts, since the I/O for the debugger is polled, etc. Speaking of which, I've seen a number of bug reports that suggest our polled debugger I/O interfaces for the low level console are not implemented properly by syscons (and maybe also sio), resulting in unnecessary debugging complications (running wakeup() while in DDB and so on). Robert N M Watson FreeBSD Core Team, TrustedBSD Projects robert@fledge.watson.org Principal Research Scientist, McAfee Research