From: Stas Sergeev <stsp@aknet.ru>
To: Andrew Morton <akpm@osdl.org>
Cc: linux-kernel@vger.kernel.org
Subject: Re: [patch] Re: 2.6.16-rc4-mm1 (bugs and lockups)
Date: Wed, 22 Feb 2006 18:51:19 +0300 [thread overview]
Message-ID: <43FC8877.4020300@aknet.ru> (raw)
In-Reply-To: <20060221174400.4542ccbf.akpm@osdl.org>
[-- Attachment #1: Type: text/plain, Size: 1320 bytes --]
Hello.
Andrew Morton wrote:
> 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?
It was important because it used to fix both the printk and
(completely accidentally!) the boot problem itself.
> #ifdef CONFIG_SMP
> cpu_set(smp_processor_id(), cpu_online_map); /* comment */
> #endif
I don't even think #ifdef is needed. Having that for the UP
case may be useless, yet looks consistent to me.
> right there in start_kernel()?
This is enough for printk but not for the boot lockup.
The attached patch is however enough. And it should be
correct, as it is consistent with an UP case.
> (That assumes that smp_processor_id() works at that stage. Surely that's
> true).
Looking into the arch-specific code, I can see that some
arches evaluate the boot-cpu number by some other means,
not by the smp_processor_id(). Still I am pretty sure the
patch won't hurt them.
With this patch and with the hotfixes, I've got the -mm
kernel working, thanks.
----
Register the boot-cpu in the cpu maps earlier to allow the
early printk to work, and to fix an obscure deadlock at boot.
Signed-off-by: Stas Sergeev <stsp@aknet.ru>
[-- Attachment #2: smpb.diff --]
[-- Type: text/x-patch, Size: 981 bytes --]
--- a/init/main.c 2006-02-21 10:36:04.000000000 +0300
+++ b/init/main.c 2006-02-22 11:30:01.000000000 +0300
@@ -440,6 +440,15 @@
* Activate the first processor.
*/
+static void boot_cpu_init(void)
+{
+ int cpu = smp_processor_id();
+ /* Mark the boot cpu "present", "online" etc for SMP and UP case */
+ cpu_set(cpu, cpu_online_map);
+ cpu_set(cpu, cpu_present_map);
+ cpu_set(cpu, cpu_possible_map);
+}
+
asmlinkage void __init start_kernel(void)
{
char * command_line;
@@ -449,17 +458,13 @@
* enable them
*/
lock_kernel();
+ boot_cpu_init();
page_address_init();
printk(KERN_NOTICE);
printk(linux_banner);
setup_arch(&command_line);
setup_per_cpu_areas();
-
- /*
- * Mark the boot cpu "online" so that it can call console drivers in
- * printk() and can access its per-cpu storage.
- */
- smp_prepare_boot_cpu();
+ smp_prepare_boot_cpu(); /* arch-specific boot-cpu hooks */
/*
* Set up the scheduler prior starting any interrupts (such as the
prev parent reply other threads:[~2006-02-22 15:51 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-02-21 17:51 [patch] Re: 2.6.16-rc4-mm1 (bugs and lockups) Stas Sergeev
2006-02-22 1:31 ` Andrew Morton
2006-02-22 1:44 ` Andrew Morton
2006-02-22 15:51 ` Stas Sergeev [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=43FC8877.4020300@aknet.ru \
--to=stsp@aknet.ru \
--cc=akpm@osdl.org \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.