On Wed, 23 Jan 2008, Daniel Walker wrote: > > > 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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/