public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Shaohua Li <shaohua.li@intel.com>
To: akpm <akpm@osdl.org>, Pavel Machek <pavel@ucw.cz>
Cc: lkml <linux-kernel@vger.kernel.org>
Subject: Hotplug CPU printk issue
Date: Thu, 26 May 2005 10:58:54 +0800	[thread overview]
Message-ID: <1117076334.4086.11.camel@linux-hp.sh.intel.com> (raw)
In-Reply-To: <1113467253.2568.10.camel@sli10-desk.sh.intel.com>

On Thu, 2005-04-14 at 16:27 +0800, Li Shaohua wrote:
> On Wed, 2005-04-13 at 16:32, Pavel Machek wrote: 
> > root@hobit:/sys/devices/system/cpu/cpu1# dmesg | tail -25 
> >  [<c011d001>] activate_task+0x1/0xa0 
> >  [<c011d128>] resched_task+0x68/0x90 
> >  [<c011d8ba>] try_to_wake_up+0x2aa/0x2f0 
> >  [<c025ed7a>] fbcon_cursor+0x19a/0x270 
> >  [<c02c4958>] hide_cursor+0x18/0x30 
> >  [<c02c758f>] vt_console_print+0x24f/0x260 
> >  [<c02c7340>] vt_console_print+0x0/0x260 
> >  [<c01247e7>] __call_console_drivers+0x57/0x60 
> >  [<c01248e0>] call_console_drivers+0x80/0x110 
> >  [<c0124d8e>] release_console_sem+0x4e/0xc0 
> >  [<c0124c12>] vprintk+0x192/0x240 
> >  [<c0528891>] preempt_schedule_irq+0x51/0x80 
> >  [<c02adeca>] acpi_processor_idle+0x0/0x265 
> >  [<c010325e>] need_resched+0x1f/0x21 
> >  [<c02adeca>] acpi_processor_idle+0x0/0x265 
> >  [<c0124a77>] printk+0x17/0x20 
> >  [<c010b583>] cpu_init+0x73/0x360 
> >  [<c0117bd6>] start_secondary+0x6/0x170 
> > Code: d2 74 bd fc 8b 44 24 28 b9 0e 00 00 00 8b 74 24 14 01 c6 b8
> 0e 
> > 00 00 00 89 74 24 1c 8b 74 24 30 89 44 24 10 8b 7c 24 1c 83 c6 10
> <f3> 
> > a5 8b 74 24 24 8b 44 24 1c 89 4c 24 10 01 ee f7 d5 21 ee 89 
> >  <0>Kernel panic - not syncing: Attempted to kill the idle task! 
> >  Stuck ?? 
> > Inquiring remote APIC #0... 
> > ... APIC #0 ID: 00000000 
> > ... APIC #0 VERSION: 00040011 
> > ... APIC #0 SPIV: 000000ff 
> > root@hobit:/sys/devices/system/cpu/cpu1# 
> Andrew, 
> Below patch fixed Pavel's oops. But strange is the 'system_state'
> check 
> is added for CPU hotplug by Rusty. This really makes me confused.
> Could 
> you please look at it. 
> This can be reproduced 100% with radeonfb driver load. Attached is
> the 
> dmesg of an oops. It seems the 'objp' parameter for 
> 'cache_alloc_debugcheck_after' is invalid.
> 
> Thanks, 
> Shaohua
> 
> --- a/kernel/printk.c   2005-04-12 10:12:19.000000000 +0800 
> +++ b/kernel/printk.c   2005-04-13 17:22:40.912897328 +0800 
> @@ -624,8 +624,7 @@ asmlinkage int vprintk(const char *fmt,  
>                         log_level_unknown = 1; 
>         } 
>   
> -       if (!cpu_online(smp_processor_id()) && 
> -           system_state != SYSTEM_RUNNING) { 
> +       if (!cpu_online(smp_processor_id())) { 
>                 /* 
>                  * Some console drivers may assume that per-cpu resources have 
>                  * been allocated.  So don't allow them to be called by this
Andrew,
Could above patch be put into mm tree? It fixes the oops of CPU hotplug
with radeon fb enabled.
The reason is the per-cpu data (radeon fb calls kmalloc) isn't
initialized when CPU hotplug is processing. system_state is
SYSTEM_RUNNING for cpu hotplug.

Thanks,
Shaohua


  parent reply	other threads:[~2005-05-26  2:52 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-04-12  5:31 [PATCH 6/6]suspend/resume SMP support Li Shaohua
2005-04-12  9:43 ` Pavel Machek
2005-04-12 10:51 ` Pavel Machek
2005-04-12 12:40   ` Li Shaohua
2005-04-13  8:32     ` Pavel Machek
2005-04-14  8:27       ` Li Shaohua
2005-04-14  8:40         ` Li Shaohua
2005-04-23 22:35         ` Andrew Morton
2005-04-23 22:41           ` Pavel Machek
2005-04-25  0:49           ` Li Shaohua
2005-05-26  2:58         ` Shaohua Li [this message]
2005-05-26  3:48           ` Hotplug CPU printk issue Andrew Morton
2005-05-26  5:43             ` Shaohua Li
2005-05-26  5:52               ` Andrew Morton
2005-05-26 19:32                 ` David Mosberger
2005-05-27  2:08                   ` Rusty Russell
2005-04-28  7:22 ` [PATCH 6/6]suspend/resume SMP support Andrew Morton
2005-04-28  7:28   ` Li Shaohua
2005-04-28  7:41     ` Andrew Morton
2005-04-28  8:29       ` Li Shaohua
2005-04-28  8:35         ` Pavel Machek
2005-04-28  9:04           ` [ACPI] " Rafael J. Wysocki
2005-04-28  7:35   ` Li Shaohua
2005-04-28  7:42     ` Pavel Machek
2005-04-28  8:11       ` [ACPI] " Yu, Luming
2005-04-28  8:20         ` Pavel Machek
2005-04-28  8:34           ` Yu, Luming

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=1117076334.4086.11.camel@linux-hp.sh.intel.com \
    --to=shaohua.li@intel.com \
    --cc=akpm@osdl.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=pavel@ucw.cz \
    /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