WLAN0 had shown but network is down

[briansune]

wlan0: flags=4098<BROADCAST,MULTICAST> mtu 1500 ether ff:ff:ff:ff:ff:ff txqueuelen 1000 (Ethernet) RX packets 0 bytes 0 (0.0 B) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 0 bytes 0 (0.0 B) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0

wlan0 Interface doesn't support scanning : Network is down

sit0 Interface doesn't support scanning.

lo Interface doesn't support scanning.

Had tried nmcli radio wifi on and restart service.

Module Size Used by rtw_8723ds 16384 0 rtw_8723d 45056 1 rtw_8723ds rtw_sdio 20480 1 rtw_8723ds rtw_core 151552 2 rtw_sdio,rtw_8723d

[briansune]

@lwfinger

BTW, the guy that wrote the kernel's rtw8723ds could not envision that there would be models in the wild with empty EFUSEs. I still cannot believe that vendors would do this!

I want to correct such idea. This is incorrect, even the EFUSE is preprogrammed from first place EFUSE could be corrupted and once this corruption exist the EFUSE must be self correct or reloaded with a basic fit on most country or TX RX requirements. This is why the original RTL8723DS have such feature. EFUSE correction and check both need to be exist otherwise the driver itself is considered as incomplete from first place.

Even a EFUSE check is done before IC shipping static charge, IC defect that could not detect before shipping is all the case and there is no 100% sure but just a concept of yield. And both hardware and software team need to take into account such case. EFUSE is just a memory could be PROM or EEPROM.

Correct me if it is not the case.

We are appreciated with such driver but a EFUSE self-correct or preload feature is what the missing puzzle here. To be sure I am also going to verify the RTW88 on the same batch of new boards. But RTL8723DS old driver had work on so many test gear and it is stable enough for our case.

But @RadxaYuntian may not, so if any hardware cross-check is needed I am happy to help out. =]

[briansune]

@RadxaYuntian

I had an info got to update is that the board I dump my EFUSE is an new one and different that this post original open. I do tried to cross-compile the RTW88 original driver. Without your modification this board can load the driver but the TX RX is so unstable and very easy to lost connection.

RTW 88 vs OLD RTL8723DS

@lwfinger Do you have encountered such situation? This chip do have preloaded EFUSE.

[lwfinger]

I have no personal exterience with any SDIO chips, but the autfor of rtw8723ds.c in the rtw88 repo must have. I will contact him to see if I can get his dump.

I forgot to mention this before, but one of the things that gets added to the EFUSE by the factory are the optimum power settings for THAT chip. Without that information, it will be difficult to get proper performance.

[briansune]

@lwfinger

Optimum TX LUT is what you are referring to. RX have no power LUT but only filter table or IF settings. And the EFUSE situation still unable to explain why a fused chip work poorly on RTW88. If this is blank IC original RTW88 should result same as the very beginning of the post but one of the board chip is not (could be reused or new old stock). There are no point to fuse a chip but using wrong settings when the chip is new.

[RadxaYuntian]

BTW, the guy that wrote the kernel's rtw8723ds could not envision that there would be models in the wild with empty EFUSEs. I still cannot believe that vendors would do this!!

For us it is a little bit different. We are only a single board manufacturer, and there are customers who uses our products to integrate into their own solution. So we generally don't touch eFuse since the customer might want to make adjustment to it.

The vendor rtl8723ds driver could generate random MAC when eFuse one is invalid, and that is preferred compared to a manual module parameter.

Without your modification this board can load the driver but the TX RX is so unstable and very easy to lost connection.

This could well due to some eFuse values are not defined. In the vendor driver as I mentioned above, it will perform runtime check for most eFuse config value, and dynamically adjust them if some is detected to be invalid. Such functionality is missing in RTW88, which requires all parameters stored in the eFuse must be valid.

You could dump your new eFuse content, and compared with the working one you posted above.

[briansune]

@RadxaYuntian

I am very confused: Q) What you trying to do here? Update the RTW88 driver missing feature? Q) So do the only board that your side manufacture have issue or not on RTW88 driver instead of the MAC? E) As I had already mention custom board design without WIFI module would highly requires a EFUSE preload feature. This had explained above clearly. And RTW88 driver runs with a preload EFUSE IC (not your modified RTW88) and the EFUSE is not programmed by our side only preform badly on the same DUT we trying to compare with.

Q) So do RTW88 involve runtime check? Q) Even it is undergo a runtime check, do RTW88 involve a read and write back runtime process? (this also had mentioned as ask many time on above) E) The same board as RTL8723DS IC and with preloaded EFUSE that are not EFUSE programmed by our side on two driver shows a different behavior. If vendor driver adjust it at runtime then no matter the default EFUSE is RTL8732DS old driver will recover a better EFUSE for operation. Q) So original vendor driver already have enough info to enables the fix of RTW88. Q) How can I dump the EFUSE content when the IC itself is already contains non-empty EFUSE and runtime fixed by RTL8732DS vendor driver? (No guidelines are shown or given)

E) the above dump is undergo on the latest board and only the same board. The only info is misaligned is the chip EFUSE is not purely blank.

[RadxaYuntian]

Q) What you trying to do here? Update the RTW88 driver missing feature?

Make RTW88 working on our 8723DS based product, that doesn't have eFuse programmed, and was working on RTL8723DS (a.k.a vendor driver).

Q) So do the only board that your side manufacture have issue or not on RTW88 driver instead of the MAC?

MAC address missing is due to un-programmed eFuse, which RTW88 currently cannot handle correctly.

Q) So do RTW88 involve runtime check?

It currently does not, which is why I keep comparing back to vendor driver which does have runtime check of eFuse contents.

Q) Even it is undergo a runtime check, do RTW88 involve a read and write back runtime process? (this also had mentioned as ask many time on above)

There is no write back on RTW88 or vendor driver, since eFuse is program once only. You do not want drive to write it without your permission.

E) The same board as RTL8723DS IC and with preloaded EFUSE that are not EFUSE programmed by our side on two driver shows a different behavior. If vendor driver adjust it at runtime then no matter the default EFUSE is RTL8732DS old driver will recover a better EFUSE for operation.

This is basically correct.

Q) So original vendor driver already have enough info to enables the fix of RTW88.

In theory yes, as shown by device working with vendor driver under the same condition. However, the current attempt to add eFuse validation and fall back failed to achieve the same result on my board. This means either my code is wrong, or there are some other parts where the driver handles the hardware differently. Prefilling eFuse value is a low hanging fruit that I can handle, comparing the behavior is not.

Q) How can I dump the EFUSE content when the IC itself is already contains non-empty EFUSE and runtime fixed by RTL8732DS vendor driver? (No guidelines are shown or given)

