Date: Tue, 21 Feb 2006 17:44:00 -0800
From: Andrew Morton <akpm@osdl.org>
To: Stas Sergeev <stsp@aknet.ru>
Cc: linux-kernel@vger.kernel.org
Subject: Re: [patch] Re: 2.6.16-rc4-mm1 (bugs and lockups)
Message-Id: <20060221174400.4542ccbf.akpm@osdl.org>
In-Reply-To: <43FB5317.60501@aknet.ru>
References: <43FB5317.60501@aknet.ru>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1307
Lines: 35

Stas Sergeev <stsp@aknet.ru> wrote:
>
> main.c: moved smp_prepare_boot_cpu() call earlier. This
>  was necessary because otherwise printk() can't print
>  It checks cpu_online(), which returns false. This change
>  is consistent with the UP case, where's the boot CPU is
>  "online" from the very beginning, AFAICS. But again, I am
>  not entirely sure whether this is safe.
> 

Yeah, this is scary.  Early boot is fragile and complex and architectures
might not expect to run smp_prepare_boot_cpu() before setup_arch().

umm, actually it's wrong.  i386's smp_prepare_boot_cpu() diddles with
per-cpu memory, and that's not initialised at that stage.  See the call to
setup_per_cpu_areas() a few lines later.

So I'll drop that hunk.  How important is it in practice?

If it's purely to make printk print something then perhaps we can do
something expedient like:

#ifdef CONFIG_SMP
	cpu_set(smp_processor_id(), cpu_online_map);	/* comment */
#endif

right there in start_kernel()?

(That assumes that smp_processor_id() works at that stage.  Surely that's
true).
-
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/