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 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,
> > > + _kset->kobj,
> > > NULL);
> > >
> > > We should not join the kset, only use
> >
> > Care to try this:
> > + system_kset = kset_create_and_register("system", NULL,
> > + _kset->kobj, NULL);
> >
> > We should not join the kset, only use it as a parent.
>
> Yes, that fixes the problem for me!
>
> Can anyone else
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()
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
>>>> 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 I ref
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 ;)
Fortunately, my ia
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
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,
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 ;)
Fortun
; >
> > 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 - seem
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 ;)
But what does "during 2.6.24 cycle (2)" mean? Some kern
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
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
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? Some kernel other than
2.6.24-rc2-mm1 is crashing
[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 ;)
But what does during 2.6.24 cycle (2
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 ;)
Fortunately, my ia64 box reproduces this oops every time.
So, I could chase it.
device_shutdown
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_kset-list,
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 way
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 ;)
Fortunately, my ia64 box
) 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 I referred to in the releaee
notes. Greg is pondering the problem - seem he's
[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 ;)
Fortunately, my ia64 box
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 code now uses
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
) 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 I referred to in the releaee
notes. Greg is pondering the problem - seem he's the only person who
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
Yes, all my test boxes did that - it's what I referred
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
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
Yes, all my test boxes did that - it's what I referred
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 else verify this?
I
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, only use it as a parent.
36 matches
Mail list logo
