Re: [PATCH] 2.4.16 kernel/printk.c (per processor initialization check)

Andrew Morton (akpm@zip.com.au)
Mon, 03 Dec 2001 01:20:28 -0800


j-nomura@ce.jp.nec.com wrote:
>
> Hello,
>
> I experienced system hang on my SMP machine and it turned out to be due to
> console write before mmu initialization completes.
>
> To be more specific, even if secondary processors are not in status enough
> to do actual console I/O (e.g. mmu is not initialized), call_console_drivers()
> tries to do it.
> This leads to unpredictable result. For me, for example, it cause machine
> check abort and hang up system.
>
> Attached is a patch for it.
>
> --- kernel/printk.c 2001/11/27 04:41:49 1.1.1.8
> +++ kernel/printk.c 2001/12/03 05:25:26
> @@ -491,20 +491,22 @@
> */
> void release_console_sem(void)
> {
> unsigned long flags;
> unsigned long _con_start, _log_end;
> unsigned long must_wake_klogd = 0;
>
> for ( ; ; ) {
> spin_lock_irqsave(&logbuf_lock, flags);
> must_wake_klogd |= log_start - log_end;
> + if (!(cpu_online_map & 1UL << smp_processor_id()))
> + break;
> if (con_start == log_end)
> break; /* Nothing to print */
> _con_start = con_start;
> _log_end = log_end;
> con_start = log_end; /* Flush */
> spin_unlock_irqrestore(&logbuf_lock, flags);
> call_console_drivers(_con_start, _log_end);
> }
> console_may_schedule = 0;
> up(&console_sem);
>

Seems that there is some sort of ordering problem here - someone
is calling printk before the MMU is initialised, but after some
console drivers have been installed.

I suspect the real fix is elsewhere, but I'm not sure where.

Probably a clearer place to put this test would be within
printk itself, immediately before the down_trylock. Does that
work?

-
-
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/