You dumped it here. As explained here this is the raw eFuse.

[briansune]

@RadxaYuntian

Q) So what do you need? E=Explain) In this post very beginning, the board is equipped with a non-fused EFUSE IC, which should result in the same situation as yours. Q) You had pointed out the function but could you elaborate a bit more how to add it or use it to make the compile prints out the dump? (I have limited software background on driver and kernel etc)

[RadxaYuntian]

Q) So what do you need? E=Explain) In this post very beginning, the board is equipped with a non-fused EFUSE IC, which should result in the same situation as yours.

I'd like to see the dump of this device. It should match my eFuse, as my hypothesis back then was:

So I think the issue is in the other fields where Brian's eFuse has a different value than the defaults I included from

So if we both have basically the same eFuse, then I think it will be worth to pick some defaults from your first eFuse dump that was pre-programmed with some working value.

Q) You had pointed out the function but could you elaborate a bit more how to add it or use it to make the compile prints out the dump? (I have limited software background on driver and kernel etc)

It's the same method you described here.

[briansune]

@RadxaYuntian

I'd like to see the dump of https://github.com/lwfinger/rtw88/issues/157#issuecomment-1805947004. It should match https://github.com/lwfinger/rtw88/issues/157#issuecomment-1805026898, as my hypothesis back then was:

This device is the new board I am mentioning, which works without your modification of RTW88. The dump is https://github.com/lwfinger/rtw88/issues/157#issuecomment-1801866371 via the RTL8723DS vendor driver.

Q) Or you would like the old board dump that is not working with the default RTW88 driver?

[dubhater]

For the ping problem, did y'all try to disable the power saving? iw wlan0 set power_save off

[RadxaYuntian]

Q) Or you would like the old board dump that is not working with the default RTW88 driver?

Yes I want the dump for this one. Thanks.

[briansune]

@dubhater

Cannot see huge different on such command. This is a pure new board and received from SMT. Driver is used RTW88 original

iw wlan0 set power_save off

@RadxaYuntian

Here is the dump on this new board:

log

``` RTW: HW EFUSE RTW: 0x000: 29 81 00 7C E1 88 07 00 A0 04 EC 35 12 C0 A2 D8 RTW: 0x010: 26 25 24 24 24 24 29 28 27 27 27 02 FF FF FF FF RTW: 0x020: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF RTW: 0x030: FF FF FF FF FF FF FF FF FF FF 22 22 22 22 22 22 RTW: 0x040: 21 21 21 21 21 02 FF FF FF FF FF FF FF FF FF FF RTW: 0x050: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF RTW: 0x060: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF RTW: 0x070: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF RTW: 0x080: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF RTW: 0x090: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF RTW: 0x0a0: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF RTW: 0x0b0: FF FF FF FF FF FF FF FF 20 25 20 00 00 00 FF FF RTW: 0x0c0: FF 29 20 11 00 00 00 FF 00 FF 11 FF FF FF FF FF RTW: 0x0d0: 3E 10 01 12 23 FF FF FF 20 04 4C 02 23 D7 21 02 RTW: 0x0e0: 0C 00 22 04 00 08 00 32 FF 21 02 0C 00 22 2A 01 RTW: 0x0f0: 01 00 00 00 00 00 00 00 00 00 00 00 02 00 FF FF RTW: 0x100: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 RTW: 0x110: 00 EB 00 6E 01 00 00 00 00 FF 38 D2 CA F6 04 7D RTW: 0x120: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF RTW: 0x130: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF RTW: 0x140: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF RTW: 0x150: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF RTW: 0x160: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF RTW: 0x170: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF RTW: 0x180: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF RTW: 0x190: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF RTW: 0x1a0: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF RTW: 0x1b0: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF RTW: 0x1c0: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF RTW: 0x1d0: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF RTW: 0x1e0: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF RTW: 0x1f0: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF ```

[lwfinger]

You need the sudo version.

[briansune]

You need the sudo version.

I do used sudo see the image carefully. the fail is not intended but just pressing up to command line ping.

[briansune]

@RadxaYuntian

I had find the old board and do some test with the default RTW88 driver. This is the board that used to test and issue of this post is based on this board at very beginning. Results are as follow:

Erros

``` briansune@zynq_brian:~/drv$ ip link 1: lo: mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 2: sit0@NONE: mtu 1480 qdisc noop state DOWN mode DEFAULT group default qlen 1000 link/sit 0.0.0.0 brd 0.0.0.0 3: wlan0: mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000 link/ether ff:ff:ff:ff:ff:ff brd ff:ff:ff:ff:ff:ff briansune@zynq_brian:~/drv$ sudo ip link set dev wlan0 address 12:e1:7d:f8:a3:e5 briansune@zynq_brian:~/drv$ sudo iw dev wlan0 scan | grep SSID briansune@zynq_brian:~/drv$ rtw_8723ds mmc1:0001:1: failed to poll offset=0x5f8 mask=0xff value=0x0 briansune@zynq_brian:~/drv$ sudo iw dev wlan0 scan | grep SSID rtw_8723ds mmc1:0001:1: failed to poll offset=0x5f8 mask=0xff value=0x0 rtw_8723ds mmc1:0001:1: mac power on failed rtw_8723ds mmc1:0001:1: failed to power on mac rtw_8723ds mmc1:0001:1: leave idle state failed rtw_8723ds mmc1:0001:1: failed to leave ips state rtw_8723ds mmc1:0001:1: failed to leave idle state briansune@zynq_brian:~/drv$ sudo iw dev wlan0 scan | grep SSID rtw_8723ds mmc1:0001:1: failed to poll offset=0x5f8 mask=0xff value=0x0 rtw_8723ds mmc1:0001:1: mac power on failed rtw_8723ds mmc1:0001:1: failed to power on mac rtw_8723ds mmc1:0001:1: leave idle state failed rtw_8723ds mmc1:0001:1: failed to leave ips state rtw_8723ds mmc1:0001:1: failed to leave idle state briansune@zynq_brian:~/drv$ ```

Old Board Dump Log

``` RTW: HW EFUSE Bluetooth: RFCOMM ver 1.11 RTW: 0x000: 29 81 00 7C E1 88 07 00 A0 04 EC 35 12 C0 A2 D8 RTW: 0x010: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF RTW: 0x020: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF RTW: 0x030: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF RTW: 0x040: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF RTW: 0x050: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF RTW: 0x060: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF RTW: 0x070: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF RTW: 0x080: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF RTW: 0x090: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF RTW: 0x0a0: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF RTW: 0x0b0: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF RTW: 0x0c0: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF RTW: 0x0d0: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF RTW: 0x0e0: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF RTW: 0x0f0: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF RTW: 0x100: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF RTW: 0x110: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF RTW: 0x120: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF RTW: 0x130: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF RTW: 0x140: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF RTW: 0x150: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF RTW: 0x160: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF RTW: 0x170: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF RTW: 0x180: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF RTW: 0x190: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF RTW: 0x1a0: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF RTW: 0x1b0: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF RTW: 0x1c0: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF RTW: 0x1d0: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF RTW: 0x1e0: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF RTW: 0x1f0: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF ```

