• ×
    Information
    Need Windows 11 help?
    Check documents on compatibility, FAQs, upgrade information and available fixes.
    Windows 11 Support Center.
  • post a message
  • ×
    Information
    Need Windows 11 help?
    Check documents on compatibility, FAQs, upgrade information and available fixes.
    Windows 11 Support Center.
  • post a message
Guidelines
Join the HP Community Solve‑a‑thon | Help Others & Share Your Solutions | Live on Zoom | 2:30 PM to 2:30 AM IST | Every Wednesday Click here to know more
HP Recommended

@Pallipurath Thank you for the clarification regarding HP's official Windows-only support policy.

I wanted to add an update because I have continued investigating the firmware side of this issue and have now published OMEN ACPI Toolkit v2.4.0:

https://github.com/paolo-de-marinis/omen-acpi

The project is based on my HP OMEN MAX 16-ap0006sl, board 8E35, BIOS F.13. It remains explicitly limited to that physically validated reference machine; I am not claiming compatibility with the 16-ap0038ns or with the whole 16-ap0xxx family.

However, the investigation may be useful to HP's BIOS/firmware engineering team because the shutdown problem can be corrected on the reference machine entirely through an ACPI-table override, without modifying the Linux kernel or replacing the firmware's existing GPU power-off implementation.

The most important result is that the firmware already contains the required discrete-GPU power-off path. On the reference firmware, the working S5 correction is essentially:

_PTS(5) → OMPR = 3 → PEGP._PS3() → PG00._OFF()

The override only makes the firmware's existing _PS3() path run while preparing S5. With this change, the previously observed post-shutdown GPU heating and power consumption disappear on the validated machine.

I therefore think it would be worthwhile for HP firmware engineering to evaluate whether the equivalent sequencing should be performed directly by the platform firmware during S5, rather than depending on OS/driver-specific state to leave the discrete GPU in the expected condition. This could make the shutdown path more robust and less dependent on the particular operating system or driver stack, improving ACPI interoperability with other operating systems while preserving the current Windows behaviour.

The updated investigation also separates a second firmware issue from the shutdown correction. WQBZ can dereference BF01[Local5] before checking that Local5 is still within SizeOf(BF01), producing the observed AE_AML_BUFFER_LIMIT. The experimental Combined variant fixes that independently by checking the buffer bound before dereferencing it. I no longer present the WQBZ error as the demonstrated root cause of the S5 problem.

So, the two areas I would suggest reviewing are:

  1. S5 discrete-GPU sequencing: evaluate invoking the existing PEGP power-down path reliably during _PTS(5) or the appropriate firmware S5 preparation path, so that PEGP._PS3() can reach PG00._OFF() without depending on Windows-specific shutdown behaviour.

  2. WQBZ buffer handling: bounds-check Local5 against SizeOf(BF01) before dereferencing BF01[Local5].

I would also suggest reviewing the NVDE/GSTA guards around PG00._OFF() in the context of S5. I am not suggesting simply forcing NVDE = 1: the current investigation shows that the NVIDIA driver normally re-arms NVDE, and the experimental fix deliberately preserves the firmware's existing guards. The question for firmware engineering is whether the final S5 power-off sequence can be made robust without relying on a particular OS/driver interaction.

I fully understand that HP Support cannot validate or support my Linux ACPI override. I am not asking HP to support the toolkit or troubleshoot Linux. My request is that these reproducible firmware-level findings be evaluated by the BIOS engineering team as possible candidates for a future HP-signed BIOS update.

Windows shutting down correctly shows that the hardware is capable of reaching the intended final state, but I do not think that by itself establishes that the underlying issue is exclusively in the Linux kernel. The ACPI override demonstrates that changing only the firmware-provided shutdown sequencing is sufficient to correct the observed behaviour on the validated reference machine.

Could you please forward the repository and these technical findings to the appropriate HP BIOS/firmware engineering team for evaluation? If possible, I would also appreciate confirmation that they have been forwarded.

† The opinions expressed above are the personal opinions of the authors, not of HP. By using this site, you accept the <a href="https://www8.hp.com/us/en/terms-of-use.html" class="udrlinesmall">Terms of Use</a> and <a href="/t5/custom/page/page-id/hp.rulespage" class="udrlinesmall"> Rules of Participation</a>.
-->