I have been unable to resolve a total power-off issue on an HP OMEN 16-ap0038ns running Fedora 43 (Gnome & KDE), Fedora 44, Ubuntu 25.10, and CachyOS 260308.
Known Facts:
Residual Power Consumption: A standard shutdown leaves residual power consumption; the device remains warm after powering off via sudo systemctl poweroff -i or sudo systemctl poweroff --force --force.
LUKS Interaction: After the shutdown command, the system prompts for the LUKS disk encryption password, indicating that Linux is indeed attempting a full power-down sequence.
Hard Reset: Holding the power button for 10 seconds successfully cuts all power.
Systemd: No unusual configurations found in systemd.
Xorg: No forced configurations in Xorg.
Sleep States: The system likely only supports s2idle (Modern Standby).
Kernels Tested: Updated and tested kernels: 6.18.13-200.fc43.x86_64, 6.12.77, 6.18.13, 6.18.19, 6.19.9, 7.0 rc2, 7.0 rc3, and 7.0 rc4.
BIOS: Updated to the latest version available (F.11 Rev.A). Settings:
USB Charge: Disabled
Power on when Lid is opened: Disabled
Wake on LAN: Disabled
ACPI Logs (journalctl -b | grep -i acpi):
ACPI tables load correctly.
The kernel recognizes all BIOS tables: FACP, DSDT, SSDT, TPM2, CRAT, BGRT, etc.
Power resources are registered: Power Button, Lid Switch, batteries, AC Adapter. This indicates Linux is aware of all hardware power management elements.
HP Firmware trust issue:ACPI: [Firmware Bug]: BIOS _OSI(Linux) query ignored.
GPU Control implementation errors:
ACPI: video: [Firmware Bug]: ACPI(PEGP) defines _DOD but not _DOS
ACPI Warning: \_SB.PCI0.GPP0.PEGP._DSM
ACPI PM and S-states:ACPI: PM: (supports S0 S4 S5). This confirms the BIOS supports S0 (Working), S4 (Hibernation), and S5 (Soft Off/Full Shutdown).
Power-off Logs (journalctl -b -1 | grep -i "poweroff"): Linux sends the shutdown command correctly, but it is either not acknowledged or ignored:
System Power States: Checking /sys/power/state only shows: freeze mem disk. Linux only recognizes suspend (mem), hibernate (disk), or freeze.
S5 Handling: S5 (Total Power Off) is managed by the firmware/BIOS via ACPI and is not an “active” state from the Linux perspective; therefore, poweroff fails to trigger a real S5 state on this hardware.
Problem Summary
The system exhibits inconsistent shutdown behavior depending on the operating system:
• Windows 11 → Proper shutdown (true S5 state)
• Linux (multiple distributions and modern kernels) → Improper shutdown
Observed symptoms on Linux:
• Residual battery drain after shutdown
• Noticeable heat while powered off
• Dedicated NVIDIA GPU remains active
• System does not reach true S5 state
Direct Technical Conclusion
This behavior strongly indicates a firmware-level ACPI implementation issue.
More specifically:
The firmware fails to correctly transition the system to S5 and does not properly power down devices (_PS3), particularly outside a Windows environment.
Objective Evidence
3.1 Hardware ruled out
• Shutdown works correctly in Windows
• No residual power consumption
• GPU powers off correctly
Hardware is fully functional
3.2 Reproducibility under Linux
Tested across multiple environments:
• Fedora (latest versions)
• CachyOS
• Recent Linux kernels
Issue is fully reproducible
3.3 ACPI parameter testing
Multiple kernel parameters tested:
acpi_osi=! acpi_osi=“Windows 2012”
acpi_osi=! acpi_osi=“Windows 2013”
acpi_osi=! acpi_osi=“Windows 2021”
acpi_osi=! acpi_osi=“Windows 2021”
acpi_sleep=s5
acpi_rev_override=5
Results:
• _OSI strings are correctly accepted by firmware
• Different ACPI paths are triggered (OSVR changes accordingly)
• No configuration results in correct shutdown
3.4 ACPI firmware errors
Consistent errors observed:
ACPI BIOS Error (bug): AE_AML_BUFFER_LIMIT
Method: _SB.WMID.WQBZ
ACPI Error: Aborting method _SB.WMID.WQBE
ACPI Warning: Time parameter 200 us > 100 us violating ACPI spec
These errors clearly indicate:
• Faulty AML implementation in firmware
• Non-compliance with ACPI specifications
Firmware (DSDT) Analysis
The ACPI tables were extracted and analyzed.
4.1 OS-dependent logic
If (_OSI (“Windows 2012”)) { OSVR = 0x0F }
If (_OSI (“Windows 2013”)) { OSVR = 0x10 }
The OSVR variable controls critical execution paths.
4.3 Use of proprietary interfaces
_SB.WMID.*
_SB.WSMI
Heavy reliance on:
• WMI (Windows Management Interface)
• SMI (System Management Interrupts)
Critical Failure Identified
Device power-off methods (_PS3) are not executed correctly under Linux.
Consequences:
• NVIDIA GPU remains powered after shutdown
• System enters an undefined intermediate power state
• Residual power draw and heat generation
Critical finding: runtime power management hang
• Writing to:
/sys/bus/pci/devices/0000:01:00.0/power/control
with value auto causes the system to hang (command does not return) causes the process to enter uninterruptible sleep (state D)
• This indicates:
◦ The kernel is blocked waiting for ACPI firmware response
◦ The ACPI method handling GPU power transition does not return
• Additionally:
◦ ACPI errors (AE_AML_BUFFER_LIMIT) are present during boot
Conclusion:
The ACPI firmware contains defective AML code that causes kernel-level blocking during power state transitions, ACPI methods responsible for GPU power management are blocking or malfunctioning
• The GPU does not enter low-power state even during normal runtime
• Runtime PM is enabled but ineffective (active state persists)
• This strongly suggests ACPI firmware is not exposing or executing proper power methods (_PS3 / _OFF)
Physical Evidence
Direct inspection confirms:
Heat originates from the discrete NVIDIA GPU after shutdown
This confirms:
• GPU does not reach D3 (off) state
• Device remains powered
Final Diagnosis
The firmware ACPI implementation is effectively Windows-dependent and does not behave correctly with other operating systems.
This implies:
• Non-standard ACPI behavior
• Improper reliance on OSI-based branching
• Incomplete or failing execution of power-off paths
Request to HP Engineering
Please review and address the following:
Critical
• Correct implementation of _S5 state
• Ensure execution of _PS3 for all devices (especially GPU)
ACPI compliance
• Fix AML issues (AE_AML_BUFFER_LIMIT)
• Review WMID and WSMI methods
Compatibility
• Ensure correct behavior under Linux
• Remove reliance on Windows-specific execution paths
Final Statement
This is not a configuration or kernel issue.
The issue is fully reproducible and OS-dependent.
The system does not correctly implement ACPI shutdown outside Windows, strongly indicating a firmware defect.