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

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

[Tor-Arne Forsmo]

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

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

[Bitterblue Smith]

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.