A working setup recipe for laptops with Intel Meteor Lake CPUs and Intel Wi-Fi 7 BE200, after losing significant time to two well-known but interlinked kernel bugs. Written 2026-05-05 from a Manjaro install but the workarounds are distro-agnostic — only the package/file paths differ.
If you have:
- An Intel Meteor Lake laptop (e.g. ThinkPad with Intel Core Ultra 1xxH/U)
- Intel Wi-Fi 7 BE200 (PCI vendor 8086, common at
09:00.0,wlpXs0f0) - Linux kernel 6.11 through 7.0
- Symptoms: ~30s system freezes (
iwlwifi: Queue X is stuck,iwlwifi: NMI_INTERRUPT_UNKNOWN, soft lockups), and/or hangs on resume from suspend (i915 errors in dmesg)
…then a working stable configuration is:
- Run kernel 6.12 LTS (avoid 6.18, 6.19, 7.0 — all have unfixed GPU resume bugs, and 7.0 introduced a new flavor of the same bug).
- Disable ASPM at the PCI level for the BE200 endpoint and its
upstream bridge via
setpciin a systemd service. Kernel cmdlinepcie_aspm=offalone is not enough — firmware keeps L1 active. - Set iwlwifi module options:
power_save=0 disable_11be=1, plusiwlmld power_scheme=1. Effectively runs as Wi-Fi 6E.
Full details below.
- CPU: Intel Meteor Lake (Core Ultra series)
- WiFi: Intel Wi-Fi 7 BE200 (802.11be), firmware
gl-c0-fm-c0-101.ucode(firmware API 101 has known issues) - GPU: integrated Meteor Lake (i915 driver, PCI
00:02.0)
- 30-second system-wide hangs, UI nonresponsive, trackpad clicks ignored
dmesg/ journal:iwlwifi 0000:09:00.0: Queue 2 is stuckiwlwifi 0000:09:00.0: NMI_INTERRUPT_UNKNOWNwatchdog: BUG: soft lockup - CPU#X stuck for 22-23s
- The driver holds a spinlock during firmware crash, blocking all network I/O and any process touching the network stack. With WiFi as default route, the desktop is effectively frozen.
ASPM L1 + L1 substates active on the BE200 link cause the device to
transition to deep low-power states from which the firmware does not
reliably wake under load. The disable_11be=1 workaround additionally
avoids unstable WiFi 7 codepaths in the current iwlwifi/iwlmld stack.
/etc/modprobe.d/iwlwifi.conf:
options iwlwifi power_save=0 disable_11be=1
options iwlmld power_scheme=1
Then rebuild initramfs (Manjaro/Arch: sudo mkinitcpio -P; Debian/Ubuntu:
sudo update-initramfs -u; Fedora: sudo dracut -f).
pcie_aspm=off on the kernel cmdline is insufficient — on this
hardware the ACPI _OSC handshake does not grant the OS control of ASPM,
so firmware re-enables L1 after the driver loads.
The reliable fix is to clear ASPM at the PCI config level for both the endpoint and its upstream bridge, as a systemd service that runs early.
/etc/systemd/system/disable-be200-aspm.service:
[Unit]
Description=Disable ASPM on BE200 WiFi to prevent queue-stuck lockups
After=systemd-modules-load.service
Before=NetworkManager.service
[Service]
Type=oneshot
RemainAfterExit=yes
ExecStart=/usr/bin/setpci -s 09:00.0 CAP_EXP+10.w=0140
ExecStart=/usr/bin/setpci -s 00:1c.7 CAP_EXP+10.w=0c40
ExecStart=/usr/bin/setpci -s 09:00.0 0x198.l=40780000
ExecStart=/usr/bin/setpci -s 00:1c.7 0x208.l=40783c10
[Install]
WantedBy=multi-user.targetAdjust PCI addresses if yours differ (lspci | grep -i wireless for the
endpoint; lspci -t to find its upstream bridge).
The four writes:
- Clear ASPM L1 bit (LnkCtl) on endpoint and bridge
- Clear all L1 substates (PCI-PM L1.1/L1.2, ASPM L1.1/L1.2) on both
Enable: sudo systemctl enable --now disable-be200-aspm.service.
lspci -s 09:00.0 -vvv | grep -iE "aspm|l1 sub"
lspci -s 00:1c.7 -vvv | grep -iE "aspm|l1 sub"Both devices should show ASPM Disabled and all L1 substates -.
iwlwifi msix=0— silently ignored, parameter does not existsetpciagainst MSI-X register at probe time viamodprobe installhook — driver re-enables MSI-X during probe, overrides PCI writenapi_threaded=0— iwlmld doesn't expose this parameterpci=nomsixkernel parameter — kernel reports "Unknown option"; parameter does not existpcie_aspm=offkernel parameter alone — kernel logs "PCIe ASPM is disabled" but ACPI _OSC denies OS control; firmware keeps L1 active
System hangs shortly after resume from s2idle suspend. From the user's perspective the laptop "doesn't wake" — screen stays black or frozen, though the kernel itself has resumed (sshd works, network reconnects).
dmesg evidence varies by kernel version:
On 6.18–6.19 (GuC TLB invalidation flavor):
i915 0000:00:02.0: [drm] *ERROR* GT0: GUC: TLB invalidation response
timed out for seqno NNNN
On 7.0 (DPLL state mismatch flavor — observed 2026-05-05 on 7.0.3):
i915 0000:00:02.0: [drm] *ERROR* [CRTC:149:pipe A] mismatch in
hw.pipe_mode.crtc_clock (expected 572010, found 65082)
i915 0000:00:02.0: [drm] *ERROR* mismatch in port_clock
(expected 540000, found 61440)
i915 0000:00:02.0: [drm] DPLL 0: pll hw state mismatch
WARNING ... intel_modeset_verify_crtc+0x347/0x550 [i915]
i915 0000:00:02.0: [drm] *ERROR* [CRTC:149:pipe A] flip_done timed out
The 7.0 symptom is a new variant — same root issue (Intel display does
not reliably restore state after s2idle on Meteor Lake), different
failure point. The DPLL frequency mismatch suggests the display PLLs
come back at the wrong frequency on resume, after which kwin's atomic
commit deadlocks waiting for flip_done.
- Last known-good: 6.8
- Broken: 6.11 through 7.0+
- Workable: 6.12 LTS — the bug exists but triggers far less often in practice. One controlled suspend test on 6.12.85 (38s s2idle cycle) resumed cleanly with no i915 errors.
In rough order of bang-for-buck:
-
Use kernel 6.12 LTS. The bug class is present but rarely fires. This is what the Linux community recommends for Meteor Lake.
-
Add
i915.enable_guc=0to the kernel cmdline. Disables GuC submission, sidesteps the TLB-invalidation flavor of the bug. Trade-off: also disables HuC (hardware-assisted decode for some video codecs); software decode still works. -
Switch to the
xedriver (Intel's newer DRM driver). Mixed reports on stability. Requires blacklisting i915 — having both modules loaded is not enough; i915 will still bind to the device. -
Wait. Intel has patches in the
linux-intel-ltstree but nothing comprehensive has merged upstream as of 2026-05-05.
On every resume cycle (regardless of kernel), this benign error appears:
spd5118 18-0050: Failed to write b = 0: -6
spd5118 18-0050: PM: dpm_run_callback(): spd5118_resume returns -6
spd5118 18-0050: PM: failed to resume async: error -6
The DDR5 SPD/temperature sensor's resume callback fails with ENXIO, likely because i2c isn't fully ready when the async callback runs. It's async and non-fatal; the system proceeds. Cosmetic.
- i915 Meteor Lake GPU hang: https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/10798
- BE200 / iwlwifi WiFi 7 issues:
- Arch Forums: https://bbs.archlinux.org/viewtopic.php?id=306935
- Intel Community: https://community.intel.com/t5/Wireless/Intel-Wi-Fi-7-BE200-320MHz-kernel-warning-and-system-freeze/td-p/1703035
- AX210 (related, predates BE200): https://community.intel.com/t5/Wireless/AX210-System-Crash-after-iwlwifi-Queue-Stuck-Error-Issue/m-p/1562147
- CachyOS regression tracking (firmware API 101 broken on 6.18+): CachyOS/linux-cachyos#673
- Distro-side bug reports for the GPU resume hang:
None of this is distro-specific — both bugs live in the upstream Linux kernel and reproduce identically on Fedora, Ubuntu, Arch, Manjaro, Debian, etc. Distros differ only in how quickly they push you onto a broken kernel: rolling distros (Manjaro, Arch, Fedora) hit 7.0-class issues months before stable distros (Debian, Ubuntu LTS) do.
If your distro auto-tracks "stable" kernels via a meta-package (Manjaro
has linux-meta, Ubuntu has HWE rollups), consider removing/pinning it
so a future kernel jump doesn't silently put you on a broken version.
This recipe gives you a stable system but it doesn't fix the underlying bugs. Premium Meteor Lake hardware on Linux remains in a "works once you fight it into submission" state as of mid-2026.