Bug#775812: base: HP EliteBook 840 G1 laptop fails to halt/poweroff after 15/12/2015 upgrade
Hi all, First of all, thank you for your time investigating the bug. I ran a few tests today, trying to help pinpointing the exact cause of the bug. On Mon, 2015-03-30 at 16:55 -0300, Henrique de Moraes Holschuh wrote: > For those affected (i.e. if your HP Elitebook 840 G1 DOES have > halt/poweroff issues right now), please do this: > [...] My HP Elitebook 840 G1 did not shutdown (but kept on rebooting) so I purged 'intel-microcode', ran 'update-initramfs -u' to be sure, validated that '/lib/firmware/intel-ucode' was removed from the system, rebooted the system, and finally tried to power off the system. The notebook did not power off properly, but rebooted instead—just as before. Like you said, I think we can now conclude it is not intel-microcode's fault. On Mon, 2015-03-30 at 18:54 +0200, Samuel Thibault wrote: > > I would like to add that I also didn't succeed in halting the > > notebook by using the GRUB command 'halt', it just rebooted after > > entering this command. > > Is this after a cold reboot (thus no uploaded microcode) or only after > a hot reboot? > > Also, just to make sure: with systemd the "halt" command doesn't power > off, "poweroff" needs to be used instead. Next, I tried to power off the system with the GRUB command 'halt'. There is no GRUB command 'poweroff' so I had to use 'halt'. The problem still persisted and the notebook rebooted instead of powering off. Next I tried to 'cold reboot': I powered off the notebook by hitting the power button at the GRUB boot menu, started the notebook (hitting the power button again), and entered the GRUB command 'halt'. Now the notebook did properly power off. I started the notebook again, let it boot al the way to the GNOME desktop and shut it down again from there. I was able to properly power down the system three times in a row. I had the idea the network connection (similar to Miguel) was cosing trouble, since I was not always able to reliably replicate the bug when I used the wired ethernet connection. For clarity, I had the suspicion that switching between wired and wireless network connections sometimes caused the bug to occur again. Continuing with my tests, I installed 'intel-microcode' again, switched wireless on—hoping to trigger the bug again. However, I shutdown and started the notebook four times, enabling and disabling the wireless network, but I did not succeed in triggering the bug to happen again. On Tue, 2015-03-31 at 08:11 -0300, Henrique de Moraes Holschuh wrote: > Please also attach the output of "lspci -v -v" (run as root). I can send you this next time when I'm using the notebook again. I forgot to check it last time! Hope this extensive description of what I've tried helps! Cheers, Tim -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#775812: base: HP EliteBook 840 G1 laptop fails to halt/poweroff after 15/12/2015 upgrade
reassign 775812 linux retitle 775812 linux-image-3.16.0-4-amd64: HP EliteBook 840 G1 laptop fails to halt/poweroff after 3.16.7-ckt2-1 upgrade thanks For the kernel maintainers: according to the user's report and his aptitude update log: Last known-good version: 3.16.7-2 First known-bad version: 3.16.7-ckt2-1 Synopsis: System will not power down if WoWLAN is enabled in BIOS/UEFI (platform default!). System will properly power down if WoWLAN is disabled in BIOS/UEFI. This is a regression in the CKT stable kernels. On Tue, Mar 31, 2015, at 05:40, Miguel Ortiz Lombardía wrote: > Attached a file listing what was upgraded via apt on December 15, the > day I first noticed the problem. I halt the computer every day, so that > should be in principle the first day it refused to do so properly. Thank you. It was a quite large update run, but you did update the kernel, which is the main suspect for this type of regression, anyway... so that's likely it. Other suspects (but very unlikely ones) from your update log: packagekit and grub2-pc. I will reassign this bug report to the kernel. It is likely caused by some change in either the shutdown path, or the wlan driver or subsystem. If it at all possible, please attach to this bug report the kernel boot logs of 2014-12-14, 15 and 16. They're usually either in /var/log/dmesg* (if they have not been rotated out yet), or you'll need to extract the relevant sections of /var/log/kern.log*. Please also attach the output of "lspci -v -v" (run as root). Let's hope the kernel guys can track down the problem and fix it. I understand it would be easy for you to reproduce the problem if they need more data. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique de Moraes Holschuh -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#775812: base: HP EliteBook 840 G1 laptop fails to halt/poweroff after 15/12/2015 upgrade
Hi, Attached a file listing what was upgraded via apt on December 15, the day I first noticed the problem. I halt the computer every day, so that should be in principle the first day it refused to do so properly. I use what I think is the default init system in jessie, i.e. systemd/udev. I hope this may help understand the issue. Best regards, Miguel Le 31/03/2015 01:54, Henrique de Moraes Holschuh a écrit : > On Mon, Mar 30, 2015, at 18:58, Miguel Ortiz Lombardía wrote: eventually after much reading I solved my problem by tweaking the BIOS and making sure that "Wake on WLAN" was inactive... >>> >>> Ouch. >> >> Yes... As mentioned, that setting being active (it seems to be this >> laptop BIOS default) had not triggered the reported behaviour previously. > > Well, that won't be caused by processor microcode, so this bug needs to > be either reassigned to something other than intel-microcode, or closed. > > WoL being active or inactive causing issues on shutdown will be > sensitive to: > > 1. kernel > > 2. WLAN firmware > > 3. systemd/udev (if you are using it) OR initscripts/udev (if you are > not using systemd). > > Maybe you can track down in /var/log/apt and /var/log/* which packages > were updated between the last time your laptop had been correctly > powered off and when you noticed it broke? > > Otherwise, we don't have enough information to track the issue, and we > should close this bug... > Start-Date: 2014-12-15 09:48:12 Commandline: apt-get upgrade Upgrade: firebird2.5-server-common:amd64 (2.5.3.26778.ds4-4, 2.5.3.26778.ds4-5), install-info:amd64 (5.2.0.dfsg.1-5, 5.2.0.dfsg.1-6), linux-image-3.16.0-4-amd64:amd64 (3.16.7-2, 3.16.7-ckt2-1), xboard:amd64 (4.8.0-1, 4.8.0-2), libfbclient2:amd64 (2.5.3.26778.ds4-4, 2.5.3.26778.ds4-5), gir1.2-packagekitglib-1.0:amd64 (1.0.1-1, 1.0.1-2), libjavascriptcoregtk-3.0-0:amd64 (2.4.7-2, 2.4.7-3), libllvm3.5:amd64 (3.5-6, 3.5-8), libllvm3.5:i386 (3.5-6, 3.5-8), gir1.2-javascriptcoregtk-3.0:amd64 (2.4.7-2, 2.4.7-3), firebird2.5-common-doc:amd64 (2.5.3.26778.ds4-4, 2.5.3.26778.ds4-5), calendar-google-provider:amd64 (31.2.0-1, 31.3.0-1), grub-common:amd64 (2.02~beta2-17, 2.02~beta2-18), iceowl-extension:amd64 (31.2.0-1, 31.3.0-1), packagekit:amd64 (1.0.1-1, 1.0.1-2), linux-headers-3.16.0-4-amd64:amd64 (3.16.7-2, 3.16.7-ckt2-1), icedove:amd64 (31.2.0-1, 31.3.0-1), grub2-common:amd64 (2.02~beta2-17, 2.02~beta2-18), packagekit-tools:amd64 (1.0.1-1, 1.0.1-2), libfbembed2.5:amd64 (2.5.3.26778.ds4-4, 2.5.3.26778.ds4-5), libwebkitgtk-3.0-0:amd64 (2.4.7-2, 2.4.7-3), python3-speechd:amd64 (0.8-6, 0.8-7), speech-dispatcher-audio-plugins:amd64 (0.8-6, 0.8-7), grub-pc-bin:amd64 (2.02~beta2-17, 2.02~beta2-18), grub-pc:amd64 (2.02~beta2-17, 2.02~beta2-18), linux-compiler-gcc-4.8-x86:amd64 (3.16.7-2, 3.16.7-ckt2-1), firebird2.5-common:amd64 (2.5.3.26778.ds4-4, 2.5.3.26778.ds4-5), libwebkitgtk-3.0-common:amd64 (2.4.7-2, 2.4.7-3), info:amd64 (5.2.0.dfsg.1-5, 5.2.0.dfsg.1-6), linux-libc-dev:amd64 (3.16.7-2, 3.16.7-ckt2-1), linux-headers-3.16.0-4-common:amd64 (3.16.7-2, 3.16.7-ckt2-1), libpackagekit-glib2-18:amd64 (1.0.1-1, 1.0.1-2), gir1.2-webkit-3.0:amd64 (2.4.7-2, 2.4.7-3), libspeechd2:amd64 (0.8-6, 0.8-7), texinfo:amd64 (5.2.0.dfsg.1-5, 5.2.0.dfsg.1-6), speech-dispatcher:amd64 (0.8-6, 0.8-7) End-Date: 2014-12-15 09:48:57
Bug#775812: base: HP EliteBook 840 G1 laptop fails to halt/poweroff after 15/12/2015 upgrade
On Mon, Mar 30, 2015, at 18:58, Miguel Ortiz Lombardía wrote: > >> eventually after much reading I solved my problem by tweaking the BIOS > >> and making sure that "Wake on WLAN" was inactive... > > > > Ouch. > > Yes... As mentioned, that setting being active (it seems to be this > laptop BIOS default) had not triggered the reported behaviour previously. Well, that won't be caused by processor microcode, so this bug needs to be either reassigned to something other than intel-microcode, or closed. WoL being active or inactive causing issues on shutdown will be sensitive to: 1. kernel 2. WLAN firmware 3. systemd/udev (if you are using it) OR initscripts/udev (if you are not using systemd). Maybe you can track down in /var/log/apt and /var/log/* which packages were updated between the last time your laptop had been correctly powered off and when you noticed it broke? Otherwise, we don't have enough information to track the issue, and we should close this bug... -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique de Moraes Holschuh -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#775812: base: HP EliteBook 840 G1 laptop fails to halt/poweroff after 15/12/2015 upgrade
El 30/03/15 a las 23:40, Samuel Thibault escribió: > Miguel Ortiz Lombardía, le Mon 30 Mar 2015 23:28:53 +0200, a écrit : >> Well, when depositing a bug report concerning a "base" package you're >> asked in what way you think the Debian Policy Manual has been broken, > > It's not about a "base" package, but about having set the severity to > "serious", i.e. a bug that is so grave that it should prevent Jessie > from getting released with it because it severely violates the Debian > Policy. > Thanks a lot for the clarification and sorry for my misunderstanding! >> eventually after much reading I solved my problem by tweaking the BIOS >> and making sure that "Wake on WLAN" was inactive... > > Ouch. > Yes... As mentioned, that setting being active (it seems to be this laptop BIOS default) had not triggered the reported behaviour previously. Miguel > Samuel > -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#775812: base: HP EliteBook 840 G1 laptop fails to halt/poweroff after 15/12/2015 upgrade
Miguel Ortiz Lombardía, le Mon 30 Mar 2015 23:28:53 +0200, a écrit : > Well, when depositing a bug report concerning a "base" package you're > asked in what way you think the Debian Policy Manual has been broken, It's not about a "base" package, but about having set the severity to "serious", i.e. a bug that is so grave that it should prevent Jessie from getting released with it because it severely violates the Debian Policy. > eventually after much reading I solved my problem by tweaking the BIOS > and making sure that "Wake on WLAN" was inactive... Ouch. Samuel -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#775812: base: HP EliteBook 840 G1 laptop fails to halt/poweroff after 15/12/2015 upgrade
Hello! El 30/03/15 a las 18:54, Samuel Thibault escribió: > Control: retitle -1 base: HP EliteBook 840 G1 laptop fails to halt/poweroff > after 15/12/2014 upgrade > Control: severity -1 important > Control: reassign -1 intel-microcode > > Hello, > > On Tue, 20 Jan 2015 12:42:05 +0100 Miguel > wrote: >> Severity: serious >> Justification: Policy 9.11 > > I do not really understand what you mean by "Policy 9.11". > Well, when depositing a bug report concerning a "base" package you're asked in what way you think the Debian Policy Manual has been broken, to justify the report. Since it had been suggested that the problem could come from systemd, I thought that this text from paragraph 11, chapter 9 of the Debian Policy Manual could be such justification : "<...> However, any package integrating with other init systems must also be backwards-compatible with sysvinit by providing a SysV-style init script with the same name as and equivalent functionality to any init-specific job, as this is the only start-up configuration method guaranteed to be supported by all init implementations. An exception to this rule is scripts or jobs provided by the init implementation itself <...> " (https://www.debian.org/doc/debian-policy/ch-opersys.html#s-alternateinit) Having said that, I was not expecting an answer so long after (thank you anyway!) I must say that eventually after much reading I solved my problem by tweaking the BIOS and making sure that "Wake on WLAN" was inactive... I still don't understand why this manipulation had not been necessary previously, but anyway, that's not important to me : I don't need/want to wake up my computer when a known wifi becomes available... I decided not to close the bug report myself because I thought I might have found a particular solution, good for me, perhaps not for others. All the best, Miguel > Tim, le Thu 12 Feb 2015 23:57:59 +0100, a écrit : >> On Tue, 20 Jan 2015 12:42:05 +0100 Miguel >> wrote: >>> I'm running Debian testing (jessie) on an HP EliteBook 840 G1 laptop. >>> Everything goes reasonably well, even very well, except that after >>> running apt-get update/upgrade on Monday (15 December) I cannot halt >>> (poweroff) the computer. When I try to switch it off it just reboots. I >>> manage to get it in sleep mode by pressing the the physical start button >>> and this is what I'm doing since then. No previous problems in this >>> sense before that upgrade. I have 'intel-microcode' and >>> 'firmware-linux-free' installed from the beginning. >> >> I can confirm this problem on exactly the same notebook and with >> 'intel-microcode' installed as well. > > Does it happen without the microcode upload? > >>> After that report I was able to sometimes halt the computer correctly either >>> from the gnome interface or from the console. >> >> I would like to add that I also didn't succeed in halting the notebook >> by using the GRUB command 'halt', it just rebooted after entering this >> command. > > Is this after a cold reboot (thus no uploaded microcode) or only after a > hot reboot? > > Also, just to make sure: with systemd the "halt" command doesn't power > off, "poweroff" needs to be used instead. > > Samuel > -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#775812: base: HP EliteBook 840 G1 laptop fails to halt/poweroff after 15/12/2015 upgrade
On Mon, Mar 30, 2015, at 15:42, intrigeri wrote: > > Control: retitle -1 base: HP EliteBook 840 G1 laptop fails to halt/poweroff > > after 15/12/2014 upgrade > > FWIW, the very same laptop powers off just fine here with current sid. > intel-microcode 3.20150121.1 is installed, and my PID 1 is systemd. Very well... For those affected (i.e. if your HP Elitebook 840 G1 DOES have halt/poweroff issues right now), please do this: 1. purge intel-microcode from the system: %aptitude purge intel-microcode 2. re-create the initramfs (should have been done by the purge, but better safe than sorry): %update-initramfs -u 2a. ensure there are no lingering files that would cause issues: ls /lib/firmware/intel-ucode That directory must be empty, or not exist at all. 3. reboot. 4. try to shutdown. If the problem persists, it is not intel-microcode's fault. If the problem is fixed by removing intel-microcode, I will ask for further details to narrow the issue down. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique de Moraes Holschuh -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#775812: base: HP EliteBook 840 G1 laptop fails to halt/poweroff after 15/12/2015 upgrade
Control: retitle -1 base: HP EliteBook 840 G1 laptop fails to halt/poweroff after 15/12/2014 upgrade Control: severity -1 important Control: reassign -1 intel-microcode Hello, On Tue, 20 Jan 2015 12:42:05 +0100 Miguel wrote: > Severity: serious > Justification: Policy 9.11 I do not really understand what you mean by "Policy 9.11". Tim, le Thu 12 Feb 2015 23:57:59 +0100, a écrit : > On Tue, 20 Jan 2015 12:42:05 +0100 Miguel > wrote: > > I'm running Debian testing (jessie) on an HP EliteBook 840 G1 laptop. > > Everything goes reasonably well, even very well, except that after > > running apt-get update/upgrade on Monday (15 December) I cannot halt > > (poweroff) the computer. When I try to switch it off it just reboots. I > > manage to get it in sleep mode by pressing the the physical start button > > and this is what I'm doing since then. No previous problems in this > > sense before that upgrade. I have 'intel-microcode' and > > 'firmware-linux-free' installed from the beginning. > > I can confirm this problem on exactly the same notebook and with > 'intel-microcode' installed as well. Does it happen without the microcode upload? > > After that report I was able to sometimes halt the computer correctly either > > from the gnome interface or from the console. > > I would like to add that I also didn't succeed in halting the notebook > by using the GRUB command 'halt', it just rebooted after entering this > command. Is this after a cold reboot (thus no uploaded microcode) or only after a hot reboot? Also, just to make sure: with systemd the "halt" command doesn't power off, "poweroff" needs to be used instead. Samuel -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#775812: base: HP EliteBook 840 G1 laptop fails to halt/poweroff after 15/12/2015 upgrade
On Tue, 20 Jan 2015 12:42:05 +0100 Miguel wrote: > I'm running Debian testing (jessie) on an HP EliteBook 840 G1 laptop. > Everything goes reasonably well, even very well, except that after > running apt-get update/upgrade on Monday (15 December) I cannot halt > (poweroff) the computer. When I try to switch it off it just reboots. I > manage to get it in sleep mode by pressing the the physical start button > and this is what I'm doing since then. No previous problems in this > sense before that upgrade. I have 'intel-microcode' and > 'firmware-linux-free' installed from the beginning. I can confirm this problem on exactly the same notebook and with 'intel-microcode' installed as well. > After that report I was able to sometimes halt the computer correctly either > from the gnome interface or from the console. I would like to add that I also didn't succeed in halting the notebook by using the GRUB command 'halt', it just rebooted after entering this command. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#775812: base: HP EliteBook 840 G1 laptop fails to halt/poweroff after 15/12/2015 upgrade
Package: base Severity: serious Justification: Policy 9.11 Dear Maintainer, I initially reported this problem on the debian-user list (17 Dec 2014). Here follow the description of the problem that I described: I'm running Debian testing (jessie) on an HP EliteBook 840 G1 laptop. Everything goes reasonably well, even very well, except that after running apt-get update/upgrade on Monday (15 December) I cannot halt (poweroff) the computer. When I try to switch it off it just reboots. I manage to get it in sleep mode by pressing the the physical start button and this is what I'm doing since then. No previous problems in this sense before that upgrade. I have 'intel-microcode' and 'firmware-linux-free' installed from the beginning. Some suggested that it could be a systemd-related problem. After that report I was able to sometimes halt the computer correctly either from the gnome interface or from the console. This has not happenend again in the last three weeks. I am force to halt the computer by letting it restart and use the power switch when GRUB starts. Of course, what I expect is to be able to halt the computer cleanly, as easily as possible but at the very least by root on the console. I apologise if this is not the right place to report this bug and I would appreciate suggestions about where it should go. -- System Information: Debian Release: 8.0 APT prefers testing-updates APT policy: (500, 'testing-updates'), (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.16.0-4-amd64 (SMP w/4 CPU cores) Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
