[lkml]   [2008]   [Jun]   [24]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: v2.6.26-rc7: BUG: unable to handle kernel NULL pointer dereference
On Tue, Jun 24, 2008 at 10:06 AM, Zhang, Yanmin
<> wrote:
> In function _cpu_up, the panic happens when calling __raw_notifier_call_chain
> at the second time. Kernel doesn't panic when calling it at the first time. If
> just say because of nr_cpu_ids, that's not right.
> By checking source codes, I find function do_boot_cpu is the culprit.
> Consider below call chain:
> _cpu_up=>__cpu_up=>smp_ops.cpu_up=>native_cpu_up=>do_boot_cpu.
> So do_boot_cpu is called in the end. In do_boot_cpu, if boot_error==true,
> cpu_clear(cpu, cpu_possible_map) is executed. So later on, when _cpu_up
> calls __raw_notifier_call_chain at the second time to report CPU_UP_CANCELED,
> because this cpu is already cleared from cpu_possible_map, get_cpu_sysdev returns

Ahhha! Well done!

(Whew, I have a lot to learn :-D)

> Many resources are related to cpu_possible_map, so it's better not to change it.
> Below patch against 2.6.26-rc7 fixes it by removing the bit clearing in cpu_possible_map.
> Vegard, would you like to help test it?

Sure, but it can take a while. 1) I have no idea why the processor
failed to initialize in the first place. So far, it only ever happened
this one time. 2) There seems to be a couple of other failure cases
related to cpu hotplug (usually the machine freezes hard), so it's not
certain that we hit this (failed to initialize) first. But I will try!

Thanks for solving the mystery.


"The animistic metaphor of the bug that maliciously sneaked in while
the programmer was not looking is intellectually dishonest as it
disguises that the error is the programmer's own creation."
-- E. W. Dijkstra, EWD1036
 \ /
  Last update: 2008-06-24 10:41    [W:0.077 / U:1.500 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site