Preemption-related bug in propagate_priority(): it's OK to hold Giant but not be running

[Robert Watson]

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 at fledge.watson.org      Principal Research Scientist, McAfee Research