Comment 182 for bug 1093217

Created attachment 106855
DSDT

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: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1093217

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 message.
[ 840.304054] swapper/0 D ffffffff81806240 0 1 0 0x00000000
[ 840.304058] ffff880118301e80 0000000000000046 0000000000000000 ffff880114537040
[ 840.304061] ffff880118301fd8 ffff880118301fd8 ffff880118301fd8 00000000000137c0
[ 840.304065] ffff880117c19700 ffff8801182f8000 ffff880118301e70 0000000000000009
[ 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 (20110623/battery-419)
[ 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 (https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1093217/comments/63) 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 kernel.

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.