[RadxaYuntian]

Yes your old board has the same unprogrammed eFuse like what I have. Your new board is programmed in some fields so it was able to connect to the network. Now we need to figure out which default value needs to be replaced and why vendor driver was working.

[briansune]

@RadxaYuntian

But there is a very puzzling question RTW88 SDIO driver suppose to be work out of the box on fused RTL8723DS chip. As you also confirmed some of my board WIFI IC do have EFUSE preloaded. But the above result shows a poor connection nor a stable performance.

Myself as part of RF hardware engineer so antenna is 99% sure tuned to the best performance. So unless noise are strongly coupled to the antenna it must be stable (hardware level).

BTW, I planed to get a RTL8723DS module and transfer to one of the test board. Should be arrive within 1 week

[RadxaYuntian]

In my definition the eFuse is programmed when there are non 0xFF byte past 0x10 offset. I assume first 16 bytes are preprogrammed by Realtek so it's beyond us OEM. It's the data after those 16 bytes that we could program during manufacture process.

By this definition your old board is NOT programmed, and your new board is programmed. RTW88 did work on your new board, but failed on your old board.

[briansune]

@RadxaYuntian

This is understood and no confusion. But one most important issue is even with a programmed EFUSE chip the RTW88 still perform poorly compared with vendor driver.

[RadxaYuntian]

For that you will need to contact the driver maintainer.

[briansune]

@RadxaYuntian

That is the point, when RTW88 is not stable and perform as vendor RTL8723DS why begin to fix the driver until the inherent RTW88 is working stably?

[briansune]

@RadxaYuntian

I would like to confirm one more info on your board. When you use old vendor driver aka RTL8723DS repository. Once you can ping and have network connected, do a reboot still able to auto connect back to the same network? Or it requires you to connect again by manual operation?

[RadxaYuntian]

Once you can ping and have network connected, do a reboot still able to auto connect back to the same network?

This is correct, and I can ping gateway right after reboot.

[RadxaYuntian]

I have updated the default eFuse value based on @briansune 's dumps. As such, I can connect to network and ping gateway even when my eFuse is unprogrammed.

I have observed the same Destination Host Unreachable issue as reported above. From the kernel message it appears to be very aggressive AP hopping (we have multiple APs providing the same Wi-Fi network):

dmesg

