Re: [REGRESSION] rtw88_8822bu: RTL8822BU unstable/disconnects on USB3 with newer kernels

[Bitterblue Smith <rtl8821cerfe2@gmail.com>]

On 03/11/2026 13:10, Tor-Arne Forsmo wrote:
> I've experienced new issues with a TP-Link Archer T4U. I've used this the past half a year without issues on a ubuntu server install, but recently I started experiencing disconnects on three different linux devices with two different Archer T4U (I bought a new one). The final fix was to revert back to a 6.18 kernel. I have never reported a bug before, I hope I'm writing to the correct e-mail addresses (I've gotten some help by AI). I've instructed ChatGPT to write a report of my findings, I hope this is helpful.
> 
> From ChatGPT:
> 
> 
> I believe I have encountered a regression affecting the rtw88_8822bu driver / RTL8822BU when operating over USB 3.0.
> 
> The problem is reproducible on a Raspberry Pi 4 with a TP-Link Archer T4U v3 (USB ID 2357:0115).
> 
> The important result is:
> 
>     6.12.62+rpt-rpi-v8  - GOOD
>     6.18.50+rpt-rpi-v8  - BAD
> 
> These are Raspberry Pi OS kernels rather than vanilla upstream kernels, so I have not established the exact upstream regression range.
> 
> Hardware:
> 
> -   Raspberry Pi 4
>     
> -   TP-Link Archer T4U v3
>     
> -   USB ID: 2357:0115
>     
> -   Realtek RTL8822BU
>     
> -   Driver: rtw88_8822bu / rtw88_usb
>     
> -   Raspberry Pi OS / Debian 13 (trixie)
>     
> -   Adapter connected directly to a USB 3.0 port
>     
> 
> With 6.18.50+rpt-rpi-v8, the adapter repeatedly disconnects and re-enumerates when used directly on USB 3.0. After reaching the SuperSpeed bus, it falls off USB again and this repeats approximately every few seconds.
> 
> I observed the device numbers continuously increasing as it re-enumerated. The pattern was essentially:
> 
>     rtw88_8822bu: Firmware version 30.20.0, H2C version 14
>     usb ...: USB disconnect
>     rtw88_8822bu: Firmware version 30.20.0, H2C version 14
>     usb ...: USB disconnect
>     ...
> 
> This continued for minutes.
> 
> There are also -EPROTO (-71) errors associated with the USB2 -> USB3 transition. I understand that a single -71 during this transition may be expected for this device/driver. The problem I am reporting is not that initial message itself, but the subsequent repeated disconnect/re-enumeration loop after the adapter has reached SuperSpeed.
> 
> The adapter works when limited to USB 2.0.
> 
> I then installed 6.12.62+rpt-rpi-v8 on exactly the same Raspberry Pi without otherwise changing the system.
> 
> With 6.12.62:
> 
>     $ uname -r
>     6.12.62+rpt-rpi-v8
>     
>     $ sudo modinfo rtw88_8822bu | grep -E 'filename|vermagic'
>     filename: /lib/modules/6.12.62+rpt-rpi-v8/kernel/drivers/net/wireless/realtek/rtw88/rtw88_8822bu.ko.xz
>     vermagic: 6.12.62+rpt-rpi-v8 SMP preempt mod_unload modversions aarch64
> 
> The same Archer T4U then enumerates successfully at SuperSpeed and remains there:
> 
>     $ lsusb
>     Bus 002 Device 005: ID 2357:0115 TP-Link Archer T4U ver.3
>     
>     $ lsusb -t
>     /:  Bus 002.Port 001: Dev 001, Class=root_hub, Driver=xhci_hcd/4p, 5000M
>         |__ Port 001: Dev 005, If 0, Class=Vendor Specific Class, Driver=rtw_8822bu, 5000M
>         |__ Port 002: Dev 006, If 0, Class=Mass Storage, Driver=uas, 5000M
> 
> The JMicron USB 3.0 disk dock shown above is simultaneously attached and operating at 5000M.
> 
> I then connected the Wi-Fi network through the Archer rather than merely leaving the interface idle:
> 
>     $ nmcli device
>     DEVICE  TYPE  STATE         CONNECTION
>     wlan1   wifi  connected     netplan-wlan0-Rasktnedikanten
>     wlan0   wifi  disconnected  --
>     
>     $ ip addr show wlan1
>     wlan1: <BROADCAST,MULTICAST,UP,LOWER_UP> ...
>         link/ether d8:44:89:03:3e:29
>         inet 192.168.10.71/24 ...
> 
> The Pi is therefore actually carrying its network connection over the Archer at USB 3.0 speed under 6.12.62, rather than the adapter simply surviving enumeration.
> 
> So far I have seen no USB errors or disconnects with 6.12.62.
> 
> For comparison, under 6.18.50 the same adapter, Pi and direct USB 3.0 connection entered the disconnect/re-enumeration loop within seconds.
> 
> I also have two physical Archer T4U v3 adapters. Both exhibited the direct-USB3 problem on the Pi with 6.18.50, so the Raspberry Pi result does not appear to be specific to one defective dongle.
> 
> There are some additional observations from x86 systems which may or may not be related:
> 
> -   One older Archer T4U v3 has worked reliably for a long period on an x86 Debian machine in the past.
>     
> -   The same older adapter works on another current x86 Linux machine over USB 3.0.
>     
> -   On a different x86 Kubuntu machine with a newer kernel, the older adapter failed during/after USB3 enumeration with rtw88 errors including -71 and -110, register access failures, "failed to read hw feature report", "failed to setup chip efuse info", and a USB SuperSpeed reset.
>     
> -   A newer physical Archer T4U v3 works on that particular x86 machine.
>     
> 
> Because of these additional results, there may also be some host/device sensitivity involved. However, the Raspberry Pi test is the controlled comparison I consider significant: same Pi, same adapter, same USB3 port, with 6.12.62 working and 6.18.50 failing very quickly.
> 
> On the bad Raspberry Pi kernel, the relevant modules were:
> 
>     kernel: 6.18.50+rpt-rpi-v8
>     
>     rtw88_8822bu:
>     srcversion: 594B4CB53E28BF8F6458E02
>     vermagic: 6.18.50+rpt-rpi-v8 SMP preempt mod_unload modversions aarch64
>     
>     rtw88_usb:
>     srcversion: C08071F92A5EA09279ABA16
>     vermagic: 6.18.50+rpt-rpi-v8 SMP preempt mod_unload modversions aarch64
> 
> For reference, two Ubuntu x86 kernels I checked used:
> 
>     rtw88_8822bu srcversion: C04D1014EBE0F8F11E65854
>     rtw88_usb    srcversion: B5E531378AC65924BDEA496
> 
> I have not bisected the regression or tested intermediate kernels. The Raspberry Pi is now being used as a working system, so I would prefer not to repeatedly change its kernel unless further testing is particularly important.
> 
> I can provide the complete dmesg from the failing 6.18.50 test if useful. It contains the repeated disconnect/re-enumeration sequence.
> 
> Please let me know if there is any other diagnostic information I can collect from the currently working 6.12.62 system without changing its kernel.
> 
> 
> 
> Best regards, Tor-Arne Forsmo

You could keep the 6.12.62 kernel and bisect only rtw88. It's not
too difficult to compile it out of tree.