On Thu, 15 Nov 2007 17:22:11 -0800,
Greg KH <[EMAIL PROTECTED]> wrote:
> On Fri, Nov 16, 2007 at 10:13:42AM +0900, Yasunori Goto wrote:
> > > >
> > > > Care to try this:
> > > > + system_kset = kset_create_and_register("system", NULL,
> > > > +
On Fri, Nov 16, 2007 at 10:13:42AM +0900, Yasunori Goto wrote:
> > >
> > > Care to try this:
> > > + system_kset = kset_create_and_register("system", NULL,
> > > + &devices_kset->kobj,
> > > NULL);
> > >
> > > We should not join the kset, on
> >
> > Care to try this:
> > + system_kset = kset_create_and_register("system", NULL,
> > + &devices_kset->kobj, NULL);
> >
> > We should not join the kset, only use it as a parent.
>
> Yes, that fixes the problem for me!
>
> Can anyone el
AIL PROTECTED]>
> > > > wrote:
> > > >
> > > > > Three boxes rarely oops during reboot or poweroff with 2.6.24-rc2-mm1
> > > > > (1) and during 2.6.24 cycle (2):
> > > > >
> > > > > kernel_restart
> > > > &g
Greg KH wrote:
On Thu, Nov 15, 2007 at 01:29:04PM -0500, Mark Lord wrote:
Greg KH wrote:
On Thu, Nov 15, 2007 at 12:07:48PM -0500, Mark Lord wrote:
..
Greg, I don't know if this is relevant or not,
but x86 has bugs in the halt/reboot code for SMP.
Specifically, in native_smp_send_stop() the
AIL PROTECTED]>
> > > > wrote:
> > > >
> > > > > Three boxes rarely oops during reboot or poweroff with 2.6.24-rc2-mm1
> > > > > (1) and during 2.6.24 cycle (2):
> > > > >
> > > > > kernel_restart
> > > > &g
On Thu, Nov 15, 2007 at 01:29:04PM -0500, Mark Lord wrote:
> Greg KH wrote:
>> On Thu, Nov 15, 2007 at 12:07:48PM -0500, Mark Lord wrote:
> ..
>>> Greg, I don't know if this is relevant or not,
>>> but x86 has bugs in the halt/reboot code for SMP.
>>>
>>> Specifically, in native_smp_send_stop() the
Greg KH wrote:
On Thu, Nov 15, 2007 at 12:07:48PM -0500, Mark Lord wrote:
..
Greg, I don't know if this is relevant or not,
but x86 has bugs in the halt/reboot code for SMP.
Specifically, in native_smp_send_stop() the code now uses
spin_trylock() to "lock" the shared call buffers,
but then ign
gt;>> Three boxes rarely oops during reboot or poweroff with 2.6.24-rc2-mm1
>>>>> (1) and during 2.6.24 cycle (2):
>>>>>
>>>>> kernel_restart
>>>>> sys_reboot
>>>>> [garbage]
>>>>> Code: 8b 88 a
rarely oops during reboot or poweroff with 2.6.24-rc2-mm1
> > > > (1) and during 2.6.24 cycle (2):
> > > >
> > > > kernel_restart
> > > > sys_reboot
> > > > [garbage]
> > > > Code: 8b 88 a8 00 00 00 85 c9 74 04 89
&g
; > > (1) and during 2.6.24 cycle (2):
> > >
> > > kernel_restart
> > > sys_reboot
> > > [garbage]
> > > Code: 8b 88 a8 00 00 00 85 c9 74 04 89
> > > EIP is at device_shutdown+0x32/0x60
> >
> > Yes, all my test boxes did that - it's what
estart
sys_reboot
[garbage]
Code: 8b 88 a8 00 00 00 85 c9 74 04 89
EIP is at device_shutdown+0x32/0x60
Yes, all my test boxes did that - it's what I referred to in the releaee
notes. Greg is pondering the problem - seem he's the only person who
cannot reproduce it ;)
Fortunat
On Thu, Nov 15, 2007 at 01:44:46AM -0800, Andrew Morton wrote:
> Yes, all my test boxes did that - it's what I referred to in the releaee
> notes. Greg is pondering the problem - seem he's the only person who
> cannot reproduce it ;)
UML does it reliably too, in case Greg is still looking for a w
On Thu, 15 Nov 2007 21:55:34 +0900,
Yasunori Goto <[EMAIL PROTECTED]> wrote:
> /**
> * device_shutdown - call ->shutdown() on each device to shutdown.
> */
> void device_shutdown(void)
> {
> struct device * dev, *devn;
>
> list_for_each_entry_safe_reverse(dev, devn, &devices_kse
garbage]
> > Code: 8b 88 a8 00 00 00 85 c9 74 04 89
> > EIP is at device_shutdown+0x32/0x60
>
> Yes, all my test boxes did that - it's what I referred to in the releaee
> notes. Greg is pondering the problem - seem he's the only person who
> cannot reproduce it
; >
> > kernel_restart
> > sys_reboot
> > [garbage]
> > Code: 8b 88 a8 00 00 00 85 c9 74 04 89
> > EIP is at device_shutdown+0x32/0x60
>
> Yes, all my test boxes did that - it's what I referred to in the releaee
> notes. Greg is pondering the problem -
00 85 c9 74 04 89
> EIP is at device_shutdown+0x32/0x60
Yes, all my test boxes did that - it's what I referred to in the releaee
notes. Greg is pondering the problem - seem he's the only person who
cannot reproduce it ;)
But what does "during 2.6.24 cycle (2)" mean?
Three boxes rarely oops during reboot or poweroff with 2.6.24-rc2-mm1
(1) and during 2.6.24 cycle (2):
kernel_restart
sys_reboot
[garbage]
Code: 8b 88 a8 00 00 00 85 c9 74 04 89
EIP is at device_shutdown+0x32/0x60
which corresponds to the following place:
c110659c
18 matches
Mail list logo
