RTL8851BE: 5 GHz 80 MHz/HE beacon loss then auth timeout since 7.3

RTL8851BE: 5 GHz 80 MHz/HE beacon loss then auth timeout since 7.3

[Tan Hao]

Hi,

On RTL8851BE, 5 GHz 80 MHz/HE association succeeds, then the STA
loses beacons within about one second. After that, every 5 GHz
authentication times out until rtw89_8851be is unloaded. 2.4 GHz
and 5 GHz HT20/HT40 stay up. This started in 7.3.0; 7.2.11 is fine
with the same firmware file.

I am still bisecting. This is a report only, no patch yet.


Hardware
--------

  Laptop: Acer S16-41L (AMD Phoenix)
  PCI:    02:00.0 Network controller [0280]: Realtek RTL8851BE [10ec:b851]
  Driver: rtw89_8851be
  Chip:   CID 0, CV 1, AID 0, ACV 0, RFE 5
  FW:     rtw89/rtw8851b_fw-1.bin  0.29.41.5 (4bd6ebac)
  linux-firmware-realtek 20261019

  Both the working 7.2.11 kernel and the failing 7.3.x kernels load
  this same fw-1.bin (format 1). 6.18 LTS still requests the older
  rtw8851b_fw.bin; I have not used LTS as the primary comparison.

  Module parameters already set (do not avoid the failure):

    rtw89_core.disable_ps_mode=Y
    rtw89_pci.disable_aspm_l1=Y
    rtw89_pci.disable_aspm_l1ss=Y
    rtw89_pci.disable_clkreq=Y

  Regulatory: country CN, DFS-FCC. Channel 149 is allowed (33 dBm).
  SER L0/L1 counters stay 0; fw_crash is 0.


Kernels

  Good: 7.2.11 (CachyOS bore-lto, rtw89 from 7.2)
  Bad:  7.3.0 and 7.3.3 (CachyOS, rtw89 from 7.3)
  User-space: NetworkManager 1.58 + wpa_supplicant 2.12, nl80211


APs (same room, RSSI typically -30..-50 dBm)

  Dual-band SSID "GuWolf":
    5 GHz  BSSID 1e:40:e8:12:08:63  5745 MHz ch149  HE80  ~1170 Mbit  WPA2/WPA3 SAE
    2.4 GHz BSSID 1e:40:e8:12:08:62  2462 MHz ch11   HT40  WPA2/WPA3 SAE

  5 GHz-only SSID "UINT_MAX":
    BSSID 4e:69:b1:c6:62:64  5745 MHz ch149  HE80  WPA2-PSK

  On 7.2, UINT_MAX also worked on UNII-1 (5220/5240) and after a CSA
  to 5745 MHz / 80 MHz. So this is not limited to a single AP.


Reproducer

  1. Boot 7.3.x with the stock rtw89 driver (do not mask HE/VHT).
  2. Connect to either 5 GHz BSSID above (SAE or PSK, same result).
  3. Association completes; beacons are lost ~1s later.
  4. Re-auth to any 5 GHz AP times out. 2.4 GHz still works.
  5. Recovery: modprobe -r rtw89_8851be rtw89_8851b rtw89_pci rtw89_core
     && modprobe rtw89_8851be
     The next 5 GHz attempt can associate once, then the same loss
     repeats.


Logs (7.3.3, GuWolf 5 GHz, typical)

  wlan0: authenticate with 1e:40:e8:12:08:63
  wlan0: send auth to 1e:40:e8:12:08:63 (try 1/3)
  wlan0: authenticated
  wlan0: associate with 1e:40:e8:12:08:63
  wlan0: RX AssocResp from 1e:40:e8:12:08:63 (capab=0x11 status=0 aid=2)
  wlan0: associated

  wpa_supplicant:
    Associated with 1e:40:e8:12:08:63
    CTRL-EVENT-BEACON-LOSS
    CTRL-EVENT-DISCONNECTED bssid=1e:40:e8:12:08:63 reason=4 locally_generated=1

  Then:

  wlan0: send auth to 1e:40:e8:12:08:63 (try 1/3)
  wlan0: send auth to 1e:40:e8:12:08:63 (try 2/3)
  wlan0: send auth to 1e:40:e8:12:08:63 (try 3/3)
  wlan0: authentication with 1e:40:e8:12:08:63 timed out

  UINT_MAX (WPA2-PSK) is the same pattern; one run associated, then:

    CTRL-EVENT-BEACON-LOSS
    (no 4-way completion)

  After a module reload, UINT_MAX associated again and wpa_supplicant
  completed the 4-way, then lost beacons ~1s later in other runs.

  Scan still lists the 5 GHz BSS at full signal while auth TX fails,
  so 5 GHz RX of beacons during scan works; 5 GHz TX after the failed
  80 MHz session does not, until reload.


