You are not logged in.
I am using a TN-725N usb wifi dongle provided by TP-link. Recently (maybe since 2-3 weeks ago) I've been experiencing an issue where the dongle fails to register as an interface when running ip link. The fix is to unplug the dongle and plug it in again, whereupon everything works as intended.
The dongle shows up in lsusb despite not appearing in ip link, so I think it's a driver issue relating to rtl8xxxu, maybe with some power management setting. I'm currently on the lts kernel, but I have tested it on the regular kernel with the same result. I have also tried a full system reinstall, but the issue persists.
I'm not very good with this sort of stuff, so if anyone could shed some light on what "rtl8xxxu error -11" is, or suggest a quick fix, that would be great.
I found this Github issue which encountered the same error. It seemed to be resolved by switching to the rtl8192cu driver, which I'm going to try next.
Here is the relevant dmesg log of the unwanted behavior upon boot:
[ 13.219689] usb 1-8: RTL8188EU rev D (TSMC) romver 0, 1T1R, TX queues 2, WiFi=1, BT=0, GPS=0, HI PA=0
[ 13.219693] usb 1-8: RTL8188EU MAC: 98:48:27:e7:69:de
[ 13.219695] usb 1-8: rtl8xxxu: Loading firmware rtlwifi/rtl8188eufw.bin
[ 13.257192] usb 1-8: Firmware revision 28.0 (signature 0x88e1)
[ 13.267492] usb 1-8: rtl8xxxu_writeN: Failed to write block at addr: 1280 size: 0080
[ 13.267707] rtl8xxxu: probe of 1-8:1.0 failed with error -11
[ 13.267741] usbcore: registered new interface driver rtl8xxxu
Here is the relevant dmesg after replugging the dongle
[ 2935.969342] usb 1-8: USB disconnect, device number 4
[ 2938.110061] usb 1-8: new high-speed USB device number 6 using xhci_hcd
[ 2938.317315] usb 1-8: New USB device found, idVendor=0bda, idProduct=8179, bcdDevice= 0.00
[ 2938.317324] usb 1-8: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[ 2938.317327] usb 1-8: Product: 802.11n NIC
[ 2938.317329] usb 1-8: Manufacturer: Realtek
[ 2938.317331] usb 1-8: SerialNumber: 00E04C0001
[ 2938.388131] usb 1-8: RTL8188EU rev D (TSMC) romver 0, 1T1R, TX queues 2, WiFi=1, BT=0, GPS=0, HI PA=0
[ 2938.388139] usb 1-8: RTL8188EU MAC: 98:48:27:e7:69:de
[ 2938.388143] usb 1-8: rtl8xxxu: Loading firmware rtlwifi/rtl8188eufw.bin
[ 2938.388311] usb 1-8: Firmware revision 28.0 (signature 0x88e1)
[ 2938.919556] rtl8xxxu 1-8:1.0 wlp1s0f0u8: renamed from wlan0
[ 3291.455631] wlp1s0f0u8: authenticate with 84:1b:5e:aa:37:59
[ 3291.457550] wlp1s0f0u8: send auth to 84:1b:5e:aa:37:59 (try 1/3)
[ 3291.459964] wlp1s0f0u8: authenticated
[ 3291.466661] wlp1s0f0u8: associate with 84:1b:5e:aa:37:59 (try 1/3)
[ 3291.473638] wlp1s0f0u8: RX AssocResp from 84:1b:5e:aa:37:59 (capab=0x411 status=0 aid=7)
[ 3291.474205] usb 1-8: rtl8xxxu_bss_info_changed: HT supported
[ 3291.474932] wlp1s0f0u8: associated
Last edited by pg_4919 (2024-07-14 12:23:35)
Offline
◉ errno 11
EAGAIN 11 Resource temporarily unavailable
The linked bug concerns intermittent connection losses, not an inability to talk to the device and alsoyou don't have an 8192cu chip, I'm not sure whether that driver can support an RTL8188EU
This is perhaps some race condition or "maybe with some power management setting", so the interesting part is what else is going on when the dongle tells you to come back later, please post your complete system journal for the boot:
sudo journalctl -b | curl -F 'file=@-' 0x0.st
Sanity check: is there a parallel windows installation?
Offline
I'm not sure if it's a negative sign, but the error code is outputted as -11, not 11.
Here's the full boot log http://0x0.st/XL9s.txt
No parallel windows installation
Offline
the error code is outputted as -11, not 11.
That's normal.
There's somehow a BT dongle(?) attached to an (external?) hub?
That seems to act up
Jul 13 18:09:09 peter-desktop kernel: usb 1-7.1: new full-speed USB device number 5 using xhci_hcd
Jul 13 18:09:09 peter-desktop kernel: usb 1-7.1: device descriptor read/64, error -32
Jul 13 18:09:09 peter-desktop kernel: usb 1-7.1: New USB device found, idVendor=0bda, idProduct=8771, bcdDevice= 2.00
Jul 13 18:09:09 peter-desktop kernel: usb 1-7.1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
Jul 13 18:09:09 peter-desktop kernel: usb 1-7.1: Product: Bluetooth Radio
Jul 13 18:09:09 peter-desktop kernel: usb 1-7.1: Manufacturer: Realtek
Jul 13 18:09:09 peter-desktop kernel: usb 1-7.1: SerialNumber: 00E04C239987
What if you remove that? Same issue around the wifi dongle?
Offline
Yes, removing the Bluetooth dongle resolves the issue
I have the BT dongle attached to a usb port on the front of my case, which is connected to the motherboard separately from the rear usb ports. I did this originally to prevent interference between the two, since sometimes my wifi would drop while playing audio. Funnily enough connecting the bluetooth dongle to the rear ports as well doesn't seem to cause the issue.
Is there any solution that allows the bluetooth dongle to be connected to the front?
Offline
Turns out that if I just move the bluetooth dongle to the other usb slot on the front everything works perfectly
Marking as solved
Offline
Hey, pg_4919.
"rtl8xxxu_writeN: Failed to write block at addr: 1280 size: 0080" <- This error happens when rtl8xxxu tries to upload the firmware which runs on the wifi chip's MCU. Realtek's official drivers try this upload up to five times. rtl8xxxu only tries once.
Would you like to test a patch for this? You can download the driver from here: https://github.com/a5a5aa555oo/rtl8xxxu After you compiled it, installed it, and confirmed that you still have the problem, apply this patch:
diff --git a/drivers/net/wireless/realtek/rtl8xxxu/core.c b/drivers/net/wireless/realtek/rtl8xxxu/core.c
index f855f8f8461c..a7488a9cd845 100644
--- a/drivers/net/wireless/realtek/rtl8xxxu/core.c
+++ b/drivers/net/wireless/realtek/rtl8xxxu/core.c
@@ -861,8 +861,8 @@ rtl8xxxu_writeN(struct rtl8xxxu_priv *priv, u16 addr, u8 *buf, u16 len)
write_error:
dev_info(&udev->dev,
- "%s: Failed to write block at addr: %04x size: %04x\n",
- __func__, addr, blocksize);
+ "%s: Failed to write block at addr: %04x size: %04x status %d\n",
+ __func__, addr, blocksize, ret);
return -EAGAIN;
}
@@ -4064,12 +4064,18 @@ static int rtl8xxxu_init_device(struct ieee80211_hw *hw)
*/
rtl8xxxu_write16(priv, REG_TRXFF_BNDY + 2, fops->trxff_boundary);
- ret = rtl8xxxu_download_firmware(priv);
- dev_dbg(dev, "%s: download_firmware %i\n", __func__, ret);
- if (ret)
- goto exit;
- ret = rtl8xxxu_start_firmware(priv);
- dev_dbg(dev, "%s: start_firmware %i\n", __func__, ret);
+ for (int i = 0; i < 5; i++) {
+ ret = rtl8xxxu_download_firmware(priv);
+ dev_dbg(dev, "%s: download_firmware %i\n", __func__, ret);
+ if (ret)
+ continue;
+
+ ret = rtl8xxxu_start_firmware(priv);
+ dev_dbg(dev, "%s: start_firmware %i\n", __func__, ret);
+ if (!ret)
+ break;
+ }
+
if (ret)
goto exit;
Compile it, install it, and try again.
I can send the patch upstream even if you don't test it, but it's better if I can say it fixed a real problem.
Offline
Hi, I tried applying the patch and it doesn’t seem to do anything, but I think it’s most likely an error on my part since I’ve never touched modules or built a driver before
I’d send the patch upstream regardless, I’ll keep trying to see if I can fix the issue
Offline
Are you running the driver from git? "lsmod | grep rtl8xxxu" should show "rtl8xxxu_git" instead of the plain "rtl8xxxu". Maybe you didn't blacklist the built-in rtl8xxxu.
Even if it doesn't fix the problem, you should see the error message five times instead of just once. Does that happen?
Last edited by cantabile (2024-10-01 09:52:56)
Offline