WLAN0 had shown but network is down #157
Comments
|
Bringing your interface up is not the driver's responsibility. That is done by your user-space network control software. What are you using? I recommend NetworkManager. It Just Works. |
|
Do you mean the driver is working? I am using networkmanager ` Jul 26 02:08:52 localhost.localdomain NetworkManager[498]: |
|
Let me attach the dmesg: [ 99.221393] rtw_core: loading out-of-tree module taints kernel. |
|
I'm also having this issue. The wired thing is I did have this working before on 8723DS :/ I also have iwddmesg with debug_mask == -1Edit: rtl8723ds worked on the same hardware and system. |
|
I am not sure the root cause but what I had discussed with @lwfinger is that the RTW88 have not default firmware loading when IC is not fused with a firmware and this is my case. The board hardware is fully custom and IC is not from OEM or broker, which causes the IC is not fused with any default firmware. BR |
Same thing here. We are a SBC manufacturer and the affected is one of our product. I don't quite understand what you mean by firmware. From dmesg it appears to be loaded: I think you might mean eFUSE. I'll take a look at related code as well. |
|
Opps typo, it should be IC settings aka EFUSE not firmware. You are right eFUSE is what I am discussing. BR |
|
Why I will discuss @lwfinger with the EFUSE setting is because the XTAL is mostly the case along side with the DCDC. BR |
|
I looked into providing a default EFUSE when it is not programmed, but I got diverted. If the MAC address is all ones, the EFUSE is not programmed. |
|
Yes, if all ones are shown then EFUSE is not preloaded for the IC. Then the driver need to take place to preload a default one which the old RTL8723DS had provided. But RTW88 does not, which you need to update or extract those from the old repository. BR |
|
I am afraid I don't have that ability to transfer the old driver to the new old. I am mostly hardware engineer so this is really out of my scope and I would like to. =S |
|
I see there is |
|
My method to see the EFUSE is using old RTL8723DS repository and make the debug flag to 4 and during driver load there is a series of message that shown the EFUSE are all ZERO and then it will say loading a default one. |
|
Thanks for the hint. I have located I'll see what will happen if I inject them in |
|
Great, would be nice to push back to this repository. |
|
Spent last 2 days on this hack: radxa-pkg@9d2ffb5 Current status and insight learnt:
I think to fix it is currently beyond my scope, so we will have to use rtl8723ds in the mean time. |
|
Do a manual MAC assign make the LO lock? |
I'm not sure what you mean by LO lock. Also I did not try assigning MAC from user space. The MAC address was hardcoded in the driver for now.
Yes, albeit much less that what is available here. |
|
So the updated driver can work? As for LO = local oscillator: |
|
In case I wasn't clear the driver DOES NOT work for me. I was not able to connect to any network. If you still want to try it here is a Debian dkms package in zip (since GitHub doesn't allow deb uploading). I don't have the BOM but I think it is a 24M 12pF crystal. If you are curious here is the schematic for our product: https://dl.radxa.com/rockpis/docs/hw/ROCK-PI-S_v13_sch_200910.pdf Search 8723 to see the related page. |
|
I need a source to cross compile as my platform is not Debian but ubuntu on different ARM system. |
|
As for schematic short review show you are using DCDC setting. The custom board we had here do tired both LDO and DCDC on old RTL8723DS driver. Result both are normal, but DCDC sometime is more easier to be unstable as noise is more subjected to board layout. |
|
If you want source code it is available here: https://github.com/radxa-pkg/rtw88/tree/issue_157 |
|
Looking back I forgot to run with |
|
Let's compare and see if the issue is aligned. |
|
I got the current message: [ 27.285840] rtw_core: loading out-of-tree module taints kernel. |
|
Your eFuse must have been partially populated, as I changed You can change line 261 back to |
|
Network can scan and WIFI devices are showing up. And WIFI can ping and connect as well but not sure why nmcli works but not nmtui =S
LOG |
|
But I don't understand what is the major reason to use RTW88 rather than RTL8723DS driver? @lwfinger |
|
And there is a catch that looks like it is not too stable compared to old RTL8723DS:
|
|
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.
|
Yeah I was not intended to submit that, which is why it was marked as HACK.
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 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. |
|
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. =] |
|
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: I adjusted as follow: And the Make file: |
|
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. |
|
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. |
|
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. |
|
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. |
|
What do you need? The EFUSE dump using the old vendor driver? |
|
Yes. |
|
Here you go. |
|
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. |
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 |
|
No you are not in the same page what this question it is referring. Just read the previous post starting from #157 (comment). 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. |
|
Well the MAC you reported is exactly the one I defined in the code, so you must using my modified version. |
|
Do the RTW88 driver from Iwfinger used your new RTW88 code? |
|
No, but you probably didn't install it correctly. Try removing it first then reinstall from this repo. |
|
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. |
|
Yes, you are right the driver is using your modified one. See image. |
|
So what are the solves here. As we all can see the result of a certificated RTL8723DS module also result in poor result. |
|
The 8723D module maintainer will need to take a look at your issue. |
|
As for your side, do RTW88 driver + RTL8723DS chip shows no performance issue? |
|
@briansune - After you wasted my time by reporting the wrong MAC results, I have moved this thread down in my priority list. The reason for poor performance is that rtw88 only copies the MAC from EFUSE and ignores the calibration data, thus the performance problem. If one of you will dig into the vendor driver and tell me what data needs to be copied, then I can prepare a patch. Otherwise, I will ignore this thread. |
|
What do you mean wasted your time?
Did you see even with MAC address loading via the EFUSE even perform poor than a self combined EFUSE. As I already tried on the hardware side aka my time and money both are being wasted.
@lwfinger There are no proofs from this claim:
But only repeatable result of RTW88 driver cannot stably run WiFi: Either certificated EFUSE or not. Hope this is very clear. |
|
Well if you have no issue on RTW88 as @lwfinger have claimed it is better for me to close the issue. First I have no intension to use RTW88 as RTL8723DS already working properly and stably. If the original driver owner is not willing to fix it, I am afraid the driver RTW88 will never work normally on RTL8723DS SDIO chip. I had made my point. |
|
@briansune - You posted that the device with a valid EFUSE was giving a different MAC with rtw88 than with the vendor driver. I had wasted an hour trying to see why that was before @RadxaYuntian asked why you were getting the same MAC as he had dummied into his source. |
|
What are you suggesting? Only EFUSE and MAC is the concern here?
I am no god and neither a software based engineer. so with two parties driver @lwfinger you and @RadxaYuntian. Risk of mixing up is high. an hour of your vs two parities of works: If the driver inherently working properly would all these actions involved from beginning? Meanwhile, confusedness are strong why you need an hour from first place to see the EFUSE loading in the driver code? |
- RockPi-S needs rtl8723DS 3rd party driver, so keep it for this board (see lwfinger/rtw88#157 (comment)) - Asus Tinkerboard Rev.2 also has a 8723DS chipset, keep rtl8723DS driver for this board as well to be safe - BananaPi M4 Zero needs 3rd party driver for RTL8821CU to work properly, suspected cause is the immaturity of the H618 (Link: armbian#6703 (comment)) - Use new drivers from 6.10 onwards instead of 6.11
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
The text was updated successfully, but these errors were encountered: