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

I bought the same laptop recently and got the same issue on Linux Mint 23. Tried the newest F.13 Rev.A BIOS and its still the same. Can someone from HP escalate the issue ? i see the others have much detailed answers that can help HP engineers fix it easily.

HP Recommended

I have the same issue : (

I encourage anyone facing it to add a comment here to add visibility to this serious problem

HP Recommended

Same issue for me !! 
OMEN 16-ap0056nf 

Fedora 44

HP Recommended

Hi @Monkey39 

 

Welcome to the HP Support Community.

 

Thank you for posting your query.

 

I understand that you are experiencing an issue with your HP OMEN, as the system does not shut down completely after you initiate a shutdown from your Linux distribution. I would request you to please elaborate your concern.

Meanwhile I would request you to please perform the below step and share the results.

 

Run HP Hardware Diagnostics

Run the built-in HP diagnostics:

  • Turn off the notebook.
  • Press Esc repeatedly during startup.
  • Select F2 – System Diagnostics.
  • Run:
  • System Test
  • Motherboard Test
  • Power Test
  • Battery Test
  • Ensure all tests pass.

Hope this helps, Please revert with the results.

 

Take care and have an amazing day!

I'm an HP Employee.


If this reply helped resolve your issue, please select the Accept as Solution as it helps others in the community quickly find the answer they’re looking for.


And if you found this reply helpful, clicking Yes below is a great way to let us know we’re providing the support you need, as it encourages us to keep improving and sharing helpful guidance.

HP Recommended

Hi Pallipurath

Unfortunately everything you asked for is completely irrelevant. I'm not trying to be rude, but it simply shows you don't have a full grasp of the issue at hand. Let me explain it below:

1. Pick any HP Omen 16 laptop from 2024-present with an AMD GPU with iGPU and dedicated GPU (ie: 5060, 5070, 5080 etc).
2. Disable UEFI Secure Boot.

3. Install *ANY* majorLinux distro such as Ubuntu, Fedora, Mint, Arch, Alma, POPOS)

4. Do all the updates.

5. Shutdown the laptop normally through the OS shutdown menu.


The laptop *appears* to be shut down, but the dedicated nVidia card NEVER powers down. It still draws power. This increases the laptop's thermals, and drains the battery when the rest of the laptop is powered off. I attempted the same on other brands of laptops and they do not have this issue.


Here are the relevant links from around the internet complaining of the same issue. This issue is so prevelant that even Google AI and CoPilot know about it when you ask.

https://www.reddit.com/r/HPOmen/comments/1u38zti/linux_bug_on_hp_omen_not_shutting_down_the_pc/
https://forum.manjaro.org/t/hp-omen-16-drains-battery-even-if-shut-down/186509
https://discussion.fedoraproject.org/t/technical-issue-incomplete-shutdown-on-hp-omen-16-ap0038ns/18...
https://bbs.archlinux.org/viewtopic.php?id=313030


There's even a post in the nVidia forums to see if they would even take a look at it:

https://forums.developer.nvidia.com/t/hp-omen-16-rtx-5060-battery-drains-after-shutdown-on-linux-gps...


Please escalate this to engineering to have this fixed in a firmware/BIOS update. I've already seen someone return their laptop because of this.


Edit: All the info you need is in the first few posts at the beginning of this thread. I have no idea how this is still getting missed. 

HP Recommended

The level of incompetence is incredible. People have already troubleshot and described the exact issue and solution in this thread. Let me sum it up for you:

Root cause: Defective AML code in the DSDT, specifically the \_SB.WMID.WQBZ method (and related WQBE path). Buffers WBU1/WBU2 lack proper fixed sizing. When Linux executes the method during the shutdown path, it hits an AE_AML_BUFFER_LIMIT error and aborts. As a result, the NVIDIA discrete GPU (PEGP) never receives a successful _PS3/_OFF, so the system never reaches true S5. Residual power draw and heat remain.

Required fix: Correct the buffer definitions and GPU power-management logic in the ACPI tables so that the WQBZ method (and full S5 transition) succeeds under any OS, not only Windows. A BIOS update is needed.

 

All of us here will buy you a beer if you can escalate this and make it happen. Cheers!

HP Recommended

I have used different distros on my Omen 16-ap0xxx. I used Claude Opus 5 last night and it found the same issues with the firmware. It just seems the people working on this firmware are forced to use vibe coding 100% to make it. How the hell has something like this not been fixed. I can understand that right now its a smaller portion of the community that is using, or wanting to use Linux on this laptop. But with how Microslop is messing up Windows 11, more people are moving to Bazzite, CachyOS, Nobara, among other. The Omen line is absolutely amazing on the hardware level. It just getting screwed by garbage software. If this firmware screw up could be fixed then I could see that increase sales. As long as the laptops are affordable, or can be found for good prices. 

