Re: threshold_init_device/kobject_uevent_env oops
From: Greg KH
Date: Sat Jan 26 2008 - 01:24:28 EST
On Fri, Jan 25, 2008 at 03:20:45PM -0800, Yinghai Lu wrote:
> On Jan 25, 2008 3:08 PM, Greg KH <gregkh@xxxxxxx> wrote:
> > On Fri, Jan 25, 2008 at 11:35:56PM +0100, Ingo Molnar wrote:
> ..
> > Also, can someone enable CONFIG_KOBJECT_DEBUG and send me the output of
> > the startup of this code? That should help explain what order things
> > are happening it.
>
> Calling initcall 0xffffffff80ba1dee: threshold_init_device+0x0/0x3f()
> kobject: 'threshold_bank4' (ffff8108265450c0): kobject_add_internal: parent: 'machinecheck0', set: '<NULL>'
> kobject: 'misc0' (ffff810425497418): kobject_add_internal: parent: 'threshold_bank4', set: '<NULL>'
> kobject: 'misc1' (ffff810425497498): kobject_add_internal: parent: 'threshold_bank4', set: '<NULL>'
> kobject: 'misc2' (ffff810425497518): kobject_add_internal: parent: 'threshold_bank4', set: '<NULL>'
> Unable to handle kernel NULL pointer dereference at 0000000000000018 RIP: [<ffffffff8045d443>] kobject_uevent_env+0x31/0x45f
2 of these work just fine, and the third blows up in kobject_uevent().
So wierd, let me dig further...
Hm, it's when we unwind that we blow up on the kobject_uevent, as that's
the first time it is called (gotta love recursion here...) So it is
really never working for these objects at all, what a mess.
As a work-around for now, you can probably just comment out the
'kobject_uevent() in the file arch/x86/kernel/cpu/mcheck/mcd_amd_64.c
and everything should work just fine, as there never really was an event
being properly generated before, no one would miss it now :)
I'll keep digging...
thanks,
greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/