The 8812au shows in lsusb but not in nmtui or nmcli #261
Comments
|
Is this an issue with nmtui or the driver？ |
|
It looks like the driver did not load. Try |
There hasn't been any change. I run |
|
After you run |
|
Without rebooting. |
|
|
|
I have another 8812au network adapter that has reported different errors： |
|
full output: |
That explains it. Just out of curiosity, what are these devices called on their packaging? One other person reported this problem a while ago. (Or maybe it was you?) But I can't reproduce it. Please apply this patch and paste here the new output. Just the hex dump will do. diff --git a/drivers/net/wireless/realtek/rtw88/efuse.c b/drivers/net/wireless/realtek/rtw88/efuse.c
index b85075cd68d0..963712a57822 100644
--- a/efuse.c
+++ b/efuse.c
@@ -166,6 +166,10 @@ int rtw_parse_efuse_map(struct rtw_dev *rtwdev)
goto out_free;
}
+ pr_err("physical efuse map:\n");
+ print_hex_dump(KERN_INFO, "", DUMP_PREFIX_OFFSET, 16, 1,
+ phy_map, phy_size, true);
+
memset(log_map, 0xff, log_size);
ret = rtw_dump_logical_efuse_map(rtwdev, phy_map, log_map);
if (ret) { |
|
For the RFE 2 error: diff --git a/drivers/net/wireless/realtek/rtw88/rtw8812a.c b/drivers/net/wireless/realtek/rtw88/rtw8812a.c
index 2505bcd77f80..7cf335c3caed 100644
--- a/rtw8812a.c
+++ b/rtw8812a.c
@@ -1008,6 +1008,9 @@ static const struct rtw_rfe_def rtw8812a_rfe_defs[] = {
[1] = { .phy_pg_tbl = &rtw8812a_bb_pg_tbl,
.txpwr_lmt_tbl = &rtw8812a_txpwr_lmt_tbl,
.pwr_track_tbl = &rtw8812a_rtw_pwr_track_tbl, },
+ [2] = { .phy_pg_tbl = &rtw8812a_bb_pg_tbl,
+ .txpwr_lmt_tbl = &rtw8812a_txpwr_lmt_tbl,
+ .pwr_track_tbl = &rtw8812a_rtw_pwr_track_tbl, },
[3] = { .phy_pg_tbl = &rtw8812a_bb_pg_rfe3_tbl,
.txpwr_lmt_tbl = &rtw8812a_txpwr_lmt_tbl,
.pwr_track_tbl = &rtw8812a_rtw_pwr_track_rfe3_tbl, }, |
|
Not me，but I will try the patch |
|
The first one is inferior brand |
|
The second one was disassembled from Skyworth equipment |
This is called cin-fast 1200M |
|
Does this help with the efuse errors? diff --git a/drivers/net/wireless/realtek/rtw88/rtw8812a.c b/drivers/net/wireless/realtek/rtw88/rtw8812a.c
index 7cf335c3caed..880b5b94a48f 100644
--- a/rtw8812a.c
+++ b/rtw8812a.c
@@ -1050,7 +1050,7 @@ const struct rtw_chip_info rtw8812a_hw_spec = {
.rx_buf_desc_sz = 8,
.phy_efuse_size = 512,
.log_efuse_size = 512,
- .ptct_efuse_size = 96 + 1, /* TODO or just 18? */
+ .ptct_efuse_size = 0,
.txff_size = 131072,
.rxff_size = 16128,
.rsvd_drv_pg_num = 9, |
I have tried this on my Skyworth adapter，rf2 error was fixed，but still other errors： |
|
Does it work with another driver? |
|
Another adapter does not have an RFE2 error. It has efuse dump error. |
|
Does the Skyworth device work with another driver, like this one? |
|
Skyworth device can work with PixelPilot on android. They may use this driver https://github.com/OpenIPC/realtek-wlan |
|
Does this help with the power on error? diff --git a/drivers/net/wireless/realtek/rtw88/main.c b/drivers/net/wireless/realtek/rtw88/main.c
index 5e8baac2dfba..7674859f4635 100644
--- a/main.c
+++ b/main.c
@@ -1987,11 +1987,6 @@ static int rtw_chip_efuse_info_setup(struct rtw_dev *rtwdev)
mutex_lock(&rtwdev->mutex);
- /* power on mac to read efuse */
- ret = rtw_chip_efuse_enable(rtwdev);
- if (ret)
- goto out_unlock;
-
ret = rtw_parse_efuse_map(rtwdev);
if (ret)
goto out_disable;
@@ -2039,9 +2034,6 @@ static int rtw_chip_efuse_info_setup(struct rtw_dev *rtwdev)
}
out_disable:
- rtw_chip_efuse_disable(rtwdev);
-
-out_unlock:
mutex_unlock(&rtwdev->mutex);
return ret;
} |
|
I feel that these errors may be caused by a USB extension cable. Now I am tasting.All rtl adapters, including rtl8812bu with kernel driver, do not work with this USB extension cable, but MTK one can work, including mt7921 and mt7612. |
|
I tested three different USB extension cabless and found that rtl devices cannot be used on all |
|
@ss8688 Do all your usb cables support USB3? My 8822bu works fine with an USB2 extension cable. |
Someone has such a device: #261 Signed-off-by: Bitterblue Smith <[email protected]>
|
If it's the same with three different cables, the cables are probably good. But if you can plug the devices directly, try that. |
|
What a coincident I had bought a USB RTL8812AU USB WIFI to test out other series of REALTEK dongle. Issue 1I met the same situation as @ss8688 Settle Method 1I tried the same method you proposed: Result 1The USB dongle can control and show wlan0 and connect to nearest WIFI As for the USB 3.0 concernI am more a hardware guy, once I bought the dongle I had dissemble the housing
Do I encounter the issue REF 2aka rtw_8812au 1-1.3:1.0: rfe 2 isn't supported My log of the RTW as followsdmesgubuntu@briansune:~$ dmesg | grep rtw The connection latency is very poor and unstabledmesgPING 8.8.8.8 (8.8.8.8) 56(84) bytes of data. Additional issueSuddenly there is a message pop up on the terminal: [ 23.939271] efuse thermal meter is 0xff USB might require huge power > 500mAI also discover that if the USB is powering the system and also the USB dongle it will over the current limit of a standard USB 500mA. |
|
@briansune I'm glad that patch fixes the efuse error.
What device is this? It's not all RTL8812AU, others really are USB 3.
If you pulled today, that error is already fixed. I don't think RFE 2 is newer, just a different combination of PA and LNA. "RFE" is "RF front end".
The ping results should improve if you disable the power saving. I noticed this problem too, but I don't know what's wrong. The driver disables the power saving when there is a bit of traffic. ping just doesn't generate enough traffic. So when you're browsing or downloading something it's not going to be a problem.
Your device is probably missing some calibration info. If you use the debug_mask=0x20 module parameter we can see what else is missing in the efuse. Apparently when the chip gets hot, the TX power can degrade. The driver compensates for this, but only if it finds the thermal meter calibration info in the efuse. In your case that byte is 0xff (undefined). It will still work.
The official driver has some code to reduce the TX power in USB 2 mode to avoid drawing more than 500 mA. rtw88 doesn't have that code. |
|
As mentioned this is RTL8812AU USB dongle. So my dongle completely ignore all USB 3.0 possible hazard from first place. As for RFE this is ture from the board you can clearly see there are no extra AMP chip or components are placed in the upper part. Will try to use debug flag but after all RTW88 on USB, SDIO also show a poor performance compared to old RLT8732DS. Meantime it is also not a complete fixed when the a chip is blank w/o firmware and no recover system is embedded in the RTW88 driver (possibly I am wrong) |
|
BTW if you follow the hardware setup in this: If this is a RTL8812AU USB dongle then I am very sure that there is no chance this can work in super-speed. This also explained itself that why attaching a USB 3.0 A port to a USB 2.0 A port could work is because extra pins at the back is not connecting to any copper =] |
|
For the debug the efuse I guess you are referring to this modification: I also rebuilt the kernel with the debug flag turned on with 0x20. EFUSE[ 1.779725] DEBUG FOR - physical efuse map: [ 2.520544] usb 1-1: new high-speed USB device number 3 using dwc2 DMESG[ 19.034924] wlx488f4c90160a: authenticate with f8:6f:b0:0e:ae:e5 |
|
As for the power saving is triggering a poor ping result. I am showing iperf3 + ping concurrently running together with large packet setting. Ping Result + IPERF3ubuntu@briansune:~$ ping 192.168.1.1 -s 10000 |
|
Now the pings are high because of iperf3. :) Try to turn off power saving with
There is not much I can do about that because I don't have any SDIO devices. |
No I had tried all three situations all result is bad latency and unstable return. Of cause I haven't manually turn off the power save because it should automatically exit power save when large packet. A: Only ping large packet B: iperf3 only C: Both concurrently running When manually remove power save as you said indeed the latency is better a lot. ping 192.168.1.1 -s 10000 BTW the thermal is still reporting issue: [ 24.967555] efuse thermal meter is 0xff |
|
I got some unusage engineer board with RTL8723DS SDIO based WIFI do you need me to ship it to you? |
|
@briansune Sure, that could work. |
|
Lets doing of this line via EMAIL. |
|
Email me or share your Email address to follow up the shipping etc. |
|
@briansune Yes, I will email you today. |
Note that wlan0 is the onboard WiFi of Raspberry Pi, not RTL8812
The text was updated successfully, but these errors were encountered: