Launchpad has imported 26 comments from the remote bug at

If you reply to an imported comment from within Launchpad, your comment
will be sent to the remote bug automatically. Read more about
Launchpad's inter-bugtracker facilities at

On 2013-07-10T02:30:12+00:00 sduddikunta wrote:

Created attachment 106855

For the past few releases of almost all popular Linux-based
distributions, users of Lenovo's Z580 laptop have been noticing that
past a particular kernel version (usually a certain build of 3.2), the
boot would seem to hang. In reality, the boot would eventually complete,
though after 15-20 minutes (or more in extreme cases). Looking at dmesg
output of boots that hung but eventually finished, three ACPI timeouts
are reported (120s infinite loop timeout in BIOS).

Testing of this bug on my end took place on Ubuntu 12.04 LTS and Fedora
19, running mainline builds (unmodified mainline tree sources with
distribution kernel configurations). However, users of Fedora, Arch,
Mint, and Gentoo report similar issues both with distribution and
mainline kernels.

Ubuntu Bug Report:

>From the dmesg output, it was found that booting without the battery
physically installed was always successful. Later inserting the battery
after boot had no adverse consequences. Furthermore, compiling a kernel
without battery support (either not at all or as a module later
blacklisted on the command line) would also produce successful boots.

dmesg from above showing impacted area:

[ 840.304049] INFO: task swapper/0:1 blocked for more than 120 seconds.
[ 840.304052] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this 
[ 840.304054] swapper/0 D ffffffff81806240 0 1 0 0x00000000
[ 840.304058] ffff880118301e80 0000000000000046 0000000000000000 
[ 840.304061] ffff880118301fd8 ffff880118301fd8 ffff880118301fd8 
[ 840.304065] ffff880117c19700 ffff8801182f8000 ffff880118301e70 
[ 840.304068] Call Trace:
[ 840.304074] [<ffffffff8165b50f>] schedule+0x3f/0x60
[ 840.304078] [<ffffffff81092df5>] async_synchronize_cookie_domain+0x75/0x120
[ 840.304082] [<ffffffff8108bd20>] ? add_wait_queue+0x60/0x60
[ 840.304085] [<ffffffff81092ef7>] async_synchronize_full+0x17/0x20
[ 840.304090] [<ffffffff81641107>] init_post+0xe/0xc5
[ 840.304094] [<ffffffff81cfcd74>] kernel_init+0x164/0x164
[ 840.304098] [<ffffffff81667b74>] kernel_thread_helper+0x4/0x10
[ 840.304101] [<ffffffff81cfcc10>] ? start_kernel+0x3bd/0x3bd
[ 840.304104] [<ffffffff81667b70>] ? gs_change+0x13/0x13
[ 947.952877] ACPI Error: Method parse/execution failed [\_SB_.WADR] (Node 
ffff880118260028), AE_AML_INFINITE_LOOP (20110623/psparse-536)
[ 947.952891] ACPI Error: Method parse/execution failed [\_SB_.BAT1.UPBI] (Node 
ffff880118260258), AE_AML_INFINITE_LOOP (20110623/psparse-536)
[ 947.952898] ACPI Error: Method parse/execution failed [\_SB_.BAT1._BIF] (Node 
ffff880118260208), AE_AML_INFINITE_LOOP (20110623/psparse-536)
[ 947.952906] ACPI Exception: AE_AML_INFINITE_LOOP, Evaluating _BIF 
[ 947.952909] ACPI: Battery Slot [BAT1] (battery present)
[ 947.954127] Freeing unused kernel memory: 924k freed
[ 947.954237] Write protecting the kernel read-only data: 12288k

Specifically, this bug has been reported to appear sometime between 3.2
and 3.3, though the exact commit is unknown. Some temporary workarounds
have been proposed, both on the Ubuntu tracker above, and on other
forums. The only fix that has consistently worked (no failed boots) was
a modification of the DSDT suggested by Tom Thompson on the Ubuntu
tracker. His workaround
was to add a "Sleep (50)" line inside the method WAEC, recompile the
DSDT, and use grub2 to replace the DSDT before booting. This fix has
consistently worked on every kernel I have tested, including Mainline
3.3, 3.4, 3.8; Ubuntu 3.3, 3.4; and Fedora 3.8. This change seems to
indicate either a race condition or other timing issue in the Linux

