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.
Update (July 15) — CONFIRMED STABLE after 4 days of normal use:
Following the DSDT patch (WQBZ neutralized) plus the additional workarounds (suspend disabled, Chrome hardware acceleration off for HD video), the system has now been stable for 4 consecutive days of continuous real-world use — movies, series, work sessions, charger connected throughout. Zero freezes of any kind: not the original hard hang, not the D3hot/HDMI resume issue, not the video-decode hang.
Final working configuration for anyone hitting the same bug on similar HP hardware:
- DSDT override neutralizing the broken
WQBZ method (root cause: an off-by-one in HP's ACPI/WMI bytecode — index 0x32 on an object of length 0x32), loaded via GRUB_EARLY_INITRD_LINUX_CUSTOM in /etc/default/grub. Key detail: the kernel silently ignores the override unless the DSDT's OEM Revision is bumped higher than the original.
rtw89_core.disable_ps_mode=1 — a separate, unrelated WiFi power-save bug (RTL8852BE-VT).- System suspend disabled entirely (
systemctl mask sleep.target suspend.target hibernate.target hybrid-sleep.target) — avoids an NVIDIA D3hot->D0 resume failure that killed the external HDMI display on wake.
- Chrome hardware acceleration disabled (
chrome://settings/system) — avoids a separate hang tied to HD video decode over the NVIDIA-wired HDMI output.
Important caveat: none of this repairs the underlying hardware or firmware. The WiFi chip's power-save bug and HP's ACPI off-by-one are still physically present in the silicon/BIOS — these are stable, reproducible mitigations, not fixes at the source. Anyone reinstalling Ubuntu or moving to a different kernel will need to reapply all of the above.
Marking this resolved for my case. Hope the full trail here — including everything that didn't work along the way — saves the next person the multi-day debugging marathon.
Update (July 23) — extended stability confirmation + video-decode fix details:
Following up after more real-world use (movies, series, work, charging, ~10+ days total since the DSDT patch):
The WQBZ/ACPI freeze remains completely fixed. No recurrence of the original hard hang.
On the separate HD-video-freeze mentioned in my previous update: it also happened once in VLC (not just Chrome), with the same silent-hang signature (looping audio, no journal trace). Investigated further:
- Checked system-level VA-API first (
vainfo): it already defaults to the AMD iGPU (radeonsi), not NVIDIA. So the issue isn't a system-wide VA-API misconfiguration — each application can still independently choose to use the NVIDIA GPU for decode via its own internal logic (e.g. Chrome's own hardware decode path, VLC's own hwdec option), bypassing the system default.
- Fix: disabled hardware-accelerated decoding per-application — Chrome (
chrome://settings/system) and VLC (Preferences -> Input/Codecs -> Hardware-accelerated decoding -> Disable).
- Added
__NV_PRIME_RENDER_OFFLOAD=0 in /etc/environment as a system-wide fallback for any Prime-aware application.
Also worth noting: I hadn't tested VLC with audio routed through the external monitor before (audio was previously on laptop speakers) — the freeze happened specifically when I switched VLC's audio output to the HDMI monitor. Since the external HDMI on this Victus is wired to the NVIDIA GPU (both video and its HDMI audio controller, snd_hda_intel 0000:01:00.1), it's plausible the NVIDIA HDMI audio path is a contributing factor, not just video decode. Haven't isolated this separately yet (would require reverting the decode fix and testing audio-only), but with the decode fix in place, 5 full HD episodes over 2 days with monitor audio have played without issue.
Unrelated finding while investigating: the WiFi chip (RTL8852BE-VT) throws periodic firmware crash dumps (SER catches error, [ERR]fw PC = ...) independent of anything above — but the driver's built-in SER (System Error Recovery) mechanism recovers it automatically without affecting the rest of the system, confirmed by checking system activity in the following minutes (Docker, Slack, browser all logging normally). Not the cause of any freeze so far; flagging in case others see it and wonder if it's related.
Current full mitigation set:
- DSDT override neutralizing WQBZ (root cause, see previous update)
rtw89_core.disable_ps_mode=1 (WiFi power-save bug)- System suspend disabled
- Hardware-accelerated decoding disabled per-app (Chrome, VLC) +
__NV_PRIME_RENDER_OFFLOAD=0 system-wide
Machine has been fully usable for daily work, video, and development for over a week now.
