[BUG] rtw89_8852bte: Recurring firmware crashes (LBC watchdog / SER) on RTL8852BE-VT despite ASPM and PS disabled

[BUG] rtw89_8852bte: Recurring firmware crashes (LBC watchdog / SER) on RTL8852BE-VT despite ASPM and PS disabled

[Josh Stevenson]

Hello,

I'm experiencing recurring firmware crashes on a Realtek RTL8852BE-VT
Wi-Fi adapter. The crashes happen every 30 minutes to several hours
during normal use, with 990 crash events logged in the current boot
(2 days 11 hours uptime). The firmware auto-recovers via SER (System
Error Recovery) each time, but connectivity drops briefly.

This is a known issue reported by multiple users (e.g., Arch Linux
forum post [1]), but I have not found an existing upstream bug report
with full diagnostic data.

[1] https://bbs.archlinux.org/viewtopic.php?id=290480

## Hardware

- Laptop: HP Laptop 15-fc0xxx (baseboard 8DC7)
- Wi-Fi: Realtek RTL8852BE-VT PCIe 802.11ax
  PCI ID: 10ec:b520 (subsystem 10ec:b520)
  Module: rtw89_8852bte (depends on rtw89_pci, rtw89_8852b)
- CPU: AMD Ryzen 7 7730U
- OS: Nobara 43 (based on Fedora 44)
- Kernel: 7.1.3-200.nobara.fc44.x86_64
- Firmware package: linux-firmware-20260622-1.fc44
- Firmware files: rtw8852b_fw.bin, rtw8852b_fw-1.bin, rtw8852b_fw-2.bin
  (dated 2026-06-22)

## Already-tried mitigations (no effect)

The following module parameters are set in /etc/modprobe.d/ and
confirmed active, but crashes persist:

  options rtw89_pci disable_clkreq=y disable_aspm_l1=y disable_aspm_l1ss=y
  options rtw89_core disable_ps_mode=y

NetworkManager Wi-Fi powersave is set to disable (value 2).
iw dev shows "Power save: off".

## Crash pattern

Crashes occur in bursts of 3 SER events:
  1. R_AX_LBC_WATCHDOG=0x00000081
  2. SER catches error: 0x1000 (L2 reset)
  3. SER catches error: 0x1001 (L1 reset)
  4. SER catches error: 0x1002 (firmware reset)

Each burst takes ~30ms. The firmware then auto-recovers and
NetworkManager reconnects within a few seconds.

Total crash events across 15 boots: 13,395+
Peak boot: 3,060 crashes in one session.

## Complete crash log (one representative event)

Jul 24 01:20:26 nobara-pc kernel: rtw89_8852bte 0000:01:00.0: R_AX_LBC_WATCHDOG=0x00000081
Jul 24 01:20:26 nobara-pc kernel: rtw89_8852bte 0000:01:00.0: <---
Jul 24 01:20:26 nobara-pc kernel: rtw89_8852bte 0000:01:00.0: SER catches error: 0x1000
Jul 24 01:20:26 nobara-pc kernel: rtw89_8852bte 0000:01:00.0: FW status = 0xa1001100
Jul 24 01:20:26 nobara-pc kernel: rtw89_8852bte 0000:01:00.0: FW BADADDR = 0x0
Jul 24 01:20:26 nobara-pc kernel: rtw89_8852bte 0000:01:00.0: FW EPC/RA = 0x0
Jul 24 01:20:26 nobara-pc kernel: rtw89_8852bte 0000:01:00.0: FW MISC = 0xb8900635
Jul 24 01:20:26 nobara-pc kernel: rtw89_8852bte 0000:01:00.0: R_AX_HALT_C2H = 0x1001
Jul 24 01:20:26 nobara-pc kernel: rtw89_8852bte 0000:01:00.0: R_AX_SER_DBG_INFO = 0x1000000
Jul 24 01:20:26 nobara-pc kernel: rtw89_8852bte 0000:01:00.0: [ERR]fw PC = 0xb898815b
Jul 24 01:20:26 nobara-pc kernel: rtw89_8852bte 0000:01:00.0: [ERR]fw PC = 0xb89880f3
Jul 24 01:20:26 nobara-pc kernel: rtw89_8852bte 0000:01:00.0: [ERR]fw PC = 0xb898815d
[... more fw PC entries ...]
Jul 24 01:20:26 nobara-pc kernel: rtw89_8852bte 0000:01:00.0: SER catches error: 0x1001
Jul 24 01:20:26 nobara-pc kernel: rtw89_8852bte 0000:01:00.0: FW status = 0xa1008100
Jul 24 01:20:26 nobara-pc kernel: rtw89_8852bte 0000:01:00.0: FW BADADDR = 0x0
Jul 24 01:20:26 nobara-pc kernel: rtw89_8852bte 0000:01:00.0: FW EPC/RA = 0x0
Jul 24 01:20:26 nobara-pc kernel: rtw89_8852bte 0000:01:00.0: FW MISC = 0xb8986657
Jul 24 01:20:26 nobara-pc kernel: rtw89_8852bte 0000:01:00.0: R_AX_HALT_C2H = 0x1002
Jul 24 01:20:26 nobara-pc kernel: rtw89_8852bte 0000:01:00.0: R_AX_SER_DBG_INFO = 0xf1000000
Jul 24 01:20:26 nobara-pc kernel: rtw89_8852bte 0000:01:00.0: [ERR]fw PC = 0xb89a1ea3
[... more fw PC entries ...]
Jul 24 01:20:26 nobara-pc kernel: rtw89_8852bte 0000:01:00.0: SER catches error: 0x1002