``` [ 12.013024] rtw_core: loading out-of-tree module taints kernel. [ 12.035765] Bluetooth: hci0: RTL: examining hci_ver=08 hci_rev=000d lmp_ver=08 lmp_subver=8723 [ 12.040181] Bluetooth: hci0: RTL: rom_version status=0 version=2 [ 12.040232] Bluetooth: hci0: RTL: loading rtl_bt/rtl8723ds_fw.bin [ 12.060939] Bluetooth: hci0: RTL: loading rtl_bt/rtl8723ds_config.bin [ 12.088112] using random self ethernet address [ 12.088145] using random host ethernet address [ 12.093042] Bluetooth: hci0: RTL: cfg_sz 47, total sz 30147 [ 12.157779] rtw_8723ds mmc2:0001:1: Firmware version 48.0.0, H2C version 0 [ 12.183726] read descriptors [ 12.183776] read strings [ 12.233463] usb0: HOST MAC 3a:0d:45:8e:cf:7e [ 12.233509] usb0: MAC 76:b6:65:97:0f:a4 [ 12.233733] dwc2 ff400000.usb: bound driver configfs-gadget.radxa-otgutils [ 12.248023] dwc2 ff400000.usb: dwc2_core_reset: HANG! Soft Reset timeout GRSTCTL_CSFTRST [ 12.657611] Bluetooth: hci0: RTL: fw version 0xaa5d675f [ 12.923434] Bluetooth: BNEP (Ethernet Emulation) ver 1.3 [ 12.923497] Bluetooth: BNEP socket layer initialized [ 12.943521] Bluetooth: MGMT ver 1.22 [ 12.969710] NET: Registered PF_ALG protocol family [ 13.191873] rk_gmac-dwmac ff4e0000.ethernet end0: Register MEM_TYPE_PAGE_POOL RxQ-0 [ 13.195475] rk_gmac-dwmac ff4e0000.ethernet end0: PHY [stmmac-0:00] driver [RTL8201F Fast Ethernet] (irq=POLL) [ 13.195546] rk_gmac-dwmac ff4e0000.ethernet end0: No Safety Features support found [ 13.195569] rk_gmac-dwmac ff4e0000.ethernet end0: PTP not supported by HW [ 13.197092] rk_gmac-dwmac ff4e0000.ethernet end0: configuring for phy/rmii link mode [ 15.755743] wlan0: authenticate with c6:70:ab:14:3f:1d [ 15.755841] wlan0: 80 MHz not supported, disabling VHT [ 16.484479] wlan0: send auth to c6:70:ab:14:3f:1d (try 1/3) [ 16.493805] wlan0: authenticated [ 16.494929] wlan0: associate with c6:70:ab:14:3f:1d (try 1/3) [ 16.513194] wlan0: RX AssocResp from c6:70:ab:14:3f:1d (capab=0x1c21 status=0 aid=27) [ 16.525209] wlan0: associated [ 16.531084] IPv6: ADDRCONF(NETDEV_CHANGE): wlan0: link becomes ready [ 16.543623] wlan0: Limiting TX power to 30 (30 - 0) dBm as advertised by c6:70:ab:14:3f:1d [ 22.765226] platform sound: deferred probe pending [ 58.447454] wlan0: authenticate with c6:70:ab:14:3f:1d [ 58.447558] wlan0: 80 MHz not supported, disabling VHT [ 59.172044] wlan0: send auth to c6:70:ab:14:3f:1d (try 1/3) [ 59.177929] wlan0: authenticated [ 59.184768] wlan0: associate with c6:70:ab:14:3f:1d (try 1/3) [ 59.846997] wlan0: associate with c6:70:ab:14:3f:1d (try 2/3) [ 60.838941] wlan0: associate with c6:70:ab:14:3f:1d (try 3/3) [ 61.830942] wlan0: association with c6:70:ab:14:3f:1d timed out [ 64.228349] wlan0: authenticate with c6:70:ab:12:b2:43 [ 64.228457] wlan0: 80 MHz not supported, disabling VHT [ 64.820436] wlan0: send auth to c6:70:ab:12:b2:43 (try 1/3) [ 64.824237] wlan0: authenticated [ 64.829769] wlan0: associate with c6:70:ab:12:b2:43 (try 1/3) [ 64.852460] wlan0: RX AssocResp from c6:70:ab:12:b2:43 (capab=0x1c21 status=0 aid=17) [ 64.860187] wlan0: associated [ 65.027520] wlan0: Limiting TX power to 30 (30 - 0) dBm as advertised by c6:70:ab:12:b2:43 [ 95.152635] rtw_8723ds mmc2:0001:1: timed out to flush queue 2 [ 95.292634] rtw_8723ds mmc2:0001:1: timed out to flush queue 2 [ 95.732415] rtw_8723ds mmc2:0001:1: timed out to flush queue 2 [ 95.872357] rtw_8723ds mmc2:0001:1: timed out to flush queue 2 [ 96.304263] rtw_8723ds mmc2:0001:1: timed out to flush queue 2 [ 96.444148] rtw_8723ds mmc2:0001:1: timed out to flush queue 2 [ 99.822521] rtw_8723ds mmc2:0001:1: failed to get tx report from firmware [ 132.965195] rtw_8723ds mmc2:0001:1: failed to get tx report from firmware [ 134.213601] rtw_8723ds mmc2:0001:1: failed to get tx report from firmware [ 146.216783] rtw_8723ds mmc2:0001:1: failed to get tx report from firmware [ 150.217668] rtw_8723ds mmc2:0001:1: failed to get tx report from firmware [ 159.211525] rtw_8723ds mmc2:0001:1: failed to get tx report from firmware [ 166.794456] rtw_8723ds mmc2:0001:1: failed to get tx report from firmware [ 200.693409] rtw_8723ds mmc2:0001:1: failed to get tx report from firmware [ 234.512414] rtw_8723ds mmc2:0001:1: failed to get tx report from firmware [ 268.360819] rtw_8723ds mmc2:0001:1: failed to get tx report from firmware [ 280.213430] rtw_8723ds mmc2:0001:1: failed to get tx report from firmware [ 297.921873] rtw_8723ds mmc2:0001:1: timed out to flush queue 1 [ 298.061796] rtw_8723ds mmc2:0001:1: timed out to flush queue 1 [ 299.125047] rtw_8723ds mmc2:0001:1: timed out to flush queue 1 [ 301.167856] rtw_8723ds mmc2:0001:1: timed out to flush queue 2 [ 302.317120] wlan0: disconnect from AP c6:70:ab:12:b2:43 for new auth to c6:70:ab:14:3f:1d [ 302.432042] wlan0: authenticate with c6:70:ab:14:3f:1d [ 302.432159] wlan0: 80 MHz not supported, disabling VHT [ 302.814689] rtw_8723ds mmc2:0001:1: failed to get tx report from firmware [ 303.005596] wlan0: send auth to c6:70:ab:14:3f:1d (try 1/3) [ 303.011115] wlan0: authenticated [ 303.014724] wlan0: associate with c6:70:ab:14:3f:1d (try 1/3) [ 303.026856] wlan0: RX ReassocResp from c6:70:ab:14:3f:1d (capab=0x1c21 status=0 aid=27) [ 303.033139] wlan0: associated [ 304.610166] wlan0: Limiting TX power to 30 (30 - 0) dBm as advertised by c6:70:ab:14:3f:1d [ 306.937981] wlan0: authenticate with c6:70:ab:12:b2:43 [ 306.938080] wlan0: 80 MHz not supported, disabling VHT [ 307.861895] wlan0: send auth to c6:70:ab:12:b2:43 (try 1/3) [ 307.879294] wlan0: authenticated [ 307.881162] wlan0: associate with c6:70:ab:12:b2:43 (try 1/3) [ 307.896198] wlan0: RX AssocResp from c6:70:ab:12:b2:43 (capab=0x1c21 status=0 aid=17) [ 307.902008] wlan0: associated [ 307.938901] wlan0: Limiting TX power to 30 (30 - 0) dBm as advertised by c6:70:ab:12:b2:43 [ 372.838231] rtw_8723ds mmc2:0001:1: timed out to flush queue 1 [ 517.347062] wlan0: authenticate with c6:70:ab:12:b2:43 [ 517.347168] wlan0: 80 MHz not supported, disabling VHT [ 518.098243] wlan0: send auth to c6:70:ab:12:b2:43 (try 1/3) [ 518.734641] wlan0: send auth to c6:70:ab:12:b2:43 (try 2/3) [ 518.738254] wlan0: authenticated [ 518.739802] wlan0: associate with c6:70:ab:12:b2:43 (try 1/3) [ 518.749194] wlan0: RX AssocResp from c6:70:ab:12:b2:43 (capab=0x1c21 status=0 aid=17) [ 518.755289] wlan0: associated [ 518.979783] wlan0: Limiting TX power to 30 (30 - 0) dBm as advertised by c6:70:ab:12:b2:43 [ 715.323406] wlan0: authenticate with c6:70:ab:14:3f:1d [ 715.323499] wlan0: 80 MHz not supported, disabling VHT [ 716.158919] wlan0: send auth to c6:70:ab:14:3f:1d (try 1/3) [ 716.171340] wlan0: authenticated [ 716.173830] wlan0: associate with c6:70:ab:14:3f:1d (try 1/3) [ 716.191422] wlan0: RX AssocResp from c6:70:ab:14:3f:1d (capab=0x1c21 status=0 aid=23) [ 716.207025] wlan0: associated [ 720.606928] wlan0: authenticate with c6:70:ab:14:3f:1d [ 720.607029] wlan0: 80 MHz not supported, disabling VHT [ 721.269518] wlan0: send auth to c6:70:ab:14:3f:1d (try 1/3) [ 721.273264] wlan0: authenticated [ 721.275874] wlan0: associate with c6:70:ab:14:3f:1d (try 1/3) [ 722.776607] wlan0: associate with c6:70:ab:14:3f:1d (try 2/3) [ 723.734764] wlan0: associate with c6:70:ab:14:3f:1d (try 3/3) [ 724.756802] wlan0: association with c6:70:ab:14:3f:1d timed out [ 725.811503] wlan0: authenticate with c6:70:ab:12:b2:43 [ 725.811609] wlan0: 80 MHz not supported, disabling VHT [ 726.568111] wlan0: send auth to c6:70:ab:12:b2:43 (try 1/3) [ 726.571056] wlan0: authenticated [ 726.576643] wlan0: associate with c6:70:ab:12:b2:43 (try 1/3) [ 726.590357] wlan0: RX AssocResp from c6:70:ab:12:b2:43 (capab=0x1c21 status=0 aid=17) [ 726.595303] wlan0: associated [ 726.655577] wlan0: Limiting TX power to 30 (30 - 0) dBm as advertised by c6:70:ab:12:b2:43 [ 824.621957] rtw_8723ds mmc2:0001:1: timed out to flush queue 2 [ 824.761925] rtw_8723ds mmc2:0001:1: timed out to flush queue 2 [ 825.201793] rtw_8723ds mmc2:0001:1: timed out to flush queue 2 [ 1162.306925] wlan0: disconnect from AP c6:70:ab:12:b2:43 for new auth to c6:70:ab:14:3f:1d [ 1162.390727] wlan0: authenticate with c6:70:ab:14:3f:1d [ 1162.390845] wlan0: 80 MHz not supported, disabling VHT [ 1162.833393] rtw_8723ds mmc2:0001:1: failed to get tx report from firmware [ 1163.174793] wlan0: send auth to c6:70:ab:14:3f:1d (try 1/3) [ 1163.185894] wlan0: authenticated [ 1163.189548] wlan0: associate with c6:70:ab:14:3f:1d (try 1/3) [ 1163.197005] wlan0: RX ReassocResp from c6:70:ab:14:3f:1d (capab=0x1c21 status=0 aid=18) [ 1163.202825] wlan0: associated [ 1164.085167] wlan0: Limiting TX power to 30 (30 - 0) dBm as advertised by c6:70:ab:14:3f:1d [ 1171.189013] wlan0: authenticate with c6:70:ab:12:b2:43 [ 1171.189117] wlan0: 80 MHz not supported, disabling VHT [ 1171.972051] wlan0: send auth to c6:70:ab:12:b2:43 (try 1/3) [ 1172.745464] wlan0: send auth to c6:70:ab:12:b2:43 (try 2/3) [ 1172.747945] wlan0: authenticated [ 1172.752060] wlan0: associate with c6:70:ab:12:b2:43 (try 1/3) [ 1172.762268] wlan0: RX AssocResp from c6:70:ab:12:b2:43 (capab=0x1c21 status=0 aid=17) [ 1172.768509] wlan0: associated [ 1172.934772] wlan0: Limiting TX power to 30 (30 - 0) dBm as advertised by c6:70:ab:12:b2:43 [ 1274.425369] wlan0: disconnect from AP c6:70:ab:12:b2:43 for new auth to c6:70:ab:14:33:e7 [ 1274.505855] wlan0: authenticate with c6:70:ab:14:33:e7 [ 1274.505973] wlan0: 80 MHz not supported, disabling VHT [ 1275.119437] wlan0: send auth to c6:70:ab:14:33:e7 (try 1/3) [ 1275.123047] wlan0: authenticated [ 1275.130830] wlan0: associate with c6:70:ab:14:33:e7 (try 1/3) [ 1275.149647] wlan0: RX ReassocResp from c6:70:ab:14:33:e7 (capab=0x1c21 status=0 aid=21) [ 1275.156288] wlan0: associated [ 1276.702058] wlan0: Limiting TX power to 30 (30 - 0) dBm as advertised by c6:70:ab:14:33:e7 [ 1280.103125] wlan0: authenticate with c6:70:ab:14:3f:1d [ 1280.103231] wlan0: 80 MHz not supported, disabling VHT [ 1280.847073] wlan0: send auth to c6:70:ab:14:3f:1d (try 1/3) [ 1280.852663] wlan0: authenticated [ 1280.861625] wlan0: associate with c6:70:ab:14:3f:1d (try 1/3) [ 1280.888237] wlan0: RX AssocResp from c6:70:ab:14:3f:1d (capab=0x1c21 status=0 aid=18) [ 1280.899543] wlan0: associated [ 1281.542922] wlan0: Limiting TX power to 30 (30 - 0) dBm as advertised by c6:70:ab:14:3f:1d [ 1286.346207] wlan0: deauthenticating from c6:70:ab:14:3f:1d by local choice (Reason: 3=DEAUTH_LEAVING) [ 1291.042209] wlan0: authenticate with c8:bf:4c:77:da:fc [ 1291.042308] wlan0: 80 MHz not supported, disabling VHT [ 1291.937882] wlan0: send auth to c8:bf:4c:77:da:fc (try 1/3) [ 1292.687944] wlan0: send auth to c8:bf:4c:77:da:fc (try 2/3) [ 1293.712970] wlan0: send auth to c8:bf:4c:77:da:fc (try 3/3) [ 1294.697275] wlan0: authentication with c8:bf:4c:77:da:fc timed out [ 1295.443995] wlan0: authenticate with d4:35:38:94:3c:6f [ 1295.444103] wlan0: 80 MHz not supported, disabling VHT [ 1296.106700] wlan0: send auth to d4:35:38:94:3c:6f (try 1/3) [ 1296.109283] wlan0: authenticated [ 1296.113152] wlan0: associate with d4:35:38:94:3c:6f (try 1/3) [ 1296.119092] wlan0: RX AssocResp from d4:35:38:94:3c:6f (capab=0x431 status=0 aid=11) [ 1296.126731] wlan0: associated [ 1296.197125] IPv6: ADDRCONF(NETDEV_CHANGE): wlan0: link becomes ready [ 1363.889459] wlan0: disconnect from AP d4:35:38:94:3c:6f for new auth to c8:bf:4c:77:da:fc [ 1363.954514] wlan0: authenticate with c8:bf:4c:77:da:fc [ 1363.954616] wlan0: 80 MHz not supported, disabling VHT [ 1364.363985] rtw_8723ds mmc2:0001:1: failed to get tx report from firmware [ 1364.764234] wlan0: send auth to c8:bf:4c:77:da:fc (try 1/3) [ 1365.681495] wlan0: send auth to c8:bf:4c:77:da:fc (try 2/3) [ 1366.642739] wlan0: send auth to c8:bf:4c:77:da:fc (try 3/3) [ 1367.658843] wlan0: authentication with c8:bf:4c:77:da:fc timed out [ 1369.728735] wlan0: authenticate with d4:35:38:94:3c:6f [ 1369.728861] wlan0: 80 MHz not supported, disabling VHT [ 1370.509517] wlan0: send auth to d4:35:38:94:3c:6f (try 1/3) [ 1370.679680] wlan0: authenticated [ 1370.682070] wlan0: associate with d4:35:38:94:3c:6f (try 1/3) [ 1370.688427] wlan0: RX AssocResp from d4:35:38:94:3c:6f (capab=0x431 status=0 aid=11) [ 1370.697900] wlan0: associated [ 1410.260543] wlan0: authenticate with d4:35:38:94:3c:6f [ 1410.260647] wlan0: 80 MHz not supported, disabling VHT [ 1411.005284] wlan0: send auth to d4:35:38:94:3c:6f (try 1/3) [ 1411.651800] wlan0: send auth to d4:35:38:94:3c:6f (try 2/3) [ 1411.655199] wlan0: authenticated [ 1411.657614] wlan0: associate with d4:35:38:94:3c:6f (try 1/3) [ 1411.665147] wlan0: RX AssocResp from d4:35:38:94:3c:6f (capab=0x431 status=0 aid=11) [ 1411.672761] wlan0: associated [ 1454.201497] wlan0: authenticate with d4:35:38:94:3c:6f [ 1454.201596] wlan0: 80 MHz not supported, disabling VHT [ 1454.997086] wlan0: send auth to d4:35:38:94:3c:6f (try 1/3) [ 1455.162482] wlan0: authenticated [ 1455.165516] wlan0: associate with d4:35:38:94:3c:6f (try 1/3) [ 1455.171168] wlan0: RX AssocResp from d4:35:38:94:3c:6f (capab=0x431 status=0 aid=11) [ 1455.177210] wlan0: associated [ 1553.799632] rtw_8723ds mmc2:0001:1: timed out to flush queue 1 [ 1556.414980] wlan0: disconnect from AP d4:35:38:94:3c:6f for new auth to c8:bf:4c:77:da:fc [ 1556.494935] wlan0: authenticate with c8:bf:4c:77:da:fc [ 1556.495038] wlan0: 80 MHz not supported, disabling VHT [ 1557.172519] wlan0: send auth to c8:bf:4c:77:da:fc (try 1/3) [ 1558.475171] wlan0: send auth to c8:bf:4c:77:da:fc (try 2/3) [ 1559.466463] wlan0: send auth to c8:bf:4c:77:da:fc (try 3/3) [ 1560.451328] wlan0: authentication with c8:bf:4c:77:da:fc timed out [ 1561.115521] wlan0: authenticate with d4:35:38:94:3c:6f [ 1561.115620] wlan0: 80 MHz not supported, disabling VHT [ 1561.851640] wlan0: send auth to d4:35:38:94:3c:6f (try 1/3) [ 1562.435390] wlan0: send auth to d4:35:38:94:3c:6f (try 2/3) [ 1562.437520] wlan0: authenticated [ 1562.442233] wlan0: associate with d4:35:38:94:3c:6f (try 1/3) [ 1562.447792] wlan0: RX AssocResp from d4:35:38:94:3c:6f (capab=0x431 status=0 aid=11) [ 1562.455781] wlan0: associated [ 1569.258858] wlan0: authenticate with d4:35:38:94:3c:6f [ 1569.258957] wlan0: 80 MHz not supported, disabling VHT [ 1569.983464] wlan0: send auth to d4:35:38:94:3c:6f (try 1/3) [ 1570.106190] wlan0: authenticated [ 1570.109444] wlan0: associate with d4:35:38:94:3c:6f (try 1/3) [ 1570.118694] wlan0: RX AssocResp from d4:35:38:94:3c:6f (capab=0x431 status=0 aid=11) [ 1570.125427] wlan0: associated [ 1604.337385] wlan0: disconnect from AP d4:35:38:94:3c:6f for new auth to c8:bf:4c:77:da:fc [ 1604.432574] wlan0: authenticate with c8:bf:4c:77:da:fc [ 1604.432682] wlan0: 80 MHz not supported, disabling VHT [ 1605.176214] wlan0: send auth to c8:bf:4c:77:da:fc (try 1/3) [ 1605.796033] wlan0: send auth to c8:bf:4c:77:da:fc (try 2/3) [ 1606.823782] wlan0: send auth to c8:bf:4c:77:da:fc (try 3/3) [ 1607.779335] wlan0: authentication with c8:bf:4c:77:da:fc timed out [ 1608.523658] wlan0: authenticate with d4:35:38:94:3c:6f [ 1608.523765] wlan0: 80 MHz not supported, disabling VHT [ 1609.220372] wlan0: send auth to d4:35:38:94:3c:6f (try 1/3) [ 1609.397463] wlan0: authenticated [ 1609.401983] wlan0: associate with d4:35:38:94:3c:6f (try 1/3) [ 1609.408426] wlan0: RX AssocResp from d4:35:38:94:3c:6f (capab=0x431 status=0 aid=11) [ 1609.416292] wlan0: associated [ 1643.073529] wlan0: disconnect from AP d4:35:38:94:3c:6f for new auth to c8:bf:4c:77:da:fc [ 1643.118595] wlan0: authenticate with c8:bf:4c:77:da:fc [ 1643.118729] wlan0: 80 MHz not supported, disabling VHT [ 1643.859470] wlan0: send auth to c8:bf:4c:77:da:fc (try 1/3) [ 1644.790368] wlan0: send auth to c8:bf:4c:77:da:fc (try 2/3) [ 1645.815421] wlan0: send auth to c8:bf:4c:77:da:fc (try 3/3) [ 1646.799852] wlan0: authentication with c8:bf:4c:77:da:fc timed out [ 1648.852366] wlan0: authenticate with d4:35:38:94:3c:6f [ 1648.852471] wlan0: 80 MHz not supported, disabling VHT [ 1649.756325] wlan0: send auth to d4:35:38:94:3c:6f (try 1/3) [ 1649.938730] wlan0: authenticated [ 1649.943417] wlan0: associate with d4:35:38:94:3c:6f (try 1/3) [ 1649.949413] wlan0: RX AssocResp from d4:35:38:94:3c:6f (capab=0x431 status=0 aid=11) [ 1649.955704] wlan0: associated [ 1681.056819] wlan0: authenticate with c8:bf:4c:77:da:fc [ 1681.056918] wlan0: 80 MHz not supported, disabling VHT [ 1681.678487] wlan0: send auth to c8:bf:4c:77:da:fc (try 1/3) [ 1682.724971] wlan0: send auth to c8:bf:4c:77:da:fc (try 2/3) [ 1683.717508] wlan0: send auth to c8:bf:4c:77:da:fc (try 3/3) [ 1684.701282] wlan0: authentication with c8:bf:4c:77:da:fc timed out [ 1686.795726] wlan0: authenticate with d4:35:38:94:3c:6f [ 1686.795826] wlan0: 80 MHz not supported, disabling VHT [ 1687.598999] wlan0: send auth to d4:35:38:94:3c:6f (try 1/3) [ 1688.736829] wlan0: send auth to d4:35:38:94:3c:6f (try 2/3) [ 1688.740489] wlan0: authenticated [ 1688.742476] wlan0: associate with d4:35:38:94:3c:6f (try 1/3) [ 1688.750401] wlan0: RX AssocResp from d4:35:38:94:3c:6f (capab=0x431 status=0 aid=11) [ 1688.757102] wlan0: associated [ 1697.087547] wlan0: authenticate with c8:bf:4c:77:da:fc [ 1697.087663] wlan0: 80 MHz not supported, disabling VHT [ 1697.930344] wlan0: send auth to c8:bf:4c:77:da:fc (try 1/3) [ 1698.688005] wlan0: send auth to c8:bf:4c:77:da:fc (try 2/3) [ 1699.677336] wlan0: send auth to c8:bf:4c:77:da:fc (try 3/3) [ 1700.692414] wlan0: authentication with c8:bf:4c:77:da:fc timed out [ 1702.770711] wlan0: authenticate with d4:35:38:94:3c:6f [ 1702.770811] wlan0: 80 MHz not supported, disabling VHT [ 1703.443741] wlan0: send auth to d4:35:38:94:3c:6f (try 1/3) [ 1704.657651] wlan0: send auth to d4:35:38:94:3c:6f (try 2/3) [ 1704.667456] wlan0: authenticated [ 1704.671115] wlan0: associate with d4:35:38:94:3c:6f (try 1/3) [ 1704.680864] wlan0: RX AssocResp from d4:35:38:94:3c:6f (capab=0x431 status=0 aid=11) [ 1704.690001] wlan0: associated [ 1738.569404] wlan0: disconnect from AP d4:35:38:94:3c:6f for new auth to c8:bf:4c:77:da:fc [ 1738.637923] wlan0: authenticate with c8:bf:4c:77:da:fc [ 1738.638036] wlan0: 80 MHz not supported, disabling VHT [ 1739.309256] wlan0: send auth to c8:bf:4c:77:da:fc (try 1/3) [ 1740.617446] wlan0: send auth to c8:bf:4c:77:da:fc (try 2/3) [ 1741.638766] wlan0: send auth to c8:bf:4c:77:da:fc (try 3/3) [ 1742.625526] wlan0: authentication with c8:bf:4c:77:da:fc timed out [ 1743.407054] wlan0: authenticate with d4:35:38:94:3c:6f [ 1743.407182] wlan0: 80 MHz not supported, disabling VHT [ 1744.090175] wlan0: send auth to d4:35:38:94:3c:6f (try 1/3) [ 1744.281956] wlan0: authenticated [ 1744.284530] wlan0: associate with d4:35:38:94:3c:6f (try 1/3) [ 1744.290254] wlan0: RX AssocResp from d4:35:38:94:3c:6f (capab=0x431 status=0 aid=11) [ 1744.298044] wlan0: associated [ 1760.033094] wlan0: authenticate with d4:35:38:94:3c:6f [ 1760.033191] wlan0: 80 MHz not supported, disabling VHT [ 1760.894696] wlan0: send auth to d4:35:38:94:3c:6f (try 1/3) [ 1761.072371] wlan0: authenticated [ 1761.074050] wlan0: associate with d4:35:38:94:3c:6f (try 1/3) [ 1761.638027] wlan0: associate with d4:35:38:94:3c:6f (try 2/3) [ 1761.647832] wlan0: RX AssocResp from d4:35:38:94:3c:6f (capab=0x431 status=0 aid=11) [ 1761.658277] wlan0: associated [ 1775.927303] wlan0: authenticate with d4:35:38:94:3c:6f [ 1775.927401] wlan0: 80 MHz not supported, disabling VHT [ 1776.596486] wlan0: send auth to d4:35:38:94:3c:6f (try 1/3) [ 1776.782371] wlan0: authenticated [ 1776.784408] wlan0: associate with d4:35:38:94:3c:6f (try 1/3) [ 1776.790191] wlan0: RX AssocResp from d4:35:38:94:3c:6f (capab=0x431 status=0 aid=11) [ 1776.798307] wlan0: associated [ 1779.910321] wlan0: deauthenticated from d4:35:38:94:3c:6f (Reason: 15=4WAY_HANDSHAKE_TIMEOUT) [ 1781.630453] wlan0: authenticate with d4:35:38:94:3c:6f [ 1781.630552] wlan0: 80 MHz not supported, disabling VHT [ 1782.222128] wlan0: send auth to d4:35:38:94:3c:6f (try 1/3) [ 1782.224849] wlan0: authenticated [ 1782.227037] wlan0: associate with d4:35:38:94:3c:6f (try 1/3) [ 1782.232903] wlan0: RX AssocResp from d4:35:38:94:3c:6f (capab=0x431 status=0 aid=11) [ 1782.240670] wlan0: associated ```

