On Wed, 23 Jan 2008, Daniel Walker wrote:

quoted text
>
> > 	if (wake_klogd && !runqueue_is_locked())
> > 		wake_up_klogd();
> >
> > This probably is the cleanest solution since it simply prevents the
> > deadlock from occurring.
>
> Do you really need to call it with the runqueue lock held .. There are
> other issue with the calls at that level.. For instance in -rt these
> call can actually hang the system in the console laying from inside
> printk (something I reported more than 6 months ago) .. It would be
> better to move them around the scheduler rather than inside it..

The wakeup hook in schedule is when we find out that we hit our max. I
could postpone that somehow, but that would require more glue code than I
would like to add.

As for -rt, we've disabled printk for consoles not ATOMIC safe. So the
only consoles that will print in atomic sections so far are, earlyprintk
and the VGA.

Tim, could you send me your "postponed print" patches. That sounds like
something the -rt patch could use.

Thanks,

-- Steve

--
unsubscribe notice
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/