## Observations

1. The crash trigger is R_AX_LBC_WATCHDOG=0x00000081 — the LBC
   (LPS Boundary Check) watchdog fires, indicating the firmware
   stopped responding.

2. FW BADADDR varies: 0x0, 0x4444, 0xaaaa — suggesting different
   crash sites in the firmware.

3. FW EPC/RA is always 0x0.

4. The fw PC values cluster around 0xb898_xxxx and 0xb89a_xxxx,
   suggesting the firmware is crashing in the same code regions.

5. Disabling ASPM, clkreq, and power save mode does NOT prevent
   the crashes. This suggests the root cause is in the firmware
   itself, not in the driver's power management integration.

6. Auto-recovery via SER works reliably — the Wi-Fi reconnects
   every time. But the brief connectivity drops are disruptive.

## Questions

1. Is this a known firmware bug? Is there a newer firmware version
   available or in development?

2. Are there any driver-side workarounds to reduce LBC watchdog
   triggers (e.g., adjusting watchdog timeout, disabling LBC)?

3. Would a newer kernel version (e.g., mainline) have rtw89
   patches that address this?

4. Is there additional diagnostic data I can collect to help
   narrow down the root cause?

Thank you for your work on this driver.

Best regards,
Josh Stevenson

RE: [BUG] rtw89_8852bte: Recurring firmware crashes (LBC watchdog / SER) on RTL8852BE-VT despite ASPM and PS disabled

[Ping-Ke Shih]

Josh Stevenson <josh@recursiveintell.com> wrote:
> Hello,
> 
> I'm experiencing recurring firmware crashes on a Realtek RTL8852BE-VT
> Wi-Fi adapter. The crashes happen every 30 minutes to several hours
> during normal use, with 990 crash events logged in the current boot
> (2 days 11 hours uptime). The firmware auto-recovers via SER (System
> Error Recovery) each time, but connectivity drops briefly.

During the recovery, it can't TX/RX. But did you mean it disconnected from
AP? Please share full kernel log. 

> 
> This is a known issue reported by multiple users (e.g., Arch Linux
> forum post [1]), but I have not found an existing upstream bug report
> with full diagnostic data.
> 
> [1] https://bbs.archlinux.org/viewtopic.php?id=290480

The report was RTL8852BE instead. Let me ignore it.

> 
> ## Hardware
> 
> - Laptop: HP Laptop 15-fc0xxx (baseboard 8DC7)
> - Wi-Fi: Realtek RTL8852BE-VT PCIe 802.11ax
>   PCI ID: 10ec:b520 (subsystem 10ec:b520)

Confirmed this ID is RTL8852BE-VT. 

>   Module: rtw89_8852bte (depends on rtw89_pci, rtw89_8852b)
> - CPU: AMD Ryzen 7 7730U
> - OS: Nobara 43 (based on Fedora 44)
> - Kernel: 7.1.3-200.nobara.fc44.x86_64
> - Firmware package: linux-firmware-20260622-1.fc44
> - Firmware files: rtw8852b_fw.bin, rtw8852b_fw-1.bin, rtw8852b_fw-2.bin
>   (dated 2026-06-22)

The firmware for RTL8852BE-VT is rtw8852bt_fw*.bin

Please check the version you are using by kernel log, like:

rtw89_8852bte 0000:03:00.0: loaded firmware rtw89/rtw8852bt_fw-1.bin
rtw89_8852bte 0000:03:00.0: enabling device (0100 -> 0103)
rtw89_8852bte 0000:03:00.0: Firmware version 0.29.127.0 (f868aa18), cmd version 0, type 5
rtw89_8852bte 0000:03:00.0: Firmware version 0.29.127.0 (f868aa18), cmd version 0, type 3

(Attaching full log would be better to analyze)

> 
> ## Already-tried mitigations (no effect)
> 
> The following module parameters are set in /etc/modprobe.d/ and
> confirmed active, but crashes persist:
> 
>   options rtw89_pci disable_clkreq=y disable_aspm_l1=y disable_aspm_l1ss=y
>   options rtw89_core disable_ps_mode=y
> 
> NetworkManager Wi-Fi powersave is set to disable (value 2).
> iw dev shows "Power save: off".

I think you have done experiments I want to know.