HP Recommended

Hi !

 I think i've got it working, not sure 100% i will make some more tests  !! 

So I extracted and decompiled the DSDT et changed the code of the WQBZ method.
I had two erros in the ACPI. 

sudo dmesg | grep ACPI


The first one in the WQBZ method as stated in the original message of this thread:

[    8.650449] ACPI BIOS Error (bug): AE_AML_BUFFER_LIMIT, Index (0x000000032) is beyond end of object (length 0x32) (20251212/exoparg2-393)

[    8.650459] ACPI Error: Aborting method \_SB.WMID.WQBZ due to previous error (AE_AML_BUFFER_LIMIT) (20251212/psparse-529)

[    8.650466] ACPI Error: Aborting method \_SB.WMID.WQBE due to previous error (AE_AML_BUFFER_LIMIT) (20251212/psparse-529)

 

The second one concerning SystemCMOS:

[    7.433236] ACPI Error: No handler for Region [VRTC] (00000000e4997109) [SystemCMOS] (20251212/evregion-131)

[    7.433247] ACPI Error: Region SystemCMOS (ID=5) has no handler (20251212/exfldio-261)

[    7.433261] ACPI Error: Aborting method \TAAD.RTWT due to previous error (AE_NOT_EXIST) (20251212/psparse-529)

[    7.433464] ACPI Error: Aborting method \TAAD._GRT due to previous error (AE_NOT_EXIST) (20251212/psparse-529)


First Error 
The culprit is not necessary the WBU1 and WBU2 buffers but  BF01.

The original code was (found in the If ((Arg0 == Zero)) and in the If ((Arg0 == One))part of the code):

Line 17746 : 

While ((Local2 != N018))
{
BF01 = DerefOf (N015 [Local2])
Local5 = Zero
While ((DerefOf (BF01 [Local5]) != Zero))
{
Local3 = DerefOf (BF01 [Local5])
N005 [Local1] = Local3
Local5++
Local1++
}

N005 [Local1] = 0x2C
Local1++
Local2++
}


I changed it to : 

     While ((Local2 != N018))
        {
            BF01 = DerefOf (N015 [Local2])
            Local5 = Zero

            // --- CORRECTIF HP WMI OOB SÉCURISÉ (Arg0 == 0) ---
            Local6 = SizeOf (BF01)
            While (Local5 < Local6)
            {
                If (DerefOf (BF01 [Local5]) == Zero)
                {
                    Break
                }

                Local3 = DerefOf (BF01 [Local5])
                N005 [Local1] = Local3
                Local5++
                Local1++
            }
            // --------------------------------------------------

            N005 [Local1] = 0x2C
            Local1++
            Local2++
        }


This modification got me rid of the first error

Second Error

This one concerns the "Device (TAAD)" is the DSDT. (Line 6142) 
I disabled all the functions is this device.

A new function was added to the Device:

Method (_STA, 0, NotSerialized) // _STA: Status
{
Return (Zero)
}


Every other function returns either  Return (Zero) or  Return (One) (That was Geminis decision  😅)

This got me rid of the second Error

Result
I think my laptop shutsdown correctly now. But this is a temporary solution as I have injected it into the kernel. So as soon as the kernel changes i have to push the modification again.

How to


Backup kernel

sudo cp /boot/initramfs-$(uname -r).img /boot/initramfs-$(uname -r).img.bak

Extract running DSDT file

sudo cat /sys/firmware/acpi/tables/DSDT > dsdt.dat

Decompile DSDT (Creates dsts.dsl file)

iasl -d dsdt.dat

Make the modifications in the Code in the dsdt.dsl file.

Once done compile dsdt.dsl

iasl -ve -tc dsdt.dsl

 

create folder structure for the dsdt.aml file (Compiled file of the dsdt.dsl)

mkdir -p kernel/firmware/acpi

copy the dsdt.aml  to acpi folder

cp dsdt.aml kernel/firmware/acpi/

Compile it

find kernel | cpio -H newc --create > acpi_override.img

copy the generate .img to the boot folder

sudo cp acpi_override.img /boot/

Concat the .img with the actual kernal .img

sudo sh -c 'cat /boot/acpi_override.img /boot/initramfs-$(uname -r).img.bak > /boot/initramfs-$(uname -r).img'


After reboot you should find something like this in the logs (sudo dmesg | grep ACPI) : 

0.003219] ACPI: DSDT ACPI table found in initrd [kernel/firmware/acpi/dsdt.aml][0x1a965]

 

I hope it helps some one 😅.

And no HP, even if this helps this is not THE SOLUTION !!! Get the BIOS right ! 

 

 

HP Recommended

So this took me a while of tracking down to actually fix and like Berylius78 I took a DSDT method, but they were fixing the buffer issue.