[briansune]

@RadxaYuntian

The new batch show a very bizarre situation. Using old vendor driver on RTL8723 result as follows: Issue-> driver can load and make rtl8723ds start working on BT and WiFI but once a reboot or halt and power-cycled the WiFi is unable to auto connect to the previous stored WiFi. The same SD-Card on different board does not recreate the same issue, and other board can easily reconnect once it reboot. As such, a dump is also preformed and the EFUSE is purely blank (exclude first 16 byte).

[RadxaYuntian]

That is the point, when RTW88 is not stable and perform as vendor RTL8723DS why begin to fix the driver until the inherent RTW88 is working stably?

Now is the time to answer this question. Because nobody wants to deal with vendor driver, so when something is not working, you have to rely on the vendor to fix it.

RTW88 is community maintained so if there is an issue we could fix it.

[briansune]

@RadxaYuntian

No the point I want to make is a blank chip could also result in some very puzzling situation like what I had just shown. Function-wise is all working but once reboot the kernel or network-manager seem have trouble to auto reconnect. If manually connect to WIFI all is stable and working.

I just want to clear out could this be the kernel issue as other board on the same SD-Card aka kernel do not have such issue.

[briansune]

@RadxaYuntian

Okay I found that this issue is highly due to MAC random default on every boot.