> 
> ## Crash pattern
> 
> Crashes occur in bursts of 3 SER events:
>   1. R_AX_LBC_WATCHDOG=0x00000081
>   2. SER catches error: 0x1000 (L2 reset)
>   3. SER catches error: 0x1001 (L1 reset)
>   4. SER catches error: 0x1002 (firmware reset)
> 
> Each burst takes ~30ms. The firmware then auto-recovers and
> NetworkManager reconnects within a few seconds.
> 
> Total crash events across 15 boots: 13,395+
> Peak boot: 3,060 crashes in one session.
> 
> ## Complete crash log (one representative event)
> 
> Jul 24 01:20:26 nobara-pc kernel: rtw89_8852bte 0000:01:00.0: R_AX_LBC_WATCHDOG=0x00000081
> Jul 24 01:20:26 nobara-pc kernel: rtw89_8852bte 0000:01:00.0: <---
> Jul 24 01:20:26 nobara-pc kernel: rtw89_8852bte 0000:01:00.0: SER catches error: 0x1000
> Jul 24 01:20:26 nobara-pc kernel: rtw89_8852bte 0000:01:00.0: FW status = 0xa1001100
> Jul 24 01:20:26 nobara-pc kernel: rtw89_8852bte 0000:01:00.0: FW BADADDR = 0x0
> Jul 24 01:20:26 nobara-pc kernel: rtw89_8852bte 0000:01:00.0: FW EPC/RA = 0x0
> Jul 24 01:20:26 nobara-pc kernel: rtw89_8852bte 0000:01:00.0: FW MISC = 0xb8900635
> Jul 24 01:20:26 nobara-pc kernel: rtw89_8852bte 0000:01:00.0: R_AX_HALT_C2H = 0x1001
> Jul 24 01:20:26 nobara-pc kernel: rtw89_8852bte 0000:01:00.0: R_AX_SER_DBG_INFO = 0x1000000
> Jul 24 01:20:26 nobara-pc kernel: rtw89_8852bte 0000:01:00.0: [ERR]fw PC = 0xb898815b
> Jul 24 01:20:26 nobara-pc kernel: rtw89_8852bte 0000:01:00.0: [ERR]fw PC = 0xb89880f3
> Jul 24 01:20:26 nobara-pc kernel: rtw89_8852bte 0000:01:00.0: [ERR]fw PC = 0xb898815d
> [... more fw PC entries ...]
> Jul 24 01:20:26 nobara-pc kernel: rtw89_8852bte 0000:01:00.0: SER catches error: 0x1001
> Jul 24 01:20:26 nobara-pc kernel: rtw89_8852bte 0000:01:00.0: FW status = 0xa1008100
> Jul 24 01:20:26 nobara-pc kernel: rtw89_8852bte 0000:01:00.0: FW BADADDR = 0x0
> Jul 24 01:20:26 nobara-pc kernel: rtw89_8852bte 0000:01:00.0: FW EPC/RA = 0x0
> Jul 24 01:20:26 nobara-pc kernel: rtw89_8852bte 0000:01:00.0: FW MISC = 0xb8986657
> Jul 24 01:20:26 nobara-pc kernel: rtw89_8852bte 0000:01:00.0: R_AX_HALT_C2H = 0x1002
> Jul 24 01:20:26 nobara-pc kernel: rtw89_8852bte 0000:01:00.0: R_AX_SER_DBG_INFO = 0xf1000000
> Jul 24 01:20:26 nobara-pc kernel: rtw89_8852bte 0000:01:00.0: [ERR]fw PC = 0xb89a1ea3
> [... more fw PC entries ...]
> Jul 24 01:20:26 nobara-pc kernel: rtw89_8852bte 0000:01:00.0: SER catches error: 0x1002
> 
> ## Observations
> 
> 1. The crash trigger is R_AX_LBC_WATCHDOG=0x00000081 — the LBC
>    (LPS Boundary Check) watchdog fires, indicating the firmware
>    stopped responding.
> 
> 2. FW BADADDR varies: 0x0, 0x4444, 0xaaaa — suggesting different
>    crash sites in the firmware.
> 
> 3. FW EPC/RA is always 0x0.
> 
> 4. The fw PC values cluster around 0xb898_xxxx and 0xb89a_xxxx,
>    suggesting the firmware is crashing in the same code regions.
> 
> 5. Disabling ASPM, clkreq, and power save mode does NOT prevent
>    the crashes. This suggests the root cause is in the firmware
>    itself, not in the driver's power management integration.
> 
> 6. Auto-recovery via SER works reliably — the Wi-Fi reconnects
>    every time. But the brief connectivity drops are disruptive.
> 
> ## Questions
> 
> 1. Is this a known firmware bug? Is there a newer firmware version
>    available or in development?

Yes, but I'd report the issue you are encountering to internal experts.
Please share full kernel log (maybe via private mail if you don't want
to expose privacy)

> 
> 2. Are there any driver-side workarounds to reduce LBC watchdog
>    triggers (e.g., adjusting watchdog timeout, disabling LBC)?

I will leave the question to internal experts when I collect the log.

> 
> 3. Would a newer kernel version (e.g., mainline) have rtw89
>    patches that address this?

No patch related this obviously. 

> 
> 4. Is there additional diagnostic data I can collect to help
>    narrow down the root cause?

Collect the log with SER cases as many as you can, and share to me.

Ping-Ke