I appear to have a different root cause on my unit, OMEN 16-ap0xxx (RTX 5060, Pop!_OS, kernel 6.18.7). The
WQBZ error has never fired here on any boot, so that was not my problem.

## The cause

The dGPU rail is an ACPI power resource called `PG00`, owned by the PCIe root port
`\_SB.PCI0.GPP0`. The firmware's own `PG00._OFF` works fine, it just never gets called at
shutdown. You cannot fix this from userspace: `pci_device_shutdown()` calls
`pm_runtime_resume()` unconditionally, so `device_shutdown()` powers the rail back up
before S5 regardless of what you release. But `_PTS(5)` runs *after* `device_shutdown()`,
and it calls `\_SB.PCI0.GPTS`, a graphics hook HP shipped with an empty body. That is the
one place left to put the call.

## Procedure

**1. Dump your own tables.** Do not use anyone else's compiled `.aml`, mine included, see
the warning at the bottom.

```sh
mkdir dsdt && cd dsdt
sudo acpidump -b # gives dsdt.dat plus ssdt*.dat
```

**2. Decompile, with the SSDTs available so externals resolve properly.**

```sh
iasl -e ssdt1.dat,ssdt2.dat,ssdt3.dat,ssdt4.dat,ssdt5.dat -d dsdt.dat
```

**3. Confirm your `GPTS` is actually empty**, and find your power resource path:

```sh
grep -n "Method (GPTS" dsdt.dsl
grep -rn "PowerResource (PG00" *.dsl # mine is in SSDT5
cat /sys/bus/pci/devices/0000:00:01.1/firmware_node/path # expect \_SB_.PCI0.GPP0
ls /sys/bus/pci/devices/0000:00:01.1/firmware_node/power_resources_D3hot/
```

If `GPTS` already has a body on your BIOS, stop, this patch would destroy it.

**4. Edit `dsdt.dsl`.** Add the external next to the other `External` lines at the top:

```asl
External (_SB_.PCI0.GPP0.PG00._OFF, MethodObj)
```

Then replace the empty `GPTS` method with:

```asl
Method (GPTS, 1, NotSerialized)
{
If ((Arg0 == 0x05))
{
\_SB.PCI0.GPP0.PG00._OFF ()
}
}
```

**5. Bump the OEM revision by one.** This is the step everyone misses, see the trap below.
Last field of the `DefinitionBlock` line, and change nothing else on that line:

```asl
-DefinitionBlock ("", "DSDT", 2, "HPQOEM", "8E35 ", 0x01072009)
+DefinitionBlock ("", "DSDT", 2, "HPQOEM", "8E35 ", 0x0107200A)
```

**6. Compile.** Expect warnings, they are normal. Errors are not.

```sh
iasl -tc dsdt.dsl # produces dsdt.aml
```

**7. Build the cpio, uncompressed.**

```sh
mkdir -p kernel/firmware/acpi
cp dsdt.aml kernel/firmware/acpi/
find kernel | cpio -H newc --create > acpi_override.cpio
```

**8. Prepend it to the initrd, keeping a pristine backup.** Adjust the path for your
distro (`/boot/initrd.img-$(uname -r)` on Debian/Ubuntu/Pop, `/boot/initramfs-$(uname -r).img`
on Fedora).

```sh
K=/boot/initrd.img-$(uname -r)

# only back up if there is no backup yet, otherwise you overwrite a clean
# backup with an already-patched initrd and end up prepending two cpios
[ -f "$K.orig" ] || sudo cp "$K" "$K.orig"

# confirm the backup is clean, this must print nothing
sudo sh -c "cpio -tv < $K.orig 2>/dev/null | grep firmware/acpi"

sudo sh -c "cat acpi_override.cpio $K.orig > $K"
```

**9. Sync to the ESP if your bootloader needs it.** On Pop!_OS:

```sh
sudo kernelstub
```

**10. Reboot and verify.** Reboot before you trust a poweroff, see the warning below.

```sh
sudo dmesg | grep -i 'Table Upgrade'
# ACPI: Table Upgrade: override [DSDT-HPQOEM-8E35 ]
ls -l /sys/firmware/acpi/tables/DSDT # must be your patched size, not the stock one
```

To revert at any point: `sudo cp $K.orig $K && sudo kernelstub`.


Things to be careful of: 

- Do not use someone else's compiled `dsdt.aml`. The kernel matches on OEM ID and table ID and accepts any greater revision, so a table built for one BIOS build loads silently on the same board running an older one, and you inherit that machine's EC offsets, thermal zones and GPIO numbers.
- A kernel update regenerates the initrd and silently drops all of this. Redo steps 8 to 10 after every upgrade.
HP Recommended

Haha ! We are all now some DSDT ACPI experts 😅 !

 

Good point @Furan917 , about the "DefinitionBlock",  i forgot to mention it ! 

 

 

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