Many Z580 models exist based on both 2nd and 3rd generation Intel Core
processors with Intel Integrated and optional NVIDIA graphics, and all
exhibit this same behavior. Windows 7/8 will boot without modification
to the BIOS provided DSDT. As Linux requires the modification to the
DSDT to boot normally after kernel 3.2, this is likely a bug. All kernel
versions past 3.2 do not boot successfully.

The original compiled DSDT, decompiled DSDT.dsl.orig, modified DSDT.dsl,
diff DSDT.dsl.diff, and recompiled DSDT.aml are attached to this report.
This bug has existed for many months, and most newer versions of
distributions will not even boot live media to install. Thank you for
your assistance.

Reply at:

On 2013-07-10T02:30:46+00:00 sduddikunta wrote:

Created attachment 106856

Reply at:

On 2013-07-10T02:31:53+00:00 sduddikunta wrote:

Created attachment 106857

Reply at:

On 2013-07-10T02:32:18+00:00 sduddikunta wrote:

Created attachment 106858

Reply at:

On 2013-07-10T02:32:30+00:00 sduddikunta wrote:

Created attachment 106859

Reply at:

On 2013-07-15T00:56:11+00:00 wrote:

Add Zheng Lv.

In the meantime, it would be good if someone can do the bisect to find
the offending commit.

Reply at:

On 2013-07-15T04:47:13+00:00 lv.zheng wrote:

>From the DSDT, we can see that all BYFG accesses are invoked inside _BIF 
I just wonder how _BIF method is invoked by the OSPM.
We may need to investigate to see the bisect result first.

Reply at:

On 2013-07-15T16:37:36+00:00 sduddikunta wrote:

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.

Reply at:

On 2013-07-15T17:01:50+00:00 sduddikunta wrote:

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.

Reply at:

On 2013-08-12T08:24:42+00:00 wrote:

Please attach acpidump like this:
# acpidump > acpidump.txt

Reply at:

On 2013-08-12T20:34:51+00:00 sduddikunta wrote:

Created attachment 107191

Reply at:

On 2013-09-28T00:03:50+00:00 sduddikunta wrote:

Has there been any progress on this? There is still active discussion on
the Ubuntu bug tracker with no true workarounds or fixes yet.

Reply at:

On 2013-09-29T02:24:38+00:00 lv.zheng wrote:

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 <> 2013-09-06 06:27:15 (GMT) 
Subject: ACPICA: Fix for a Store->ArgX when ArgX contains a reference to a 

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.

Reply at:

On 2013-09-29T03:05:18+00:00 sduddikunta wrote:

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.

Reply at:

On 2013-10-10T01:27:00+00:00 wrote:

Anything new about the test?

Reply at:

On 2013-10-10T01:46:51+00:00 sduddikunta wrote:

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.

Reply at:

On 2014-03-07T03:28:14+00:00 lv.zheng wrote:


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)

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
   # git checkout -b linux-next --track origin/linux-next
2. Please boot the kernel without DSDT customized.

Thanks in advance.

Reply at:

On 2014-03-09T14:58:40+00:00 sduddikunta wrote:

I will test and report back in a few days.

Reply at:

On 2014-03-13T00:53:56+00:00 sduddikunta wrote:

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.

Reply at:

On 2014-03-13T07:19:14+00:00 lv.zheng wrote:

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.

Reply at:

On 2014-06-03T03:49:35+00:00 rui.zhang wrote:, any update on this?

Reply at:

On 2014-06-03T04:59:58+00:00 lv.zheng wrote:

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.


Reply at:

On 2014-06-03T05:04:24+00:00 rui.zhang wrote:

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?

Reply at:

On 2014-06-03T05:25:02+00:00 lv.zheng wrote:

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.


Reply at:

On 2014-06-11T00:22:36+00:00 lv.zheng wrote:

Closing since no response.
You can re-open it if you still suffer from the same issue in the recent kernel.

Reply at:

On 2019-07-11T09:46:12+00:00 tomplatz567 wrote:

Created attachment 283621

Reply at:

** Changed in: linux
       Status: Unknown => Expired

** Changed in: linux
   Importance: Unknown => High

You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.

  8086:0166 [Lenovo IdeaPad Z580] 12.04-13.10 10-20min boot delay (From>3.12-rc2)

To manage notifications about this bug go to:

ubuntu-bugs mailing list

Reply via email to