What does not fix it

  - disable_ps_mode / disable_aspm_l1 / disable_aspm_l1ss / disable_clkreq
  - NetworkManager wifi.powersave=2, scan-rand-mac-address=no
  - Raising mac80211.beacon_loss_count from 7 to 80: disconnect
    delayed from ~1s to ~9s, still zero beacons in that window
  - Reloading without actually resetting the 5 GHz PHY (just
    reconnect) is not enough once the first 80 MHz session has died


What does work on the same 7.3.3 kernel

  Forcing HT-only (wpa_supplicant disable_he=1 disable_vht=1), so the
  AP falls back to HT20/HT40 on 5745 MHz:

    wlan0: AP 4e:69:b1:c6:62:64 changed bandwidth in assoc response,
           new used config is 5745.000 MHz, width 1 (5745.000/0 MHz)
    WPA: Key negotiation completed
    iw: HT40 MCS 7, ~150 Mbit/s, beacon loss 0, DHCP OK

  Both SSIDs stay up this way. I am using that only as a local
  workaround, not as a proposed driver change.


Firmware elements on 7.3.3

  Firmware element BB version: 00 17 00 00
  Firmware element radio A version: 00 28 00 00
  Firmware element NCTL version: 00 0b 00 00
  Firmware element TXPWR version: 00 48 00 00
  Firmware element PWR_TRK version: 00 22 00 00
  Firmware element REGD version: 00 49 00 06


I can capture rtw89 debug_mask traces comparing a working HT40
session with a failing HE80 session, and I can test patches on this
RTL8851BE. Please tell me which debug bits you want.

Thanks,
Tan Hao

RE: RTL8851BE: 5 GHz 80 MHz/HE beacon loss then auth timeout since 7.3

[Ping-Ke Shih]

Tan Hao <guwolf@guwolf.com> wrote:
> Hi,
> 
> On RTL8851BE, 5 GHz 80 MHz/HE association succeeds, then the STA
> loses beacons within about one second. After that, every 5 GHz
> authentication times out until rtw89_8851be is unloaded. 2.4 GHz
> and 5 GHz HT20/HT40 stay up. This started in 7.3.0; 7.2.11 is fine
> with the same firmware file.

The changes between 7.3.0 and 7.2.11 related to RTL8851BE are mostly
BT-coexistence patches (if I read correctly), so you can quickly
check if it works well with BT disabled.

> 
> I am still bisecting. This is a report only, no patch yet.

Thanks. Please bisect the cause. 

> Reproducer
> 
>   1. Boot 7.3.x with the stock rtw89 driver (do not mask HE/VHT).
>   2. Connect to either 5 GHz BSSID above (SAE or PSK, same result).
>   3. Association completes; beacons are lost ~1s later.
>   4. Re-auth to any 5 GHz AP times out. 2.4 GHz still works.

For this point, BT might be not related because it works on 2.4GHz band, but
if it is not too hard, please try to disable BT.

>   5. Recovery: modprobe -r rtw89_8851be rtw89_8851b rtw89_pci rtw89_core
>      && modprobe rtw89_8851be
>      The next 5 GHz attempt can associate once, then the same loss
>      repeats.

This is a little weird to me. RTL8851BE becomes idle (power off) after
disconnection. It is very like reload modules. Not sure what they are
different?

> 
>   UINT_MAX (WPA2-PSK) is the same pattern; one run associated, then:

What does UINT_MAX mean?

> What does work on the same 7.3.3 kernel
> 
>   Forcing HT-only (wpa_supplicant disable_he=1 disable_vht=1), so the
>   AP falls back to HT20/HT40 on 5745 MHz:

Does it work if not disable_vht? (To clarify if RTL8851BE misbehavior
on bandwidth 80MHz.)

Re: RTL8851BE: 5 GHz 80 MHz/HE beacon loss then auth timeout since 7.3

[Hao Tan]

Hi Ping-Ke,

Thanks for the comments.

> The changes between 7.3.0 and 7.2.11 related to RTL8851BE are mostly
> BT-coexistence patches (if I read correctly), so you can quickly
> check if it works well with BT disabled.

This is a regression in v7.3. v7.2 is good and v7.3 is bad with the same
rtw8851b_fw-1.bin 0.29.41.5. I started from the v7.2 rtw89 driver and
applied the v7.3 rtw89 changes in order on one test kernel. The step that
changes the result is:

  86f763e37248 ("wifi: rtw89: coex: Rearrange _ntfy_role_info info") is good.

  a76501e1d148 ("wifi: rtw89: coex: Separate _ntfy_role_info into two function")
  is bad.

The rebuilt series differs from v7.3 by six files at the tail. Those
commits are after this step. Both endpoints were tested as unmodified
mainline, and the good/bad pair above differs by only a76501e1d148.

