Public bug reported:
Hardware
Wi-Fi: Realtek RTL8852BE PCIe 802.11ax Wireless Network Controller (PCI ID
10ec:b852)
Subsystem: Lenovo Device [17aa:4853]
Driver/module: rtw89_8852be (uses rtw89_core, rtw89_pci)
System
Ubuntu 26.04.1 LTS (x86_64)
Kernel: 7.0.0-38-generic (7.0.0-38.38)
NetworkManager 1.54.3, systemd-resolved
Desktop: KDE Plasma 6.6.6, plasma-nm 4:6.6.6-0ubuntu0.1
Problem
On 5 GHz, the established link keeps reporting itself as healthy while the
data
path is actually dead. NetworkManager keeps the device in "activated" state
and
the system tray icon shows "connected", but TCP connections time out and pages
do not load. The only way to get the network back is to open the system tray
network applet - that immediately restores connectivity, because the applet
triggers a Wi-Fi scan / re-association that wakes the card and flushes the
frames that were stuck in the AP buffer.
Measured on the local gateway (1 hop, 192.168.1.1).
Decisive measurement - taken with the NetworkManager power save already
disabled and "iw dev wlp4s0 get power_save" reporting "off", i.e. with the
nl80211 power-save flag taken out of the picture:
active link: min 1.725 avg 2.302 max 3.940 ms, 0.00%
loss
same link after 60 s idle: min 1.735 avg 25.570 max 215.986 ms, 3.33%
loss
With the NM power save left at its default (3 = enable) the same condition
develops into the full-blown form of the problem:
idle link: avg 42.9 / 154.1 / 145.9 ms, max 382 / 917 / 1538 ms,
occasional packet loss
after a fresh re-association:
avg 2.8-4.0 ms, max 5.9-19.5 ms, 0% loss
A TCP connect to a remote host times out after 10 s while the icon says
"connected".
The stall therefore survives setting the NetworkManager-level power save off:
nmcli con mod <ssid> 802-11-wireless.powersave 2
nmcli con down <ssid> && nmcli con up <ssid>
# iw dev wlp4s0 get power_save -> Power save: off
so this is not the nl80211 PS flag - it is the driver's own PS mode below it.
Decisive measurement, taken with "iw dev wlp4s0 get power_save" reporting
"off" (NM power save disabled) so the nl80211 flag is out of the picture:
active link: avg 2.302 ms, max 3.940 ms, 0.00% loss
same link after 60 s idle: avg 25.570 ms, max 215.986 ms, 3.33% loss
With the NM power save left at its default (3 = enable) the condition
develops into the full-blown form:
idle link: avg 42.9 / 154.1 / 145.9 ms, max 382 / 917 / 1538 ms, with
occasional packet loss; a fresh re-association brings it back to
avg 2.8-4.0 ms, max 5.9-19.5 ms, 0% loss.
Relevant module parameters on the running system (all still at the "enabled"
/ "bad" defaults):
/sys/module/rtw89_core/parameters/disable_ps_mode = N
/sys/module/rtw89_pci/parameters/disable_aspm_l1 = N
/sys/module/rtw89_pci/parameters/disable_aspm_l1ss = N
/sys/module/rtw89_pci/parameters/disable_clkreq = N
/etc/NetworkManager/conf.d/default-wifi-powersave-on.conf: wifi.powersave
= 3
How to reproduce
1. Connect to a 5 GHz SSID (same SSID is served by 3 APs here, channels
36/44/48).
2. Leave the link idle for 30-60 s.
3. ping -c 30 -i 0.7 192.168.1.1
4. Observe the spikes and the occasional loss.
Alternative reproduction matching the user-visible symptom:
1. Connect to a 5 GHz SSID and start a transfer / browse.
2. Let the link sit idle for a while.
3. The tray icon still shows "connected" but nothing loads.
4. Click the system tray network applet -> the network comes back at once.
Expected results
Steady 1-3 ms to the gateway, no loss, no hundreds-of-milliseconds stalls, and
the link should not stop forwarding data while it is still associated.
Observed results
avg 42-154 ms, max 382-1538 ms with occasional loss (see above).
Workaround / mitigation
Passing the known rtw89 power-management parameters fixes the stalls:
# /etc/modprobe.d/rtw89-no-powersave.conf
options rtw89_core disable_ps_mode=y
options rtw89_pci disable_aspm_l1=y disable_aspm_l1ss=y disable_clkreq=y
followed by "update-initramfs -u" and a reboot. This matches LP #2145121.
Note that the mitigation had to be applied because the parameters default to
the power-hungry / stalling values above.
Related reports
LP #2145121 - "rtl8852be rtw89: 2.4GHz latency spikes/packet loss under load;
improved with disable_ps_mode + disable_clkreq/ASPM" (same NIC, same driver;
that report is about 2.4 GHz under load and is against 6.17, this one is about
5 GHz and about the link going completely dead while still associated).
Also see the ubuntu-studio-users thread "RTL8852BE Wi-Fi negotiates only
54 Mbps on Ubuntu Studio 26.04 (Kernel 7.0.0-27)", which reports the same
card on the same kernel cycle with the same set of workarounds.
Request
Could the rtw89 driver avoid stalling an already associated link, or should
disable_ps_mode default to Y for this chip? Even if the PS-mode code is
correct, the stall is severe enough that users cannot work around it without
opening a GUI applet.
Full diagnostics
See the attached full-info.txt (lspci/ethtool/modinfo, all rtw89 module
parameters, iw reg get, iw link, iw scan, nmcli state, NetworkManager journal,
and the latency measurements).
** Affects: linux (Ubuntu)
Importance: Undecided
Status: New
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/2172003
Title:
rtw89 (rtl8852be): link reports "connected" but is dead - gateway
latency spikes to 1.5s idle, recovers only when the Wi-Fi applet is
opened
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2172003/+subscriptions
--
ubuntu-bugs mailing list
[email protected]
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