[lwfinger]

@RadxaYuntian - I make some comments on you trial commit. I think it was a lot more elaborate that was required.

[briansune]

@RadxaYuntian

1)The same issue happen on two board currently I received from SMT. If RTL8723DS vendor driver fix a blank EFUSE IC. The MAC will randomly change every boot. So nmcli or nmtui will got to modify the connection config file to a no specific MAC.

2) @lwfinger according to some research and report from REALTEK chip. The EFUSE is commonly got flushed by parasitic voltage stored in bypass capacitors. And this is why there are also reuse chip in the market is got flushed to blank EFUSE. So a self-recover driver is really a must.

[RadxaYuntian]

I think it was a lot more elaborate that was required.

Yeah I was not intended to submit that, which is why it was marked as HACK.

If RTL8723DS vendor driver fix a blank EFUSE IC. The MAC will randomly change every boot.

The random MAC is generated here.

I also tried to check if there is a way for Linux to notify upper layer about missing MAC address. So far I have found nothing (except if we want a random MAC we could use eth_hw_addr_random).

We also have some devices with RTL8211 GbE controller without MAC programmed, and they get consistent MAC address from U-Boot. I'm not sure if this is something that can be done from Linux only that doesn't involve platform specific unique ID.

[briansune]

@RadxaYuntian

