Alan Jenkins wrote: > 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@xxxxxx> >>>>> 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@xxxxxx> >>>>> CC: Zhang Rui <rui.zhang@xxxxxxxxx> >>>>> CC: Zhao Yakui <yakui.zhao@xxxxxxxxx> >>>>> CC: Venki Pallipadi <venkatesh.pallipadi@xxxxxxxxx> >>>>> CC: Anil S Keshavamurthy <anil.s.keshavamurthy@xxxxxxxxx> >>>>> Signed-off-by: Len Brown <len.brown@xxxxxxxxx> >>>>> >>>>> 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. > Ok, I tried reverting 0f66af530116e9f4dd97f328d91718b56a6fc5a4 "ACPI: battery: asynchronous init" and that fixed it. Thanks for your help so far, Bjorn. Alan -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