> if it is not too hard, please try to disable BT.

On unmodified v7.3, with the AP SSID "GuWolf" (BSSID 1e:40:e8:12:08:63):

  - Bluetooth controller powered off: VHT80 stayed up for 60 seconds,
    with no beacon loss. With the controller powered off,
    _set_wl_preagc_ctrl() already disables pre-AGC. pre_agc stayed 0
    for that run. The separate Bluetooth-on run reproduced the failure.
  - Bluetooth powered on: I used a temporary wpa_supplicant network and
    explicitly set disable_he=1 and disable_vht=0 before association.
    Both values remained set while it associated at VHT80; about three
    seconds later it disconnected with reason 4 (locally generated), and
    subsequent 5 GHz authentication timed out.

The beacon has HT and VHT IEs and no HE IE. VHT operation is 80 MHz
(channel 149, center 155). Forcing both disable_he=1 and disable_vht=1
falls back to HT20/HT40, which stays up.

> This is a little weird to me. RTL8851BE becomes idle (power off) after
> disconnection. It is very like reload modules. Not sure what they are
> different?

On unmodified v7.3 they are not the same. After the beacon loss I
disconnected and associated again without unloading the driver.
Association completed, but pre_agc was still 1, and beacons were lost
again after about one second. Reloading rtw89_8851be, rtw89_8851b,
rtw89_pci and rtw89_core clears that coex state and pre_agc returns to 0,
so one more association can complete before the same failure. RF idle
after disconnect does not clear it.

> What does UINT_MAX mean?

It is only the SSID of a second AP in the same room (BSSID
4e:69:b1:c6:62:64). It is 5 GHz only, WPA2-PSK, channel 149, and fails
the same way.

> Does it work if not disable_vht? (To clarify if RTL8851BE misbehavior
> on bandwidth 80MHz.)

No. With Bluetooth on, disable_he=1 and VHT still enabled, the VHT80
link still failed and disconnected with reason 4. See the second bullet
above.

a76501e1d148 also changes the role-notify flow, so I did not assume the
new STA value was the whole fix. This firmware uses role info v2
(fwlrole 2). Keeping the STA role and the new notify flow, but sending
link_mode_v0 in the role v2 H2C, still failed. Keeping the STA role, the
notify flow and the original H2C, and disabling pre-AGC when the link is
out of band, restored VHT80.