Just share RTL8211 experience on my side. This chip is very old and too many examples and even too many boards had been used in Asia side. So this chip don't even need to concern about not working from first place (Ethernet is more easier and stable when come to driver, what do you expected on GMII or RGMII protocol low speed and not complex).

As I had mentioned EEPROM could be corrupted when the voltage level is remain at some level (remain capacitor charge) and once that is hold during reboot the problem could ends up very very wrong. There are so many story myself also experienced on some client product and claiming stuck or fail working after while. (Not REALTEK product and mostly memory oriented and hardware design itself can't even prevented from first place as vendor or IC design also can't define when it will be the case).

I will try to fix the MAC and see the different, and thank you for locating the line I need to modify really helps out. =]

[briansune]

@lwfinger @RadxaYuntian

I would like to know why the vendor driver try to read /data/wifimac.txt and even adding such file won't able to make it read the MAC.

I do see it uses func - isFileReadable @osdep_service.c

From rtw_read_macaddr_from_file @hal_com.c

And begin call hal_config_macaddr @sdio_halinit.c

And other thing I tried and should make the old one or the new RTW88 better: As MAC is random or fix in here. So it is better to make it more controllable via MAKE or Kconfig.

I adjusted as follow:

err_chk:

#ifndef CONFIG_RTW_MAC_B4
#define CONFIG_RTW_MAC_B4 0x00
#endif

