From: Andrew Morton <akpm@linux-foundation.org>
To: "Shilimkar, Santosh" <santosh.shilimkar@ti.com>
Cc: Kevin Cernekee <cernekee@gmail.com>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
Russell King - ARM Linux <linux@arm.linux.org.uk>
Subject: Re: Additional fix : (was [v2]printk: fix delayed messages from CPU hotplug events)
Date: Mon, 2 Aug 2010 15:44:34 -0700 [thread overview]
Message-ID: <20100802154434.5615bcf9.akpm@linux-foundation.org> (raw)
In-Reply-To: <EAF47CD23C76F840A9E7FCE10091EFAB02C5DB6D1F@dbde02.ent.ti.com>
On Tue, 29 Jun 2010 14:22:26 +0530
"Shilimkar, Santosh" <santosh.shilimkar@ti.com> wrote:
> Hi,
>
> I have faced similar issue as what is being described in below with
> latest kernel.
>
> ------------------------------------------------
> https://patchwork.kernel.org/patch/103347/
>
> When a secondary CPU is being brought up, it is not uncommon for
> printk() to be invoked when cpu_online(smp_processor_id()) == 0. The
> case that I witnessed personally was on MIPS:
>
> http://lkml.org/lkml/2010/5/30/4
>
> 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. Therefore, the boot time messages from the new CPU can get
> stuck in "limbo" for a long time, and might suddenly appear on the
> screen when a completely unrelated event (e.g. "eth0: link is down")
> occurs.
>
> This patch modifies the console code so that any pending messages are
> automatically flushed out to the console whenever a CPU hotplug
> operation completes successfully or aborts.
>
> -----------------------------------------------
>
> Above patch fixes only half of the problem. I mean the cpu online
> path prints are coming on the console.
>
> But similar problem also exist if there are prints in the cpu offline
> path. I got that fixed by adding below patch on top of you patch.
>
> diff --git a/kernel/printk.c b/kernel/printk.c
> index d370b74..f4d7352 100644
> --- a/kernel/printk.c
> +++ b/kernel/printk.c
> @@ -982,6 +982,9 @@ static int __cpuinit console_cpu_notify(struct notifier_bloc
> switch (action) {
> case CPU_ONLINE:
> case CPU_UP_CANCELED:
> + case CPU_DEAD:
> + case CPU_DYING:
> + case CPU_DOWN_FAILED:
> if (try_acquire_console_sem() == 0)
> release_console_sem();
> }
The patch lacked a suitable title. I called it "console: flush log
messages for more cpu-hotplug events".
The patch lacks a Signed-off-by:. Please send one.
The patch has its tabs replaced with spaces. I fixed that. Please
reconfigure your email client for next time.
The code which is being patch has changed. It now does
acquire_console_sem();
release_console_sem();
so the code may no longer work - perhaps it now deadlocks (unlikely).
Please retest?
Finally, I don't understand the patch :( Who is sending out CPU_DEAD,
CPU_DYING or CPU_DOWN_FAILED events during kernel boot? I'd have
thought that those events simply aren't occurring, and that the patch
has no effect. Confused - please explain further.
next prev parent reply other threads:[~2010-08-02 22:44 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-06-29 8:52 Additional fix : (was [v2]printk: fix delayed messages from CPU hotplug events) Shilimkar, Santosh
2010-08-02 22:44 ` Andrew Morton [this message]
2010-08-03 7:33 ` Shilimkar, Santosh
2010-08-03 15:24 ` Randy Dunlap
2010-08-03 16:53 ` Shilimkar, Santosh
2010-08-03 23:59 ` Andrew Morton
2010-08-04 3:30 ` Paul Mundt
2010-08-04 13:51 ` Ralf Baechle
2010-08-04 15:23 ` Ralf Baechle
-- strict thread matches above, loose matches on Subject: below --
2010-07-01 4:27 Shilimkar, Santosh
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=20100802154434.5615bcf9.akpm@linux-foundation.org \
--to=akpm@linux-foundation.org \
--cc=cernekee@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux@arm.linux.org.uk \
--cc=santosh.shilimkar@ti.com \
/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