Created attachment 107134 [details] Kernel config I'm sorry if I chose the wrong product and component, but these seemed only reasonable ones to select. Most of the time when I try to poweroff my laptop, it just hangs. Doesn't matter if you run poweroff, shutdown -h now or select poweroff from Xfce4 menu, it will just hang saying "Power down." and remain like that for an eternity (well, it looks like so) unless I hold down power button for like 5 secs. This happens ever since I bought this laptop last year ago, since kernel 3.5 or 3.6, I think. It still happens on latest 3.11.0-rc4 kernel. I want to note that I use one proprietary driver, Broadcom wireless one but I've verified and confirmed that it is not causing the issue by blacklisting it and using the kernel driver (which doesn't work well for my hardware). I've also noticed some people have this issue after resumming from suspend, but this machine can't even suspend (it suspends all devices but remains powered on, so only option is to shut it down using power button). There are also some strange ACPI messages in dmesg output which I have attached (have been there ever since). I am also attaching kernel configuration. As for the hardware, it is a HP Pavilion g6-1225em laptop which specifications you can see at [1] I sure hope this will be fixed once, I've already replaced one hard drive because of all the hard shutdowns and/or lockups because of power management. [1] http://h10025.www1.hp.com/ewfrf/wc/document?cc=ad&dlc=en&docname=c03017292&lc=en
Created attachment 107135 [details] dmesg output
Created attachment 107136 [details] Kernel config
Please attach acpidump: # acpidump > acpidump.txt
Created attachment 107166 [details] acpidump output
Hello, here's the output. Also, I've noticed the following messages on stderr Could not read ACPI table header from file Could not get ACPI table at index 14, AE_BAD_HEADER Could not read ACPI table header from file Could not get ACPI table at index 15, AE_BAD_HEADER Could not read ACPI table header from file Could not get ACPI table at index 16, AE_BAD_HEADER
Does S3(suspend to ram) and S4(suspend to disk) work?
From comment #1, S3 doesn't work either. What about S4?
Is there a newer BIOS version available? BTW, do you have Windows installed and does it power off OK?
Suspend to disk doesn't work either. Power manager tried to suspend to disk, but it failed since "no swap device was found" - and I have one, it is always on. # swapon NAME TYPE SIZE USED PRIO /dev/sda6 partition 6G 0B -1 My system has 6GB of RAM, so I assigned 6GB for swap. I'll attach a log from the kernel when power manager tried to hibernate it (few days ago). The system just came back up after hibernate failed, but drivers were messed up so only reboot fixed it. I'd imagine same would happen if hibernate was complete. There is no new BIOS version available, there were 3 to 4 updates available since May, last year but none ever touched anything related to ACPI. And yes, I have Win 7 Ultimate, and it shuts down just fine - every time. Even suspend to ram and suspend to disk work fine.
Created attachment 107185 [details] Kernel log when system tried to hibernate
I forgot to mention that I tried acpi_osi=Linux kernel parameter, but I just noticed a message like "Linux query ignored".
Does add kernel cmdline option acpi_osi="!Windows 2012" help?
Sorry, I didn't notice the reply. Must've had lost it in all the messages. I'll report back.
Created attachment 110481 [details] new dmesg output This is new dmesg output, but it still hung once on poweroff even when I used the kernel parameter you mentioned.
[ 1.634387] ACPI: Added _OSI(Module Device) [ 1.634391] ACPI: Added _OSI(Processor Device) [ 1.634394] ACPI: Added _OSI(3.0 _SCP Extensions) [ 1.634398] ACPI: Added _OSI(Processor Aggregator Device) [ 1.634401] ACPI: Deleted _OSI(Windows 2012) [ 1.637854] ACPI: EC: Look up EC in DSDT [ 1.641211] ACPI: Executed 1 blocks of module-level executable AML code [ 1.671257] [Firmware Bug]: ACPI: BIOS _OSI(Linux) query ignored This might be interesting part.
(In reply to Armin K. from comment #14) > Created attachment 110481 [details] > new dmesg output > > This is new dmesg output, but it still hung once on poweroff even when I > used the kernel parameter you mentioned. Hung once or hung every time? Before you add this cmdline option, does the system huang randomly or always? And what about S3/S4 with that cmdline option?
Created attachment 110581 [details] dmesg after suspend and resume with acpi_osi parameter
Created attachment 110591 [details] dmesg output after failed hibernate with acpi_osi parameter
Created attachment 110601 [details] dmesg after suspend and resume without acpi_osi parameter
Created attachment 110611 [details] dmesg after sucessfull hibernate and resume without acpi_osi parameter
Suspend worked with acpi_osi parameter. Hibernate seemed to work too, but instead of shutting down the machine, desktop just came back. Second attachment is mostly the same as first one, but it has additional info about (failed) hibernate. I didn't had kernel resume parameter set when I tried it with acpi_osi parameter. Last two attachments are without acpi_osi parameter, and both suspend and hibernate worked fine, both suspending/hibernating and resuming from them. I had set resume parameter to point to my swap partition. All tests were ran with Radeon GPU disabled (hybrid graphics setup). I believe its dynamic power management might break suspend and such since it was too new. Also, instead of using -rc kernel this time, I am using stable 3.11 kernel, so I presume lot of things were fixed too. It looks to me however that acpi_osi="!Windows 2012" has no (good) effect on this machine.
An update, I've seen a kernel fix where a developer worked arround similar bug (can't find it right now) by forcing reboot=pci parameter. I am using the mentioned parameter, and yet it hangs far far less than it was doing before. The few hangs are somehow usb specific, since I am using an external hub and it's power adaptor cable isn't that good. Sometimes when external hub loses power on shut down, I get tons of usb errors (failed to reset device or whatever) and only then machine seems to hang (not always). Without the reboot=pci parameter it seems to hang far more. I want to note that this model also needed a workaround for backlight, so I presume workaround for this would be fine, too.
(In reply to Armin K. from comment #17) > Created attachment 110581 [details] > dmesg after suspend and resume with acpi_osi parameter So S3 works? Does it always work or sometimes?
(In reply to Armin K. from comment #18) > Created attachment 110591 [details] > dmesg output after failed hibernate with acpi_osi parameter No swap device is found, this is a different problem than the system can not suspend/hibernate/shutdown.
(In reply to Armin K. from comment #20) > Created attachment 110611 [details] > dmesg after sucessfull hibernate and resume without acpi_osi parameter OK... so this time hibernate succeeded. I don't think acpi_osi would affect if swap device can be found or not.
(In reply to Armin K. from comment #21) > Suspend worked with acpi_osi parameter. Hibernate seemed to work too, but > instead of shutting down the machine, desktop just came back. Second > attachment is mostly the same as first one, but it has additional info about > (failed) hibernate. I didn't had kernel resume parameter set when I tried it > with acpi_osi parameter. The resume parameter doesn't matter since hibernate doesn't succeed as the system doesn't find a swap device to write snapshot image to. > > Last two attachments are without acpi_osi parameter, and both suspend and > hibernate worked fine, both suspending/hibernating and resuming from them. I > had set resume parameter to point to my swap partition. Er...so looks like S3/S4 are all working OK without acpi_osi parameter and that parameter isn't supposed to be used by default, which means your system can do S3/S4 well with a default configuration. Then the only problem is with shutdown. > > All tests were ran with Radeon GPU disabled (hybrid graphics setup). I > believe its dynamic power management might break suspend and such since it > was too new. Also, instead of using -rc kernel this time, I am using stable > 3.11 kernel, so I presume lot of things were fixed too. > > It looks to me however that acpi_osi="!Windows 2012" has no (good) effect on > this machine. Good to know this, thanks.
(In reply to Armin K. from comment #22) > An update, > > I've seen a kernel fix where a developer worked arround similar bug (can't > find it right now) by forcing reboot=pci parameter. I am using the mentioned > parameter, and yet it hangs far far less than it was doing before. The few > hangs are somehow usb specific, since I am using an external hub and it's > power adaptor cable isn't that good. Sometimes when external hub loses power > on shut down, I get tons of usb errors (failed to reset device or whatever) > and only then machine seems to hang (not always). Without the reboot=pci > parameter it seems to hang far more. I want to note that this model also > needed a workaround for backlight, so I presume workaround for this would be > fine, too. The reboot=pci is believed to have something to do with virtualization, can you please try to disable virtualization related settings in BIOS, something like VT-x VT-d etc. and see if that makes shutdown better? When you disable virtualization and do the shutdown test, you do not need to specify the reboot=pci parameter, thanks.
(In reply to Aaron Lu from comment #23) > (In reply to Armin K. from comment #17) > > Created attachment 110581 [details] > > dmesg after suspend and resume with acpi_osi parameter > > So S3 works? Does it always work or sometimes? It appears that both S3 and S4 work just fine, even without acpi_osi= parameter. It looked like to me that acpi_os=whatever parameter broke it.
(In reply to Aaron Lu from comment #26) > (In reply to Armin K. from comment #21) > > Suspend worked with acpi_osi parameter. Hibernate seemed to work too, but > > instead of shutting down the machine, desktop just came back. Second > > attachment is mostly the same as first one, but it has additional info > about > > (failed) hibernate. I didn't had kernel resume parameter set when I tried > it > > with acpi_osi parameter. > > The resume parameter doesn't matter since hibernate doesn't succeed as the > system doesn't find a swap device to write snapshot image to. > That was some other bug. As I said in comment #9, swap partition was present and was mounted when I try to suspend. Seems to work just fine yet. > > > > Last two attachments are without acpi_osi parameter, and both suspend and > > hibernate worked fine, both suspending/hibernating and resuming from them. > I > > had set resume parameter to point to my swap partition. > > Er...so looks like S3/S4 are all working OK without acpi_osi parameter and > that parameter isn't supposed to be used by default, which means your system > can do S3/S4 well with a default configuration. Then the only problem is > with shutdown. > > Yes, they work fine. > > > > All tests were ran with Radeon GPU disabled (hybrid graphics setup). I > > believe its dynamic power management might break suspend and such since it > > was too new. Also, instead of using -rc kernel this time, I am using stable > > 3.11 kernel, so I presume lot of things were fixed too. > > > > It looks to me however that acpi_osi="!Windows 2012" has no (good) effect > on > > this machine. > > Good to know this, thanks. As an update, I just ran suspend and hibernate with Radeon GPU on and it also worked fine. I only see some warnings and/or errors with binary wlan driver (broadcom), but it seems to work fine after resuming.
(In reply to Aaron Lu from comment #27) > (In reply to Armin K. from comment #22) > > An update, > > > > I've seen a kernel fix where a developer worked arround similar bug (can't > > find it right now) by forcing reboot=pci parameter. I am using the > mentioned > > parameter, and yet it hangs far far less than it was doing before. The few > > hangs are somehow usb specific, since I am using an external hub and it's > > power adaptor cable isn't that good. Sometimes when external hub loses > power > > on shut down, I get tons of usb errors (failed to reset device or whatever) > > and only then machine seems to hang (not always). Without the reboot=pci > > parameter it seems to hang far more. I want to note that this model also > > needed a workaround for backlight, so I presume workaround for this would > be > > fine, too. > > The reboot=pci is believed to have something to do with virtualization, can > you please try to disable virtualization related settings in BIOS, something > like VT-x VT-d etc. and see if that makes shutdown better? When you disable > virtualization and do the shutdown test, you do not need to specify the > reboot=pci parameter, thanks. Indeed. I've also believed that. In fact, my laptop has a bios switch to disable VT-x and it was disabled by default, since description said "HP recommends this feature to be disabled unless you use specialized applications." I can confirm that when VT-x is on, system hangs a lot more without reboot=pci parameter, but it also hangs when VT-x is off, just not that much.
Is there VT-d setting available?
This CPU doesn't support VT-d.
There is a thread about a similar bug: https://lkml.org/lkml/2013/10/25/426 Can you please try to see if older kernels work for you? Thanks.
If I recall correctly, the first kernel I used with this machine was 3.4 or 3.5. It hanged on rare occassions (not sure though). I've used Debian Live, which had 3.2 kernel, but machine never seemed to hang on shutdown with it.
How about v3.3? If v3.3 is bad, maybe doing a git bisect would be helpful. http://www.reactivated.net/weblog/archives/2006/01/using-git-bisect-to-find-buggy-kernel-patches/
I think that I've figured out why this is happening. When PCI Hotplug in kernel config was disabled and when booting with reboot=pci kernel parameter, issuing "reboot" command would fail to reboot machine and would shut it down instead. Now even without reboot=pci, but with the workaround from the [1], my system seems to shut down just fine (at least for now) and also fix other power issues that I had - radeon vgaswitcheroo and intel reclocking support. [1] https://bugs.freedesktop.org/show_bug.cgi?id=70687#c13
Thanks Armin for the update, I've added Rafael in and he might know what happened.
Hm, I believe that Comment 36 isn't related to my problem. Even with acpiphp disabled, my machine still hung at reboot for 3 times in a row! I'm out of ideas. This system can't run anything below 3.4 kernel, so bisecting isn't really an option.
What's the status of power off on latest upstream kernel?
It still hangs on rare occassions with kernel 3.13.3.
Are you using any kernel cmdline options?
Plenty # cat /proc/cmdline BOOT_IMAGE=../vmlinuz root=/dev/sda8 rootfstype=ext4 ro quiet radeon.dpm=1 acpiphp.disable=1 acpi_backlight=vendor snd-hda-intel.power_save=1 i915.i915_enable_rc6=1 i915.i915_enable_fbc=1
None is power off related I think?
Only radeon.dpm=1 turns on Radeon power management, which was disabled in 3.13.2->3.13.3 update. It was enabled by default since 3.12 though. acpiphp.disable=1 explicitly disables acpiphp which I thought caused hangs, but it doesn.t The last 3 are enabled by default I think, but not sure. acpi_backlight=vendor is required or my display will start without any backlight untill I press "Brightness Up" button. I did notice something, but not sure it's related - PEBS [ 0.028891] perf_event_intel: PEBS disabled due to CPU errata, please upgrade microcode [ 10.582744] microcode: CPU0 sig=0x206a7, pf=0x10, revision=0x25 [ 11.002307] microcode: CPU0 sig=0x206a7, pf=0x10, revision=0x25 [ 11.003823] microcode: CPU0 updated to revision 0x29, date = 2013-06-12 [ 11.003885] microcode: CPU1 sig=0x206a7, pf=0x10, revision=0x25 [ 11.003952] microcode: CPU1 sig=0x206a7, pf=0x10, revision=0x25 [ 11.004968] microcode: CPU1 updated to revision 0x29, date = 2013-06-12 [ 11.005041] microcode: CPU2 sig=0x206a7, pf=0x10, revision=0x25 [ 11.005123] microcode: CPU2 sig=0x206a7, pf=0x10, revision=0x25 [ 11.006107] microcode: CPU2 updated to revision 0x29, date = 2013-06-12 [ 11.006138] microcode: CPU3 sig=0x206a7, pf=0x10, revision=0x25 [ 11.006204] microcode: CPU3 sig=0x206a7, pf=0x10, revision=0x25 [ 11.007184] microcode: CPU3 updated to revision 0x29, date = 2013-06-12 [ 11.007191] perf_event_intel: PEBS enabled due to microcode update [ 11.007294] microcode: Microcode Update Driver: v2.00 <tigran@aivazian.fsnet.co.uk>, Peter Oruba Microcode firmware was extracted from .dat file fetched from Intel downloads center and added in /lib/firmware to get this to work
I can confirm the very same behavior with an Acer-Aspire V5-473. If I try to poweroff the machine, it just freezes and can't do anything. The same happens with "Suspension to Ram". By the way, Hibernation works without problems. My kernel is 3.11.10. I reported this in the Opensuse forums https://forums.opensuse.org/showthread.php/495716-Unable-to-shutdown-in-13-1-%28x86_64%29
Could not read ACPI table header from file Could not get ACPI table at index 14, AE_BAD_HEADER Could not read ACPI table header from file Could not get ACPI table at index 15, AE_BAD_HEADER Could not read ACPI table header from file Could not get ACPI table at index 16, AE_BAD_HEADER First of all, this is probably a bug in acpidump tool. Lv, can you please check and get this fixed first?
Hi, Armin K. I checked the acpidump output, there is no RSDP/RSDT in it. So the acpidump you were using shouldn't be the on in the Linux kernel. Could you try the acpidump built from Linux kernel? It is under the tools/power/acpi folder. You can build it: # cd tools # make acpi It can be found as tools/power/acpi/acpidump. Thanks and best regards -Lv
Created attachment 159521 [details] Output of acpidump from the Linux Kernel source Here's the output from acpidump from linux kernel source. The acpidump I was using was rather from acpica utils or something ilke that.
(In reply to Armin K. from comment #48) > Created attachment 159521 [details] > Output of acpidump from the Linux Kernel source > > Here's the output from acpidump from linux kernel source. The acpidump I was > using was rather from acpica utils or something ilke that. Now we can see SSDT5, SSDT6, SSDT7 in the acpidump output. There is no problem related to acpidump. Assign it back to Aaron to follow. Thanks
Armin, Since things got a lot better in recent kernels and it occur only on rare occasions, I'll close the bug. M, I'm not sure if you have the same problem with Armin, if you still have problems, please file a new bug. Thanks.