lkml.org 
[lkml]   [2009]   [Apr]   [14]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [BISECTED] EEE PC hangs when booting off battery
Bjorn Helgaas wrote:
> On Monday 13 April 2009 01:57:00 pm Alan Jenkins wrote:
>
>> Bjorn Helgaas wrote:
>>
>>> On Sunday 12 April 2009 07:11:57 am Alan Jenkins wrote:
>>>
>>> You mention that this occurs when booting off battery. So I
>>> assume everything works fine when the EEE is plugged in to the
>>> wall socket?
>>>
>> When I tested it before, that was what I found.
>>
>> However, I now find that's not quite right. It only works (i.e. doesn't
>> hang) if I remove the battery as well as plugging it into the wall. If
>> I have the battery in, it hangs.
>>

... and right now, I can only reproduce it by booting with it plugged
into the wall and the battery present. If I unplug it from the wall, it
boots fine.

It must be affected by something else as well, maybe battery level or
charging / discharging status.

>>>>>>> Magic SysRQ keys work though. ...
>>>>>>>
>>>>>>>
>>>>> I was able to run SysRq-P, and found the following backtrace -
>>>>>
>>>>> Pid: 0
>>>>> EIP is at acpi_idle_enter_bm+0x1df/0x208 [processor]
>>>>>
>>> Can you figure out where this is in acpi_idle_enter_bm() or
>>> maybe just email me your processor.ko module?
>>>
>>> Does it always happen at the same point?
>>>
>> Yes, it always happens at the same point.
>>
>> It turns out I can read the runes, but I don't understand what they're
>> saying :-).
>>
>
> I'm not much good with x86 assembly either :-)
>
> I think that in both cases below, you're right after enabling
> interrupts and about to exit the idle routine. My guess is the
> system is not really hung; it just doesn't think it has anything
> to do and is spending all its time in the idle loop.
>
>
>> 00001bd0 <acpi_idle_enter_bm>:
>>
>> ...
>> 00001bd0 + 0x1df = 00001daf
>> ...
>> 1d70: b8 03 00 00 00 mov $0x3,%eax
>> 1d75: e8 90 f3 ff ff call 110a <tsc_halts_in_c>
>> 1d7a: 85 c0 test %eax,%eax
>> 1d7c: 74 0a je 1d88 <acpi_idle_enter_bm+0x1b8>
>> 1d7e: b8 0e 09 00 00 mov $0x90e,%eax
>> 1d7f: R_386_32 .rodata.str1.1
>> 1d83: e8 fc ff ff ff call 1d84 <acpi_idle_enter_bm+0x1b4>
>> 1d84: R_386_PC32 mark_tsc_unstable
>> 1d88: 8b 45 e8 mov -0x18(%ebp),%eax
>> 1d8b: 8b 55 ec mov -0x14(%ebp),%edx
>> 1d8e: e8 ab fd ff ff call 1b3e <us_to_pm_timer_ticks>
>> 1d93: 89 c3 mov %eax,%ebx
>> 1d95: b8 17 01 00 00 mov $0x117,%eax
>> 1d9a: 69 ca 17 01 00 00 imul $0x117,%edx,%ecx
>> 1da0: 89 d6 mov %edx,%esi
>> 1da2: f7 e3 mul %ebx
>> 1da4: 8d 14 11 lea (%ecx,%edx,1),%edx
>> 1da7: e8 fc ff ff ff call 1da8 <acpi_idle_enter_bm+0x1d8>
>> 1da8: R_386_PC32 sched_clock_idle_wakeup_event
>> 1dac: fb sti
>> 1dad: 89 e0 mov %esp,%eax
>> -> 1daf: 31 c9 xor %ecx,%ecx <---------
>> 1db1: 25 00 e0 ff ff and $0xffffe000,%eax
>> 1db6: 89 fa mov %edi,%edx
>> 1db8: 83 48 0c 04 orl $0x4,0xc(%eax)
>> 1dbc: ff 47 18 incl 0x18(%edi)
>> 1dbf: 8b 45 e4 mov -0x1c(%ebp),%eax
>> 1dc2: e8 a4 f5 ff ff call 136b <acpi_state_timer_broadcast>
>> 1dc7: 01 5f 1c add %ebx,0x1c(%edi)
>> 1dca: 11 77 20 adc %esi,0x20(%edi)
>> 1dcd: 8b 45 e8 mov -0x18(%ebp),%eax
>> 1dd0: 83 c4 10 add $0x10,%esp
>> 1dd3: 5b pop %ebx
>> 1dd4: 5e pop %esi
>> 1dd5: 5f pop %edi
>> 1dd6: 5d pop %ebp
>> 1dd7: c3 ret
>>
>>
>>> If you blacklist or rename the processor module to prevent it
>>> from loading, does that keep the hang from occurring?
>>>
>> No. In that case I get the hang in default_idle+0x59/0x95
>>
>> 0000007a <default_idle>:
>> 7a: 55 push %ebp
>> 7b: 89 e5 mov %esp,%ebp
>> 7d: 56 push %esi
>> 7e: 53 push %ebx
>> 7f: 83 ec 18 sub $0x18,%esp
>> 82: 83 3d 18 00 00 00 00 cmpl $0x0,0x18
>> 84: R_386_32 .bss
>> 89: 75 7a jne 105 <default_idle+0x8b>
>> 8b: 80 3d 05 00 00 00 00 cmpb $0x0,0x5
>> 8d: R_386_32 boot_cpu_data
>> 92: 74 71 je 105 <default_idle+0x8b>
>> 94: 83 3d 04 00 00 00 00 cmpl $0x0,0x4
>> 96: R_386_32 __tracepoint_power_start
>> 9b: 74 23 je c0 <default_idle+0x46>
>> 9d: 8b 1d 08 00 00 00 mov 0x8,%ebx
>> 9f: R_386_32 __tracepoint_power_start
>> a3: 85 db test %ebx,%ebx
>> a5: 74 19 je c0 <default_idle+0x46>
>> a7: 8d 75 e0 lea -0x20(%ebp),%esi
>> aa: b9 01 00 00 00 mov $0x1,%ecx
>> af: ba 01 00 00 00 mov $0x1,%edx
>> b4: 89 f0 mov %esi,%eax
>> b6: ff 13 call *(%ebx)
>> b8: 83 c3 04 add $0x4,%ebx
>> bb: 83 3b 00 cmpl $0x0,(%ebx)
>> be: 75 ea jne aa <default_idle+0x30>
>> c0: 89 e0 mov %esp,%eax
>> c2: 25 00 e0 ff ff and $0xffffe000,%eax
>> c7: 83 60 0c fb andl $0xfffffffb,0xc(%eax)
>> cb: f6 40 08 08 testb $0x8,0x8(%eax)
>> cf: 75 04 jne d5 <default_idle+0x5b>
>> d1: fb sti
>> d2: f4 hlt
>> --> d3: eb 01 jmp d6 <default_idle+0x5c> <--------
>> d5: fb sti
>> d6: 89 e0 mov %esp,%eax
>> d8: 25 00 e0 ff ff and $0xffffe000,%eax
>> dd: 83 48 0c 04 orl $0x4,0xc(%eax)
>> e1: 83 3d 04 00 00 00 00 cmpl $0x0,0x4
>> e3: R_386_32 __tracepoint_power_end
>> e8: 74 1e je 108 <default_idle+0x8e>
>>
>>
>>
>>>> 7ec0a7290797f57b780f792d12f4bcc19c83aa4f is first bad commit
>>>> commit 7ec0a7290797f57b780f792d12f4bcc19c83aa4f
>>>> Author: Bjorn Helgaas <bjorn.helgaas@hp.com>
>>>> Date: Mon Mar 30 17:48:24 2009 +0000
>>>>
>>> Ouch, sorry about that. Thanks for doing all the bisection work.
>>>
>>>
>>>> ACPI: processor: use .notify method instead of installing handler
>>>> directly
>>>>
>>>> This patch adds a .notify() method. The presence of .notify() causes
>>>> Linux/ACPI to manage event handlers and notify handlers on our behalf,
>>>> so we don't have to install and remove them ourselves.
>>>>
>>>> Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com>
>>>> CC: Zhang Rui <rui.zhang@intel.com>
>>>> CC: Zhao Yakui <yakui.zhao@intel.com>
>>>> CC: Venki Pallipadi <venkatesh.pallipadi@intel.com>
>>>> CC: Anil S Keshavamurthy <anil.s.keshavamurthy@intel.com>
>>>> Signed-off-by: Len Brown <len.brown@intel.com>
>>>>
>>>> However, reverting this commit from v2.6.30-rc1 doesn't solve the hang.
>>>>
>>> I don't see the problem in that commit yet, and if there is a problem
>>> with it, I would think that reverting it from 2.6.30-rc1 would solve
>>> it. But maybe it'd be useful to revert the whole .notify series to
>>> make sure. From 2.6.30-rc1, you should be able to revert these:
>>>
>>> 7ec0a7290797f57b780f792d12f4bcc19c83aa4f processor
>>> 373cfc360ec773be2f7615e59a19f3313255db7c button
>>> 46ec8598fde74ba59703575c22a6fb0b6b151bb6 Linux/ACPI infrastructure
>>>
>>> What happens with those commits reverted?
>>>
>> I'll find out tomorrow.
>>
>
> The fact that it still hangs even when you don't load the processor
> driver at all suggests that the 7ec0a729079 commit identified by the
> bisection is not the real problem. That commit only touches
> drivers/acpi/processor_core.c.
>

Yah.

> I think it's more likely some kind of race or missed wakeup.
>
> Since it seems to be sensitive to whether the battery is present,
> I guess you could try blacklisting the battery.ko driver. There
> have been a few changes to it since 2.6.29-rc8. If things work
> without battery.ko, we can look through those changes.
>

Good guess :-). I tried a couple of times either way, and blacklisting
"battery" definitely avoids the hang.

Thanks
Alan


\
 
 \ /
  Last update: 2009-04-14 10:09    [W:0.135 / U:0.096 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site