Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1750876Ab0FAEJo (ORCPT ); Tue, 1 Jun 2010 00:09:44 -0400 Received: from mail-yw0-f179.google.com ([209.85.211.179]:63827 "EHLO mail-yw0-f179.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750716Ab0FAEJn (ORCPT ); Tue, 1 Jun 2010 00:09:43 -0400 DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=NmVK81IWSgYiFmOXAYE7qyDdzZCk7eZPurKR1enPq7KiypjrzDQrMDCISh5M6Nnvus G+ZxW2C41jOtI9FY1zrkgDiNCSy3EWsV2YrchVM97y2U4APk3XolJfGy5ymVDo3o0YKJ Kq7a/yAKQcOyMDgE9pQo+C+eWwHtmVdqsvFJQ= MIME-Version: 1.0 In-Reply-To: <20100601031528.GC15411@linux-sh.org> References: <20100601031528.GC15411@linux-sh.org> Date: Mon, 31 May 2010 21:04:42 -0700 Message-ID: Subject: Re: [PATCH v2] printk: fix delayed messages from CPU hotplug events From: Kevin Cernekee To: Paul Mundt Cc: mingo@elte.hu, akpm@linux-foundation.org, simon.kagstrom@netinsight.net, David.Woodhouse@intel.com, rgetz@analog.com, linux-kernel@vger.kernel.org, linux-mips@linux-mips.org Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1313 Lines: 25 On Mon, May 31, 2010 at 8:15 PM, Paul Mundt 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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/