#ifndef CONFIG_RTW_MAC_B5
#define CONFIG_RTW_MAC_B5 0x00
#endif

    if (rtw_check_invalid_mac_address(mac, _TRUE) == _TRUE) {
#ifdef CONFIG_RTW_RANDOM_MAC
        RTW_ERR("invalid mac addr:"MAC_FMT", assign random MAC\n", MAC_ARG(mac));
        *((u32 *)(&mac[2])) = rtw_random32();
        mac[0] = 0x00;
        mac[1] = 0xe0;
        mac[2] = 0x4c;
#else
        RTW_ERR("invalid mac addr:"MAC_FMT", assign default one\n", MAC_ARG(mac));
        mac[0] = 0x00;
        mac[1] = 0xe0;
        mac[2] = 0x4c;
        mac[3] = 0x87;
        mac[4] = CONFIG_RTW_MAC_B4;
        mac[5] = CONFIG_RTW_MAC_B5;
#endif
    }

    _rtw_memcpy(out, mac, ETH_ALEN);
    RTW_INFO("%s mac addr:"MAC_FMT"\n", __func__, MAC_ARG(out));

And the Make file:

EXTRA_CFLAGS += -DCONFIG_RTW_RANDOM_MAC
or
EXTRA_CFLAGS += -DCONFIG_RTW_MAC_B4=0x12 -DCONFIG_RTW_MAC_B5=0x34

[lwfinger]

I have no idea what the vendor driver is trying to get by reading file wifimac.txt. From the name I would guess a MAC address. A better way would be to provide a module parameter where you could specify the MAC as a peermanent "options" file.

[briansune]

@lwfinger @RadxaYuntian

I am afraid even getting a real certificated WIFI-module and transfer to the custom board also preform poorly on the WIFI.

See Module:

See Transfer:

See ping test:

See the MAC load:

So RTW88 SDIO WIFI do have inherent issue that need to fix.

[briansune]

@lwfinger @RadxaYuntian

In case, I test the same transferred module IC board with Vendor driver. Very stable and well performed ping test.

But I am confused why RTW88 MAC is 4a:6d:a2:41:e1:b5 and RTL8723DS MAC is 68:39:43:9d:10:ef. RTL8723DS driver even reboot serval times show no change on MAC address (so it is a must using EFUSE settings). Do the RTW88 override the MAC address or there is a setting to use EFUSE or custom?

THANK YOU all support.

[lwfinger]

There may be a bug, but RTW88 should use the MAC address in the EFUSE. At the moment, it does not work unless the R=EFUSE has a MAC encoded. I will check that out.

Please provide an EFUSE dump for the current card.

[briansune]

@lwfinger

What do you need? The EFUSE dump using the old vendor driver?

[lwfinger]

Yes.

[briansune]

@lwfinger

Here you go. module_IC_DUMP.txt

[lwfinger]

Thanks. That dump shows the MAC address that the vendor driver shows starting at offset 0x11A. I have not yet discovered how RTW88 gets its address.

[RadxaYuntian]

But I am confused why RTW88 MAC is 4a:6d:a2:41:e1:b5 and RTL8723DS MAC is 68:39:43:9d:10:ef.

That is because I have to provide a dummy MAC for my own chip, which contains invalid MAC address(all 0xFF): https://github.com/radxa-pkg/rtw88/blob/issue_157/rtw8723d.c#L276

[briansune]

@RadxaYuntian

No you are not in the same page what this question it is referring. Read back to previous posts, I had brought a WIFI module and transfer the RTL8723DS chip to the custom board and the CHIP is preloaded with certificated RTL8723DS eFUSE.

Just read the previous post starting from https://github.com/lwfinger/rtw88/issues/157#issuecomment-1817053568.

The test are not using any of your driver nor a modified driver from RTW88 or RTL8723DS vendor driver.

The goal is to verify the default RTW88 driver is stable or not under a certificated module aka RTL8723 eFUSE with confirmed settings.

[RadxaYuntian]

Well the MAC you reported is exactly the one I defined in the code, so you must using my modified version.

[briansune]

@RadxaYuntian

Do the RTW88 driver from Iwfinger used your new RTW88 code?

[RadxaYuntian]

No, but you probably didn't install it correctly. Try removing it first then reinstall from this repo.

[briansune]

@RadxaYuntian

Okay there might be a mistake on my side I rerun the test again to make sure. Thank you for pointing out such MAC detail.

[briansune]

@RadxaYuntian

Yes, you are right the driver is using your modified one. A very fast update on the SD card show the follow result. And a fun fact is the RTW88 original one even perform worst than the modified RTW88. (Oh GOD =[)

See image.

[briansune]

@lwfinger @RadxaYuntian

So what are the solves here. As we all can see the result of a certificated RTL8723DS module also result in poor result.