After shuting down HP OMEN 16-ap0038ns does not fully shutdown

Fernando · Yesterday 18:53:15

TECHNICAL REPORT – SHUTDOWN FAILURE (HP OMEN)

Likely ACPI Firmware Bug

1. 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

2. 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.

3. 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)
• Arch, CachyOS
• Recent Linux kernels (6.18.13, 6.12.77, 6.18.13, 6.18.19, 6.19.9, 6.19.11, 7.0 rc2, 7.0 rc3, and 7.0 rc4. y 7.0rc6)
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_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

4. 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.2 Shutdown execution path
_PTS → PTS → HPTS + CPTS + OPTS
• HPTS → OS-dependent logic
• CPTS → calls to SMI (\_SB.WSMI)
• OPTS → S3/S4 handling

4.3 Use of proprietary interfaces
\_SB.WMID.*
\_SB.WSMI
Heavy reliance on:
• WMI (Windows Management Interface)
• SMI (System Management Interrupts)

5. 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

6. 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)

7. 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

8. 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

9. 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

10. 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.

5hridhyan · Today 02:51:54

Thanks for detailed report, as this likely involves vendor-specific ACPI behavior, it may ultimately require a fix from HP...
if possible, could you please post your full journal logs, of your Arch for such run? (eg. `sudo journalctl -b -1 | nc termbin.com 9999`, with loglevel=7 and no quiet or splash as kernel param, -1 for previous boot)
sometimes there are hints about partial workarounds or kernel-side quirks that can help in specific cases

Edit:
You may also consider reporting this upstream (kernel bugzilla) if you haven’t already, in case maintainers can identify a possible workaround...

Last edited by 5hridhyan (Today 03:03:11)

seth · Today 14:25:30

Windows 11 → Proper shutdown (true S5 state)

3rd link below. Mandatory.
Disable it (it's NOT the BIOS setting!) and reboot windows and linux twice for voodo reasons.

Because windows doesn't at all default to S5 but S4, https://en.wikipedia.org/wiki/ACPI#Global_states

Arch Linux

#1 Yesterday 18:53:15

After shuting down HP OMEN 16-ap0038ns does not fully shutdown

#2 Today 02:51:54

Re: After shuting down HP OMEN 16-ap0038ns does not fully shutdown

#3 Today 14:25:30

Re: After shuting down HP OMEN 16-ap0038ns does not fully shutdown

Board footer