From: Kevin Cernekee <cernekee@gmail.com>
To: Ralf Baechle <ralf@linux-mips.org>
Cc: <linux-mips@linux-mips.org>, <linux-kernel@vger.kernel.org>
Subject: [PATCH 2/2] MIPS: Fix deferred console messages during CPU hotplug
Date: Sun, 30 May 2010 00:35:58 -0700 [thread overview]
Message-ID: <526fcbfa605500d9da9b04ac0f93ef2beddca6ed@localhost.localdomain> (raw)
In-Reply-To: <1b31306f28573a4bee56f164b1f74962fced9bc5@localhost.localdomain>
When a secondary CPU is booting up in start_secondary(), cpu_probe() and
calibrate_delay() are called while cpu_online(smp_processor_id()) == 0.
This means that can_use_console() will return 0 on many systems:
static inline int can_use_console(unsigned int cpu)
{
return cpu_online(cpu) || have_callable_console();
}
If (can_use_console() == 0), printk() will spool its output to log_buf
and it will be visible in "dmesg", but that output will NOT be echoed to
the console until somebody calls release_console_sem() from a CPU that
is online. Effectively this means that the cpu_probe() and
calibrate_delay() messages will sit in limbo, and will only get dumped
to the screen the next time printk() happens to get called.
At boot time, more printk() messages are invariably generated after SMP
initialization as the kernel boot proceeds, so this problem is unlikely
to be noticed. But when using the CPU hotplug feature to reactivate a
dormant processor, the new CPU's boot messages could be stuck in limbo
for quite a while since nothing is necessarily printed to the kernel log
afterward.
The proposed workaround is to acquire and release console_sem from
__cpu_up(), so any queued messages can be flushed out to the console by
a CPU that is definitely known to be online.
This issue was seen on 2.6.34.
Signed-off-by: Kevin Cernekee <cernekee@gmail.com>
---
arch/mips/kernel/smp.c | 5 +++++
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/arch/mips/kernel/smp.c b/arch/mips/kernel/smp.c
index 6cdca19..bf8923f 100644
--- a/arch/mips/kernel/smp.c
+++ b/arch/mips/kernel/smp.c
@@ -33,6 +33,7 @@
#include <linux/cpu.h>
#include <linux/err.h>
#include <linux/ftrace.h>
+#include <linux/console.h>
#include <asm/atomic.h>
#include <asm/cpu.h>
@@ -219,6 +220,10 @@ int __cpuinit __cpu_up(unsigned int cpu)
cpu_set(cpu, cpu_online_map);
+ /* Flush out any buffered log messages from the new CPU */
+ if (try_acquire_console_sem() == 0)
+ release_console_sem();
+
return 0;
}
--
1.7.0.4
next prev parent reply other threads:[~2010-05-30 7:50 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-05-30 7:32 [PATCH 1/2] MIPS: pfn_valid() is broken on low memory HIGHMEM systems Kevin Cernekee
2010-05-30 7:35 ` Kevin Cernekee [this message]
2010-05-31 4:41 ` [PATCH 2/2] MIPS: Fix deferred console messages during CPU hotplug Paul Mundt
2011-05-19 11:48 ` [PATCH 1/2] MIPS: pfn_valid() is broken on low memory HIGHMEM systems Ralf Baechle
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=526fcbfa605500d9da9b04ac0f93ef2beddca6ed@localhost.localdomain \
--to=cernekee@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mips@linux-mips.org \
--cc=ralf@linux-mips.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®