_set_wl_preagc_ctrl() disables pre-AGC when the TDD binding is 5 GHz, or
when the role is still NOLINK. Wi-Fi on 5 GHz and Bluetooth on 2.4 GHz
do not share a band, so tdd_bind is empty and out_of_band is already set.
After a76501e1d148 the NOLINK fallback no longer matches. The change is:

  } else if (dm->out_of_band ||
             dm->tdd_bind.rf_band == BIT(RTW89_BAND_5G)) {
          is_preagc = BTC_PREAGC_DISABLE;

Overlapping TDD/FDD bindings are unchanged. I have tested this only on
RTL8851BE with 5 GHz Wi-Fi and 2.4 GHz Bluetooth.

On v7.3 the change passed 600 seconds at VHT80 with no beacon loss, then
five reconnects without unloading the module. Six 50 MB downloads and
three 10 MB uploads completed. The same change on rtw-next
04c9984187228904f222681661c50db3f0c50b71 passed that VHT80 test and a
separate 2.4 GHz association and traffic test.

I am not claiming continuous Bluetooth HID or PAN coexistence. The
keyboard did not reconnect after a controller toggle, and the PAN test
saw a transient disconnect. I will follow up with the change as a
separate [PATCH] in this thread.

Hao Tan

[PATCH] wifi: rtw89: coex: Disable pre-AGC for out-of-band links

[Hao Tan]

When Wi-Fi and Bluetooth are on different RF bands, neither the TDD nor
the FDD binding has a band. _update_coex_bind() records that as
dm->out_of_band.

_set_wl_preagc_ctrl() disables pre-AGC when the TDD binding is 5 GHz, or
when the role is still NOLINK. After commit a76501e1d148 ("wifi: rtw89:
coex: Separate _ntfy_role_info into two function"), a 5 GHz-only STA is
no longer NOLINK. With Wi-Fi on 5 GHz and Bluetooth on 2.4 GHz, tdd_bind
is empty, so pre-AGC stays enabled. On RTL8851B this programs the
pre-AGC table, and a VHT80 link drops shortly after association.

Also disable pre-AGC when dm->out_of_band is set. Overlapping TDD and
FDD bindings are unchanged.

Tested on RTL8851BE (RFE 5, rtw8851b_fw-1.bin 0.29.41.5) with 5 GHz
Wi-Fi and 2.4 GHz Bluetooth. With this change, VHT80 stayed up for 600
seconds on v7.3 and on rtw-next 04c998418722. Without it, v7.3 drops the
link shortly after association.

Fixes: a76501e1d148 ("wifi: rtw89: coex: Separate _ntfy_role_info into two function")
Cc: stable@vger.kernel.org
Link: https://lore.kernel.org/linux-wireless/340ed206ff6a4680a46806e3bea5dbc5@realtek.com/
Signed-off-by: Hao Tan <guwolf@guwolf.com>
---
 drivers/net/wireless/realtek/rtw89/coex.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/net/wireless/realtek/rtw89/coex.c b/drivers/net/wireless/realtek/rtw89/coex.c
index 61e8b601c..411c1490b 100644
--- a/drivers/net/wireless/realtek/rtw89/coex.c
+++ b/drivers/net/wireless/realtek/rtw89/coex.c
@@ -6604,7 +6604,8 @@ static void _set_wl_preagc_ctrl(struct rtw89_dev *rtwdev)
 
 	if (!(bt->run_patch_code && bt->enable.now)) {
 		is_preagc = BTC_PREAGC_DISABLE;
-	} else if (dm->tdd_bind.rf_band == BIT(RTW89_BAND_5G)) {
+	} else if (dm->out_of_band ||
+		   dm->tdd_bind.rf_band == BIT(RTW89_BAND_5G)) {
 		is_preagc = BTC_PREAGC_DISABLE;
 	} else if (rinfo->link_mode[RTW89_MAC_0] == BTC_WLINK_NOLINK ||
 		 btc->cx.bt0.link_info.link_cnt.now == 0) {

base-commit: 04c9984187228904f222681661c50db3f0c50b71
-- 
2.56.0

RE: [PATCH] wifi: rtw89: coex: Disable pre-AGC for out-of-band links

[Ping-Ke Shih]

Hao Tan <guwolf@guwolf.com> wrote:
> When Wi-Fi and Bluetooth are on different RF bands, neither the TDD nor
> the FDD binding has a band. _update_coex_bind() records that as
> dm->out_of_band.
> 
> _set_wl_preagc_ctrl() disables pre-AGC when the TDD binding is 5 GHz, or
> when the role is still NOLINK. After commit a76501e1d148 ("wifi: rtw89:
> coex: Separate _ntfy_role_info into two function"), a 5 GHz-only STA is
> no longer NOLINK. With Wi-Fi on 5 GHz and Bluetooth on 2.4 GHz, tdd_bind
> is empty, so pre-AGC stays enabled. On RTL8851B this programs the
> pre-AGC table, and a VHT80 link drops shortly after association.
> 
> Also disable pre-AGC when dm->out_of_band is set. Overlapping TDD and
> FDD bindings are unchanged.
> 
> Tested on RTL8851BE (RFE 5, rtw8851b_fw-1.bin 0.29.41.5) with 5 GHz
> Wi-Fi and 2.4 GHz Bluetooth.

I'll keep above commit message, but remove below version info while
committing. 

> With this change, VHT80 stayed up for 600
> seconds on v7.3 and on rtw-next 04c998418722. Without it, v7.3 drops the
> link shortly after association.

> 
> Fixes: a76501e1d148 ("wifi: rtw89: coex: Separate _ntfy_role_info into two function")
> Cc: stable@vger.kernel.org
> Link: https://lore.kernel.org/linux-wireless/340ed206ff6a4680a46806e3bea5dbc5@realtek.com/
> Signed-off-by: Hao Tan <guwolf@guwolf.com>

I'll pick this to rtw branch for -rc cycle.

Acked-by: Ping-Ke Shih <pkshih@realtek.com>

RE: RTL8851BE: 5 GHz 80 MHz/HE beacon loss then auth timeout since 7.3

[Ping-Ke Shih]

Hao Tan <guwolf@guwolf.com> wrote:
>   86f763e37248 ("wifi: rtw89: coex: Rearrange _ntfy_role_info info") is good.
> 
>   a76501e1d148 ("wifi: rtw89: coex: Separate _ntfy_role_info into two function")
>   is bad.

Thanks for the bisect.

> _set_wl_preagc_ctrl() disables pre-AGC when the TDD binding is 5 GHz, or
> when the role is still NOLINK. Wi-Fi on 5 GHz and Bluetooth on 2.4 GHz
> do not share a band, so tdd_bind is empty and out_of_band is already set.
> After a76501e1d148 the NOLINK fallback no longer matches. The change is:
> 
>   } else if (dm->out_of_band ||
>              dm->tdd_bind.rf_band == BIT(RTW89_BAND_5G)) {
>           is_preagc = BTC_PREAGC_DISABLE;

I saw the patch. I'll consult internal experts to review the patch.

Ping-Ke