[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <AANLkTinY8Htz2bb2I_oN5iWtAjxuDkGzAvX_4TbtmKBh@mail.gmail.com>
Date: Mon, 31 May 2010 21:04:42 -0700
From: Kevin Cernekee <cernekee@...il.com>
To: Paul Mundt <lethal@...ux-sh.org>
Cc: mingo@...e.hu, akpm@...ux-foundation.org,
simon.kagstrom@...insight.net, David.Woodhouse@...el.com,
rgetz@...log.com, linux-kernel@...r.kernel.org,
linux-mips@...ux-mips.org
Subject: Re: [PATCH v2] printk: fix delayed messages from CPU hotplug events
On Mon, May 31, 2010 at 8:15 PM, Paul Mundt <lethal@...ux-sh.org> wrote:
> If this is to be entirely restricted to CPU hotplug then you could use
> the hotcpu notifier here instead of the open-coded cpu notifier directly,
> the former wraps to the latter in the CPU hotplug case and is simply a
> nop for the regular SMP case.
I ran some tests and saw the same problem during the regular MIPS SMP
boot. i.e. adding "while (1) { }" at the end of __cpu_up() prevents
any of the probing/calibration messages originating on CPU1 from ever
being echoed to the console. Adding the semaphore code before the
while loop caused the CPU1 messages to reappear.
Under normal circumstances you won't ever notice the problem at boot
time, because printing "Brought up %ld CPUs" has the undocumented side
effect of flushing out any messages that got stuck during SMP init.
And if that printk() wasn't there, the next one (from NET, PCI, SCSI,
...) would surely take its place.
But in the case of MIPS CPU hotplug, there is no such printk() at the
end, and so our luck runs out.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists