On Fri, Jan 25, 2008 at 03:20:45PM -0800, Yinghai Lu wrote: > On Jan 25, 2008 3:08 PM, Greg KH <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
