You are not logged in.
Hello,
I have recently installed Arch on my new laptop. I am a Linux beginner but have been able to solve most of my issues so far using various online resources. I have been unable to solve this issue for several days however, and it concerns my safety. It is not something I'm willing to leave to chance again. Overheating lithium batteries are no joke.
Hardware:
- Laptop: HP Omen 16-ap0022no
- BIOS/UEFI version: F.08
- Kernel: 7.2.9-arch1-1
- Bootloader: systemd-boot 262-1-arch, stub=same
What happened:
Yesterday my laptop was powered off in a plastic bag, in my backpack, next to my tablet. Luckily I have installed an alarm app which notifies me whenever the tablet's battery is overheated. The tablet's battery had reached an internal temperature of 45°C, which is almost enough to trigger thermal emergency shutdown. The plastic bag had almost melted. When I started the laptop I was able to confirm that the CPU usage was virtually non-existent, stable around 2% after booting, but the temperature was over 85°C. I quickly looked into how to control the fans manually, put them on max for 5 min and then everything was fine.
It seems the laptop is not shutting down correctly, and it creates a dangerous situation where something is generating heat but the fans do not respond (while in this "off" state).
Things that do not work:
- "shutdown now"
- "systemctl poweroff"
- "poweroff"
- "sudo systemctl poweroff --force --force"
Pressing and holding the power button does not seem to work either, however, this is hard to confirm due to the reason below.
What has made the troubleshooting difficult is that I only notice the problem by the fact that heat has built up over a longer period of time. This is making it difficult to find the root cause. My only reliable way of shutting the laptop off is to leave it on until the battery dies. The battery is very difficult to remove from the chassis, making this way of shutting off in an emergency difficult too.
Worth mentioning too is that whenever I start it again after a "shutdown" I see the kernel start and I have to log in anew. It is a normal startup, not a startup as if it was waking from sleep. My own theory is that some firmware command is not sent to the hardware, which leads to the CPU (or something else) generating heat without the fans being active or able to compensate. This is scary because it also makes me doubt whether emergency thermal shutdown conditions would work from the hardware side of things. Another possibility is that it is rebooting itself, but I have not heard the fans whir and have not seen anything like that in practice.
Lastly I want to mention that I see this as a learning opportunity. I am not looking for a quick solution, I would like to understand how to troubleshoot these issues myself, I am simply wary of "trial and error" in a situation like this. Much rather than a few terminal commands to paste, I would appreciate tips on how to troubleshoot and log this in a good way, and explanations of why I should check something are very welcome.
Thank you!
Last edited by h4kken (Yesterday 19:11:45)
Offline
Things that do not work:
Those are all t he same.
Does https://wiki.archlinux.org/title/Keyboa … el_(SysRq) + o cut power?
Though w/
Pressing and holding the power button does not seem to work either
I'd not hold my breath.
What has made the troubleshooting difficult is that I only notice the problem by the fact that heat has built up over a longer period of time.
There'd also be unexpected battery drain.
But just to be clear: when you shut the system down, when you shut the system down you see the system log tailing w/ "system about to power down" or something like that and then the panel and keyboard and all other LEDs turn off (along the fans if they're currently running) - pressing some keys does absolutely nothing
Can you reboot the system?
Is the firmware/BIOS/UEFI up to date?
I was able to confirm that the CPU usage was virtually non-existent, stable around 2%
Something other than the CPU might draw the power, though I assume only the GPU could cause that amount of heat.
Is it a hybrid graphics system? Can you disable the GPU?
You can try to lie to the ACPI eg,
acpi_osi=! acpi_osi="Windows 2022"https://learn.microsoft.com/en-us/windo … inacpi-osi
Speaking of which: is there a parallel windows installation?
Offline
Update: found the cause and got it working.
Took it down to the computer/coding club at my uni and troubleshooted with a group of people far better at Linux than me.
The overall process was complicated and took a long time, this is an AI-generated summary to condense our accumulative effort into a readable format:
It's a known bug on the OMEN 16-ap0xxx (board 8E35) with the RTX 5060/5070. When you shut down from Linux the firmware never runs the power-down for the NVIDIA GPU, so the GPU stays powered after "shutdown" and draws around 20 W with the fans off. Doesn't happen from Windows. Lots of people have the same problem on Debian, Mint, Ubuntu, CachyOS and Arch:
https://forums.developer.nvidia.com/t/h … bug/364074 (and on the Arch wiki)
My earlier measurements fit this. With SysRq+o it drew ~20 W while "off", normal poweroff was lower but not consistent.
The fix comes from these two repos:
https://github.com/paolo-de-marinis/omen-acpi
https://github.com/Adiakys/omen16-s5-fix
It patches the DSDT so that _PTS(5) (shutdown) sets PEGP.OMPR = 3 and calls PEGP._PS3(), which ends up in PG00._OFF() and actually cuts the GPU power. The BIOS isn't modified, the patched table is loaded from an initrd at boot.
Neither repo supports Arch with systemd-boot, and my setup boots a UKI, so I did it by hand:
- dumped DSDT + SSDTs from /sys/firmware/acpi/tables and decompiled them with iasl
- checked that my DSDT revision is 0x01072009 (same as F.11/F.13 even though I'm on F.08) and that the SSDT has the OMPR == 0x03 -> PG00._OFF() path
- applied the same _PTS patch as the Ubuntu script, bumped the OEM revision, compiled (0 errors) and checked with diff that only those 3 things changed
- packed it into an uncompressed cpio under kernel/firmware/acpi/dsdt.aml
- made a separate initramfs with mkinitcpio -g and a separate systemd-boot entry with the cpio as the first initrd. My normal UKI entry is untouched and still the default
- dmesg shows "Table Upgrade: override [DSDT-HPQOEM-8E35]" with revision 0107200A
Result: I shut it down on battery and left it for about 45 minutes. The laptop stayed cool and the battery barely dropped, compared to ~20 W drain before.
Things to know if you try this:
- Secure Boot has to be off, otherwise the kernel ignores the override
- the fix entry needs its initramfs rebuilt after kernel updates
- after a BIOS update, delete the fix entry and redo everything, since the DSDT changes
- the WQBZ AE_AML_BUFFER_LIMIT error is still there, it's a separate bug and doesn't affect this
- it's experimental, use at your own risk
Offline