Bug 201965
| Summary: | Power off / Shutdown hangs after echoing "Reboot: Power down" on DELL / WYSE Thin Client - AMD G-T56N | ||
|---|---|---|---|
| Product: | ACPI | Reporter: | Sebastian (sebastian486) |
| Component: | Power-Off | Assignee: | acpi_power-off |
| Status: | NEW --- | ||
| Severity: | normal | CC: | adamoa, biergaizi2009, lenb, marcos, sawbona |
| Priority: | P1 | ||
| Hardware: | x86-64 | ||
| OS: | Linux | ||
| Kernel Version: | 4.9.0-8-amd64 #1 SMP Debian 4.9.130-2 (2018-10-27) x86_64 | Subsystem: | |
| Regression: | No | Bisected commit-id: | |
|
Description
Sebastian
2018-12-12 03:09:34 UTC
Output of acpitool -e: Kernel version : 4.9.0-8-amd64 - ACPI version : 20160831 ----------------------------------------------------------- Battery status : <not available> AC adapter : online Fan : <not available> CPU type : AMD G-T56N Processor CPU speed : 0x5000101 MHz Cache size : 1646.542 KB Bogomips : 3293.08 Bogomips : 3293.08 Function Show_CPU_Info : could not read directory /proc/acpi/processor/ Make sure your kernel has ACPI processor support enabled. Thermal info : <not available> Device S-state Status Sysfs node --------------------------------------- 1. PB4 S4 *disabled 2. PB5 S4 *disabled 3. PB6 S4 *disabled 4. PB7 S4 *disabled 5. OHC1 S4 *enabled pci:0000:00:12.0 6. EHC1 S4 *enabled pci:0000:00:12.2 7. OHC2 S4 *enabled pci:0000:00:13.0 8. EHC2 S4 *enabled pci:0000:00:13.2 9. OHC3 S4 *enabled pci:0000:00:16.0 10. EHC3 S4 *enabled pci:0000:00:16.2 11. OHC4 S4 *enabled pci:0000:00:14.5 12. SBAZ S4 *disabled pci:0000:00:14.2 13. KBC0 S3 *enabled pnp:00:02 14. MSE0 S3 *disabled pnp:00:03 15. P2P S5 *disabled pci:0000:00:14.4 16. SPB0 S4 *disabled pci:0000:00:15.0 17. SPB1 S0 *disabled pci:0000:00:15.1 18. SPB2 S4 *disabled pci:0000:00:15.2 19. SPB3 S4 *disabled It could be possibly a duplicate of https://bugzilla.kernel.org/show_bug.cgi?id=199349. See the latest comment here for a solution. I have what seems to be a similar issue as the one posted here by the OP. This is on a Sun Microsystems Ultra 24 Workstation (BIOS v1.56) running under Linux devuan 4.9.0-8-amd64 #1 SMP Debian 4.9.144-3.1 (2019-02-19) x86_64 GNU/Linux and an Intel(R) Core(TM)2 Quad CPU Q9550. Basically, on shutdown the machine will do one of two things: 1. shut down properly 2. freeze during the shutdown at this point ... [code] e1000e: EEE Tx LPI Timer Preparing to enter sleep state S5 Reboot: Power Down [/code] ... with the fans blowing at full speed. Whenever it occurrs, the last line is before the freeze is the same: [code] Reboot: Power Down [/code] Unfortunately, I have not been able to reproduce it or link it to anything in particular, it just happens every so many shutdowns and the number can go from3 to 20 with no discernible (at least to me) pattern. None of the /var/log files (syslog, kern.log, faillog, messages) show anything relevant, which is not a surprise as in that state (ie: Reboot: Power Down) filesystems are in a RO state. I have tried the same approaches as the OP ... 1) various kernel boot parameters 2) a custom init script run at shutdown to rmmod the e1000e driver module ...but the issue eventually ocurrs again. I have also tried a shutdown script using /proc/sysrq-trigger to no avail: eventually it will also occurr and in the same manner. The problem woud seem to be distribution agnostic as it also happens in an emergency skeleton TCLinux installation (with an older kernel) that I boot from a USB memory stick and in a Mint installation I was using up to about a couple of years ago before I moved to Devuan. Please advise or ask for addiitonal information if required. Thanks in advance. JHM Hi, I had a similar problem for several months until I decided to focus on analyzing what it could be. I switched ON ACPI_DEBUG and I checked that the system hanged after the ACPI registers were set to sleep (after the "Reboot: Power down" message). My motherboard has TPM configured but the ownership is of my Dual Boot Windows, when I disabled the TPM the problem vanished. It seems that my mainboard expects the TPM to be enable in order to successfuly power down, please check if this is the case for you. Best, Adam Hello: Thank you very much for taking the time to write here about this. Much obliged. > ... similar problem ... > ... focus on analyzing what it could be. A thankless endeavour, no doubt. > ... switched ON ACPI_DEBUG ... Never thought of that, basically because it was unknown to me. > ... system hanged after the ACPI registers were set to sleep ... The problem with my box (Sun Ultra 24) is that I have never been able to reliably reproduce the fault. It started when I formatted the original HDD and installed Linux on it. Save for the ones that would make the box go absolutely berserk (needing to remove the battery and reset everything back) no change in BIOS settings made any difference whatsoever. Eventually (from one to sixty days) it would rear its ugly head again. In the end I have learned to live with this absolute POS BIOS that Sun Microsystems wrote into an otherwise very well built box, ahead of its time in many respects. But I digress ... The TPM settings in the BIOS have always been set to [Disabled] so I have taken up on your suggestion and changed the TPM settings to [Enabled] according to the instructions here: https://docs.oracle.com/cd/E19591-01/html/E23171/z40013591297501.html What I have not done is reset the TPM as it is [Unowned] as I fear some sort of 'retribution' if I fiddle with that. The only difference is that I now have a TPM related entry in /var/log/dmesg: [code] tpm tpm0: [Hardware Error]: Adjusting reported timeouts: A 750->750000us B 2000->2000000us C 750->750000us D 750->750000us [/code] I now have to wait and see if the fault occurrs again. If and when it does, I will post here again. Once again, thank you for taking the time to write here about this. Best, JHM Hello:
An update of sorts, but in maybe relevant.
> ... wait and see if the fault occurrs again.
Setting TPM to enabled has yet to produce the fault.
But this is with my box running Devuan Linux Beowulf with a backported kernel:
[code]
~$ uname -a
Linux devuan 5.10.0-0.deb10.16-amd64 #1 SMP Debian 5.10.127-2~bpo10+1 (2022-07-28) x86_64 GNU/Linux
~$
[/code]
ie: Debian 5.10.127 kernel
Like I mentioned earlier, I have never found a way to reproduce it so it is a matter of waiting to see 'if and when' it crops up again. It has been that way since I installed Linux on this box.(2015)
But then, while testing a Linux Devuan 5.0.0 (Daedalus) Live from a USB stick the fault happened at shutdown, for the first time after enabling TPM in the BIOS.
[code]
~$ uname -a
Linux devuan 6.1.0-10-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.1.38-1 (2023-07-14) x86_64 GNU/Linux
~$
[/code]
Rather dissapointed at this being so, I went back to working on other things with my usual Beowulf (Debian 5.10 kernel) installation, booting and shutting down (as usual) a few times during a day's work without incident.
When finished, I went back to booting the USB stick to continue testing the latest Devuan Daedalus release and the fault occurred yet again.
TL;DR:
With the Debian 5.10.xxx (and all previous) kernels, the fault has always occurred albeit in the usual unpredictable/non-reproducible manner.
But with the Debian 6.1.38 kernel in Devuan Daedalus, if the TPM feature is enabled in the BIOS it happens *every* time.
The Sun Ultra 24 is ca.2007 hardware and the last available BIOS (1.56) is from late 2011 so I expect that the on-board 1.1/1.2 TPM [i]thing[/i] it carries is probably as much a POS as the board's BIOS itself.
Given my limited experience with all this, I can only speculate that whatever bugs exist within my mainboard's BIOS *may* have been partly worked around in Linux kernel v. 6.1.38.
ie: the shutdown problem solved, albeit not entirely, by disabling TPM in the BIOS.
But I will have to update my rig to Devuan Daedalus to find out and I'm not quite there yet.
I'd appreciate any comments on this.
Best,
JHM
|