Bug 60542
Summary: | DSDT: Lenovo Ideapad Z580 Extremely Slow Boot, AML infinite loop | ||
---|---|---|---|
Product: | ACPI | Reporter: | sduddikunta |
Component: | ACPICA-Core | Assignee: | Lv Zheng (lv.zheng) |
Status: | CLOSED INSUFFICIENT_DATA | ||
Severity: | high | CC: | aaron.lu, lenb, lv.zheng, rui.zhang, sduddikunta, tomplatz567, zetalog |
Priority: | P1 | ||
Hardware: | x86-64 | ||
OS: | Linux | ||
Kernel Version: | no known working kernel | Subsystem: | |
Regression: | No | Bisected commit-id: | |
Attachments: |
DSDT
DSDT.aml DSDT.dsl DSDT.dsl.orig DSDT.dsl.diff acpidump.txt 118 |
Description
sduddikunta
2013-07-10 02:30:12 UTC
Created attachment 106856 [details]
DSDT.aml
Created attachment 106857 [details]
DSDT.dsl
Created attachment 106858 [details]
DSDT.dsl.orig
Created attachment 106859 [details]
DSDT.dsl.diff
Add Zheng Lv. In the meantime, it would be good if someone can do the bisect to find the offending commit. From the DSDT, we can see that all BYFG accesses are invoked inside _BIF method. I just wonder how _BIF method is invoked by the OSPM. We may need to investigate to see the bisect result first. After further testing, this bug may not be a regression. Because of the nature of the problem, boots even with bad kernels often don't hang. However, in the recent testing I did, I found that versions dating back to 3.0 (including the previously thought good 3.2) also exhibited the issue. I'll continue to test versions prior to 3.0. Attempted to test 2.6.39 and 2.6.38; my system does not boot either one. It's not that they hang the same way the 3.x kernels do, the kernel doesn't load at all. I get no output to the screen. There is no indication of anything happening. Please attach acpidump like this: # acpidump > acpidump.txt Created attachment 107191 [details]
acpidump.txt
Has there been any progress on this? There is still active discussion on the Ubuntu bug tracker with no true workarounds or fixes yet. Have you tested the kernel with an ACPICA fix that has filled a gap for operation region fields? The commit is: Commit 4be4be8fee2ee99a52f94f90d03d2f287ee1db86 Author: Bob Moore <robert.moore@intel.com> 2013-09-06 06:27:15 (GMT) Subject: ACPICA: Fix for a Store->ArgX when ArgX contains a reference to a field. Which is shipped in the mainline kernel tagged as 3.12-rc2. This bug seems to be a duplicate of the issue fixed by this commit. Thanks for the response. I just installed the Ubuntu mainline 3.12-rc2 build, and initial testing seems to be showing good results. I've asked the folks on the Ubuntu tracker for additional help in testing, and I'll report back once we're done. Anything new about the test? Sorry about the delay. The new kernel does not fix the bug. Myself and a few on the Ubuntu tracker have found that it still exhibits the same occasional, seemingly random issues with the infinite loop. Hi, The WAEC method has created a named object inside of it: Method (WAEC, 0, NotSerialized) { Name (CUNT, 0x1E) While (LNotEqual (^PCI0.LPCB.EC0.BYFG, Zero)) { Sleep (0x05) Decrement (CUNT) If (LEqual (CUNT, Zero)) { Store (Zero, ^PCI0.LPCB.EC0.BYFG) Store (Zero, ^PCI0.LPCB.EC0.DRFG) Break } } } So this looks like a method should be marked as Serialized. Recently we have fix shipped in the Linux upstream to automatically marking control methods as Serialized. Could you give it try? 1. Please download and checkout the git repo that this series is based on (linux-pm/linux-next branch): # git clone https://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git # git checkout -b linux-next --track origin/linux-next 2. Please boot the kernel without DSDT customized. Thanks in advance. I will test and report back in a few days. This does not fix the bug. The same condition is seen: a seemingly randomly occurring hang. I also noticed that my computer was unable to shut down via the usual channels with this kernel. It would halt but not power off. OK, Let's do some basic debugging. 1. Please use the v3.14-rc5 kernel (it is linus/master branch); 2. Please apply the following patches: attachment 129031 [details] attachment 129041 [details] attachment 129051 [details] attachment 129061 [details] attachment 129071 [details] 3. Boot the kernel with "acpi.debug_layer=0x000000E4 acpi.debug_level=0x00000010 acpi_trace_once=_SB_.BAT1._BIF"; 4. Post dmesg here. Let's first track what has been executed in this case. Thanks in advance. sduddikunta@gmail.com, any update on this? Hi, Rui This bug is a valid report. All information needed are uploaded here. It reflects a gap in ACPICA interpreter. We just don't have time working on it. There are 2 ACPICA releases queued up for 3.16 and some urgent issues are handled this Q. Thanks Do we have a patch that has been verified to fix this? If no, we need one, and I think this is what you want to do in comment #19, no? No(In reply to Zhang Rui from comment #22) > Do we have a patch that has been verified to fix this? > If no, we need one, and I think this is what you want to do in comment #19, > no? You are right. I confused this bug to another. That kind of logging message could be useful. Thanks Closing since no response. You can re-open it if you still suffer from the same issue in the recent kernel. Created attachment 283621 [details]
118
|