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

Fernando · 2026-04-08 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 · 2026-04-09 02:51:54

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 (2026-04-10 16:19:32)

seth · 2026-04-09 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

Fernando · 2026-04-10 15:28:15

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:

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

Incomplete Shutdown: The GPU remains energized, causing thermal output and battery depletion.
Log Pollution: Constant AE_AML_BUFFER_LIMIT entries in system logs.
Method Failure: Breakdown of _OFF and _PS3 power management routines.
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.

Fernando · 2026-04-10 15:43:55

Since the computer is sold without an operating system and no exclusive use restriction with Windows is specified, the product is considered to fall short of reasonable expectations for general performance.
Therefore, after HP's evasiveness, lack of support, and their apparent unwillingness to resolve the issue I've practically outlined for a solution, along with their argument that this computer should only work with Windows, I requested a refund due to a factory defect.
I only hope that all the analysis and evidence provided regarding the problem with this computer running Linux operating systems will help other users with the same issue and, above all, provide clarity when choosing a new computer and which manufacturers to select.

Thank you very much for your patience and understanding.

PD: A very angry newbie with HP.

5hridhyan · 2026-04-10 15:50:20

PD: A very angry newbie with HP.

Welcome to the party!

Fernando · 2026-04-10 15:57:15

Thank you very much for your response, but as I explained in the last message I posted today, this is not a problem related to the kernel or the Linux environment and can only be definitively resolved by HP, who are responsible for this problem since it is a BIOS programming error, even though they hide behind the excuse that they "can help me install Windows so that it works correctly."

Welcome to the party too! )

Arch Linux

#1 2026-04-08 18:53:15

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

#2 2026-04-09 02:51:54

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

#3 2026-04-09 14:25:30

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

#4 2026-04-10 15:28:15

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

#5 2026-04-10 15:43:55

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

#6 2026-04-10 15:50:20

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

#7 2026-04-10 15:57:15

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

Board footer