Full system freeze on boot with charger connected — ACPI BIOS Error (AE_AML_BUFFER_LIMIT) on HP Victus 15-fb3xxx
https://askubuntu.com/questions/1568308/full-system-freeze-on-boot-with-charger-connected-acpi-bios-error-ae-aml-buff
I have an HP Victus 15-fb3xxx (Ryzen 7 7445HS, RTX 3050 laptop, BIOS F.14) running Ubuntu 26.04 (kernel 7.0.0-27-generic). The system freezes completely (hard freeze, requires forced shutdown) consistently when booting with the charger connected, even without any heavy workload.
In journalctl -b -1 -p err from the boot right before the freeze, I consistently see this:
kernel: No irq handler for 1.55
kernel: No irq handler for 2.55
[...]
kernel: ACPI BIOS Error (bug): AE_AML_BUFFER_LIMIT, Index (0x000000032) is beyond end of object (length 0x32) (20251212/exoparg2-393)
kernel: ACPI Error: Aborting method \_SB.WMID.WQBZ due to previous error (AE_AML_BUFFER_LIMIT) (20251212/psparse-529)
kernel: ACPI Error: Aborting method \_SB.WMID.WQBE due to previous error (AE_AML_BUFFER_LIMIT) (20251212/psparse-529)
WQBZ/WQBE appear to be HP-proprietary WMI methods related to temperature/power-mode reporting (also queried by the NVIDIA driver via PlatformRequestHandler, which in a separate log reports failed to get target temp from SBIOS).
I've already ruled out the WiFi driver (RTL8852BE-VT, rtw89_8852bte module) as the cause of this specific freeze — it had a separate, unrelated power-save-mode bug that I already fixed with rtw89_core.disable_ps_mode=1 via GRUB, and it no longer shows up in recent logs.
Concrete questions:
- Has anyone with an HP laptop (Victus, Omen, or similar) seen this exact AE_AML_BUFFER_LIMIT error on the WQBZ/WQBE methods, and correlated it with freezes specifically when the charger is connected/detected?
- Is there a kernel parameter or a way to blacklist the hp_wmi module that mitigates this without losing critical functionality (fan control, function keys)?
- Has HP fixed this ACPI table bug in any BIOS version newer than F.14 for this laptop line?
Happy to attach a full acpidump if that helps diagnose it further.
Update (July 10):
Some important corrections and new findings since posting:
The charger is NOT the trigger. I initially correlated the freeze with the charger, but it also happens on battery, with no charger connected, after ~40 minutes of normal uptime. So the charger connection was a red herring — please disregard that part of the title.
NVIDIA D3 power-state failure found. On one freeze I caught this on screen: nvidia 0000:01:00.0: Unable to change power state from D3hot to D0, device inaccessible (plus the same for snd_hda_intel and an nvidia-modeset HDMI-0 pixel clock error). I mitigated it with nvidia.NVreg_DynamicPowerManagement=0x00 in GRUB (confirmed Runtime D3 status: Disabled), but the freeze still occurs, so this was a symptom, not the root cause.
The freeze leaves no trace in the local journal. journalctl -b -1 simply cuts off mid-activity with no error, oops, or panic — a silent hard hang. To capture it, I've set up netconsole / live journal streaming to a second machine over the network. Still waiting to catch a freeze with usable output.
The ACPI AE_AML_BUFFER_LIMIT errors on WQBZ/WQBE remain present in every boot regardless of the mitigations above.
Current GRUB cmdline: rtw89_core.disable_ps_mode=1 rtw89_pci.disable_aspm_l1=1 rtw89_pci.disable_aspm_l1ss=1 pcie_aspm=off nvidia.NVreg_DynamicPowerManagement=0x00
Will update again once I capture the hang over netconsole and/or after testing noapic and a BIOS update to F.15.
Update 2 (July 10, later):
Caught a hard freeze with actual output on screen this time (previously it was a silent hang with nothing in the local journal). The screen showed:
kernel: nvidia 0000:01:00.0: Unable to change power state from D3hot to D0, device inaccessible
kernel: snd_hda_intel 0000:01:00.1: Unable to change power state from D3hot to D0, device inaccessible
nvidia-modeset: ERROR: GPU:0: Failure reading maximum pixel clock value for display device HDMI-0.
kernel: BUG: unable to handle page fault for address: ffffcb14037700d0
So the D3hot→D0 resume failure I mentioned in Update 1 isn't just a cosmetic error — it culminates in a real kernel page fault (likely nvidia-modeset dereferencing an invalid pointer after the device dropped off the PCI bus), which is what causes the full hang.
Root cause of the gap: nvidia.NVreg_DynamicPowerManagement=0x00 (which I'd already set) only disables NVIDIA's own internal power management — it does NOT disable the kernel's generic PCI runtime power management, which is a separate control. Checking:
cat /sys/bus/pci/devices/0000:01:00.0/power/control
returned auto, meaning the kernel could still autosuspend the GPU independently of the NVIDIA driver setting.
Fix applied: forced it to on and made it persistent via udev:
echo on | sudo tee /sys/bus/pci/devices/0000:01:00.0/power/control
/etc/udev/rules.d/99-nvidia-no-pm.rules:
SUBSYSTEM=="pci", ATTR{vendor}=="0x10de", ATTR{power/control}="on"
Currently monitoring to see if this closes the gap. Also using netconsole/live journal streaming to a second machine to catch any future freeze with full context, since local journalctl doesn't survive a hang this violent.
Update 3 (July 11):
Progress and new findings:
The freeze produces a real kernel page fault. After disabling runtime PM at the PCI level (echo on > /sys/bus/pci/devices/0000:01:00.0/power/control, made persistent via udev rule + systemd service), the freeze still occurred, and I caught this on screen before the black-screen hang:
nvidia 0000:01:00.0: Unable to change power state from D3hot to D0, device inaccessible
snd_hda_intel 0000:01:00.1: Unable to change power state from D3hot to D0, device inaccessible
nvidia-modeset: ERROR: GPU:0: Failure reading maximum pixel clock value for display device HDMI-0.
BUG: unable to handle page fault for address: ffffcb14037700d0
So the failed D3hot->D0 transition leads to a kernel page fault. power/control was confirmed on at freeze time, so standard runtime PM wasn't the trigger — something else is still driving the GPU into D3.
Already in hybrid mode. prime-select query returns on-demand, so the hybrid configuration by itself does not prevent the freezes. HP Support has confirmed on their forums that Victus laptops aren't officially validated for Linux (GPU/audio/thermal only validated for Windows 11), consistent with the ACPI firmware bug being the root cause.
Currently testing noapic (boot logs show repeated No irq handler for X.55 messages, so interrupt routing via the broken ACPI tables seemed worth ruling out). Current cmdline:
rtw89_core.disable_ps_mode=1 rtw89_pci.disable_aspm_l1=1 rtw89_pci.disable_aspm_l1ss=1 pcie_aspm=off nvidia.NVreg_DynamicPowerManagement=0x00 noapic
Next isolated test, only if noapic proves insufficient, is fully disabling the dGPU via prime-select intel. The AE_AML_BUFFER_LIMIT / WQBZ/WQBE ACPI errors remain constant across every boot regardless of any mitigation.
Update (July 11) — root cause pinpointed in the ACPI method:
Captured the full AML failure via dmesg. The WQBZ method aborts on an off-by-one buffer access:
ACPI BIOS Error (bug): AE_AML_BUFFER_LIMIT, Index (0x32) is beyond end of object (length 0x32) (20251212/exoparg2-393)
Initialized Local Variables for Method [WQBZ]:
Local1: Integer 0x32
Local5: Integer 0x32
ACPI Error: Aborting method _SB.WMID.WQBZ due to previous error (AE_AML_BUFFER_LIMIT)
ACPI Error: Aborting method _SB.WMID.WQBE due to previous error (AE_AML_BUFFER_LIMIT)
hp_bioscfg: Returned error 0x3, "Invalid command value/Feature not supported"
The object length is 0x32 (50) and the method tries to index element 0x32 — one past the last valid index (0–49). A classic off-by-one in HP's AML bytecode. This is a firmware bug, not fixable via kernel parameters.
Things I've now ruled out as the freeze cause:
- WiFi driver (rtw89) — mitigated, no longer in logs.
- NVIDIA dGPU — freeze still happens with
prime-select intel (dGPU fully off, nvidia-smi reports no device).
- External mouse/keyboard — they enumerate cleanly (
Dell KB216, generic USB optical mouse), no i2c/usb errors tied to them.
noapic — tested and removed; it introduced new amd_gpio / atkbd / i2c_designware controller timed out errors without fixing the hang.- PCI runtime PM forced to
on — freeze persists regardless.
Also note amdgpu 0000:06:00.0: Runtime PM not available — even the integrated AMD GPU can't do runtime PM here, consistent with the ACPI power subsystem being broken at the firmware level.
Current plan: attempt a BIOS update to F.15 (via HP's USB flash mechanism if supported, to avoid needing Windows), since the root cause is in firmware. If HP hasn't fixed the WQBZ off-by-one in F.15, the fallback is an ACPI table override (acpidump + iasl) patching the method. Will report back.
Update (July 11) — WORKAROUND APPLIED (pending real-world confirmation):
Since HP doesn't provide a Linux BIOS update path for this model (and BIOS updates on Victus laptops have a documented brick risk), I patched the broken method directly via a DSDT override loaded from initrd. No firmware flashing, fully reversible.
Steps:
sudo acpidump -b and confirmed WQBZ lives in dsdt.dat.iasl -d dsdt.dat to decompile.- In the
WQBZ method, inserted an early Return (DerefOf (N012 [Arg0])) right after the local variable initialization, before the loops that overflow the buffer — effectively neutralizing the method (I don't need the HP WMI feature it feeds on Linux).
- Recompiled with
iasl -tc dsdt.dsl.
- Packed into a cpio at
kernel/firmware/acpi/dsdt.aml and loaded it via GRUB_EARLY_INITRD_LINUX_CUSTOM in /etc/default/grub.
Key gotcha: the first attempt didn't apply — the kernel found the table in initrd but kept using the original. The fix was incrementing the OEM Revision in the DefinitionBlock (from 0x01072009 to 0x01072010). The kernel silently ignores a DSDT override whose revision isn't higher than the firmware's. After bumping it, the override applied.
Result: dmesg | grep AE_AML_BUFFER_LIMIT is now empty. WQBZ/WQBE no longer abort. Confirmed the patch survives initramfs regeneration (e.g. after prime-select), since the cpio is prepended independently.
NVIDIA is back in on-demand mode with the patch active. Now testing under the conditions that previously triggered the freeze (4K video, charging, sleep/resume) to confirm this actually eliminates the hangs and not just the log error. Will report back after a few days of uptime.
Update (July 11) — additional trigger found + note on HP Linux support:
After the DSDT patch eliminated the WQBZ freeze, the system was stable for general use. However, I hit a separate, more specific hang: it froze once while playing HD video on the external HDMI monitor. Notably, journalctl -b -1 was completely clean afterwards (silent hard hang, no ACPI error, no D3hot trace) — so this is a different mechanism from the WQBZ firmware bug, which remains fixed (AE_AML_BUFFER_LIMIT stays absent).
Since the HDMI port on this Victus is wired to the NVIDIA dGPU, HD video decode + HDMI output stresses the NVIDIA path specifically. Disabling Chrome's hardware acceleration (chrome://settings/system -> turn off "Use graphics acceleration when available") appears to prevent it — several HD videos have played without a freeze so far. This forces video decode off the NVIDIA GPU. Still confirming with longer uptime.
I also disabled system suspend entirely (systemctl mask sleep.target suspend.target hibernate.target hybrid-sleep.target), because the NVIDIA D3hot->D0 resume failure would kill the external display on wake. On a hybrid NVIDIA laptop with this firmware, avoiding suspend proved more reliable than fighting the resume path.
Note for others considering this hardware on Linux: the root cause here is a firmware-level off-by-one in HP's own ACPI/WMI bytecode (WQBZ/WQBE), present verbatim across multiple HP models (another user confirmed the identical index on a Spectre X360). HP's official position is that Victus laptops are only validated for Windows, and there is no Linux BIOS update path — so fixing this requires decompiling and patching the DSDT by hand, which is out of reach for most users. The workarounds above make the machine fully usable on Linux, but it's worth being aware going in that this class of HP gaming laptop needs manual firmware-level intervention to run Linux reliably. Hopefully documenting the full fix here spares the next person the multi-hour debugging session.
