After shuting down from a Linux distribution, HP OMEN 16-ap0038ns does not fully shutdown

[FerCasF]

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:

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

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

3- Hard Reset: Holding the power button for 10 seconds successfully cuts all power.

4- Systemd: No unusual configurations found in systemd.

     Xorg: No forced configurations in Xorg.

5- Sleep States: The system likely only supports s2idle (Modern Standby).

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

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

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

9- Power-off Logs (journalctl -b -1 | grep -i "poweroff"):
Linux sends the shutdown command correctly, but it is either not acknowledged or ignored:

     systemd-poweroff.service: Deactivated successfully

     Reached target poweroff.target - System Power Off

10- System Power States: Checking /sys/power/state only shows: freeze mem disk. Linux only recognizes suspend (mem), hibernate (disk), or freeze.

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

12 GRUB/Kernel Boot Parameters Tested:

acpi=force

acpi=noirq

acpi=off (Testing only, not recommended for use)

reboot=pci or reboot=efi

acpi_osi="Windows 2022"

acpi_osi= "Windows 2021"

acpi_osi= "Windows 2020"

Result: No change.

13- Sleep Method: cat /sys/power/mem_sleep returns [s2idle]. The system is not using "deep" sleep.

[leslviv]

I have the same issue! Please keep us updated on any progress, sir

[FerCasF]

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)
    • 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

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.

[FerCasF]

Technical Conclusion: Shutdown Issue on HP OMEN (NVIDIA PEGP GPU)

Device: OMEN Gaming Laptop 16-ap0038ns (C92R7EA#ABE)

BIOS Version: F.11 Rev.A (Dec 23, 2025)

Issue Detection Date: 02/25/2026

Problem: Inability to perform a complete system shutdown in Linux (multiple distributions and kernels) due to an ACPI failure related to the NVIDIA discrete GPU (PEGP).

---

1. Context

The Linux system detects ACPI errors during the shutdown sequence. The primary failure is linked to the NVIDIA PEGP discrete graphics card. The observed behavior is as follows:

• Linux: Shutdown does not complete; the GPU remains powered on, generating residual heat in the lower-center chassis and causing battery drain.

• Windows: Shutdown functions correctly, indicating an ACPI compatibility gap between the BIOS firmware and the Linux kernel.

2. GPU Identification and Involved Methods

The PEGP GPU is exposed in the ACPI table as: _SB.PCI0.GPP0.PEGP

The firmware does not implement standard ACPI power-off methods (_PS3 / _OFF). Instead, the BIOS utilizes a proprietary HP method: _SB.WMID.WQBZ

• This method manages the power state of the discrete GPU.

• Upon execution, Linux reports:

  ACPI BIOS Error (bug): AE_AML_BUFFER_LIMIT, Index (0x32) is beyond end of object (length 0x32) ACPI Error: Aborting method \_SB.WMID.WQBZ due to previous error

3. Affected Variables

Within the WQBZ method, buffers are utilized without proper definition or sizing:

Fragmento de código

Method (WQBZ, 1, NotSerialized)
{
    N003 = WBU1 /* \_SB_.WMID.WQBZ.WBU1 */
    N011 = WBU2 /* \_SB_.WMID.WQBZ.WBU2 */
    ...
}

The Root Cause:

• WBU1 and WBU2 are buffers that the method attempts to populate, but the BIOS fails to define an explicit and sufficient fixed size.

• Linux strictly validates buffer boundaries and triggers AE_AML_BUFFER_LIMIT when the method attempts to write data beyond the object's allocated length.

• Essentially, these variables are undersized or malformed according to the AML (ACPI Machine Language) standard.

Consequence: The WQBZ method aborts → the GPU power-off sequence fails → residual heat and battery consumption persist, potentially leading to long-term hardware degradation.

4. Code Snippets

ACPI Errors detected in Journalctl:

Plaintext

Apr 09 11:45:23 Omen-nando kernel: ACPI BIOS Error (bug): AE_AML_BUFFER_LIMIT, Index (0x000000032) is beyond end of object (length 0x32)
Apr 09 11:45:23 Omen-nando kernel: ACPI Error: Aborting method \_SB.WMID.WQBZ due to previous error

WQBZ Method in DSDT:

• Line 18112: Method (WQBZ, 1, NotSerialized)

• Line 18140: N003 = WBU1

• Line 18216: N011 = WBU2

Incorrectly Sized Variables:

• WBU1: Buffer without explicit sizing.

• WBU2: Buffer without explicit sizing.

Observations:

• WBU1, WBU2, and WBU3 are ACPI buffers expected to receive data of a specific length.

• In Windows, these buffers are initialized correctly via the proprietary WMI interface.

• In Linux, the execution exceeds the buffer capacity, triggering the limit error.

• PCI GPU Port: 0000:01:00.0

5. Impact Analysis

1. Incomplete Shutdown: The GPU remains energized, causing thermal output and battery depletion.

2. Log Pollution: Constant AE_AML_BUFFER_LIMIT entries in system logs.

3. Method Failure: Breakdown of _OFF and _PS3 power management routines.

4. OS Disparity: Windows likely ignores the buffer overflow or handles it through proprietary drivers, masking the firmware bug.

6. Mitigation & Solutions

• BIOS/UEFI Update: HP must rectify the buffer definitions and PEGP power management logic in a future firmware release.

7. Conclusion

The shutdown failure stems from a programming error in the BIOS firmware, specifically within the WQBZ method. The variables WBU1 and WBU2 lack adequate sizing, causing a fatal AE_AML_BUFFER_LIMIT error in Linux. This prevents the GPU from powering down.

Recommendation: Await an official BIOS update from HP.

Interim Workaround: Until a patch is released, the only reliable way to ensure a full hardware shutdown is to perform the power-off sequence from within Windows.

[m4te855]

I have the same issue. I researched a little bit an I think its the gpu, but I am not 100% sure

[yuvrajtalukdar]

Facing the same issue. Seems to be a firmware problem, and effects ubuntu and arch linux at least. Effects shutdown and hibernate performed from linux. 

[FerCasF]

I finally found the problem in the BIOS/ACPI programming. HP hasn't fixed the bug in BIOS F.12, and the computer was checked by HP's official technical service, which proceeded to completely replace the motherboard, verifiable by the change in the motherboard's serial number.

However, the shutdown failure is clearly due to a programming error in the BIOS firmware, specifically in the `WQBZ` method that manages the discrete GPU's power. The `WBU1` and `WBU2` variables are not of an adequate size, causing `AE_AML_BUFFER_LIMIT` in Linux. This prevents the GPU from completely shutting down, causing heat and battery drain in non-Windows operating systems.

Therefore, the problem remained exactly the same, so I returned the HP Omen because the source of the problem is not a specific hardware defect, but a structural flaw in the firmware (BIOS/ACPI).

This problem causes the device to continue consuming power and generating heat even when it's turned off, which is a functional defect.

I've now bought a Slimbook Creative and it works really well.