Compiling kernel (6.1.26) fails #37
Comments
|
Hey, I would recommend that you switch to the rtw88 repo (https://github.com/lwfinger/rtw88.git). It, as well as kernel 6.4 due out in about 2 months, support all of the 802.11ac chips - PCI, USB, and SDIO. |
|
@lwfinger That's awesome news! Thanks for the information, I will try if I can get Wifi working on my SoC with the |
|
@lwfinger Hey again, I got it working with this repository by compiling it as a module and not make it built-in :) About the
Thanks for your help! |
|
You are right. I just asked the author of the other SDIO drivers why the 8723ds was not included. If someone is needed to test, would you be able to help? Many wifi drivers, including all of the rtw88 and rtw89 families, must be built as modules. The usual problem is some namespace contamination with the same symbol being defined in multiple drivers. |
|
Oh I see, thanks for the information. Yes I could help with testing. I'm currently tinkering with a MangoPi MQ-Quad (https://mangopi.org/mqquad) which has the 8723ds chip on it. But I only started getting into kernel/driver stuff, so I might need some help setting things up etc. |
|
Testing could be no more difficult than doing a 'git pull' from rtw88, building and trying, and then reporting the results including anything from the logs. If you can build modules, that will work. |
|
Alright I can do that :) Happy to help! |
|
I just pushed the 8723ds code. Do a 'git pull', 'make', and 'sudo make install'. Let me know how it works. |
|
I'm getting the following error when running CC [M] /root/rtw88/rtw8723ds.o
In file included from /root/rtw88/rtw8723ds.c:5:
/root/rtw88/rtw8723ds.c:14:15: error: ‘SDIO_VENDOR_ID_REALTEK’ undeclared here (not in a function); did you mean ‘SDIO_VENDOR_ID_MEDIATEK’?
14 | SDIO_DEVICE(SDIO_VENDOR_ID_REALTEK,
| ^~~~~~~~~~~~~~~~~~~~~~
/usr/src/linux-headers-5.10.0-16-common/include/linux/mmc/sdio_func.h:95:13: note: in definition of macro ‘SDIO_DEVICE’
95 | .vendor = (vend), .device = (dev)
| ^~~~
/root/rtw88/rtw8723ds.c:15:8: error: ‘SDIO_DEVICE_ID_REALTEK_RTW8723DS’ undeclared here (not in a function); did you mean ‘SDIO_DEVICE_ID_MEDIATEK_MT7663’?
15 | SDIO_DEVICE_ID_REALTEK_RTW8723DS),
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/usr/src/linux-headers-5.10.0-16-common/include/linux/mmc/sdio_func.h:95:31: note: in definition of macro ‘SDIO_DEVICE’
95 | .vendor = (vend), .device = (dev)
| ^~~
make[3]: *** [/usr/src/linux-headers-5.10.0-16-common/scripts/Makefile.build:291: /root/rtw88/rtw8723ds.o] Error 1
make[2]: *** [/usr/src/linux-headers-5.10.0-16-common/Makefile:1846: /root/rtw88] Error 2
make[1]: *** [/usr/src/linux-headers-5.10.0-16-common/Makefile:185: __sub-make] Error 2
make[1]: Leaving directory '/usr/src/linux-headers-5.10.0-16-arm64'
make: *** [Makefile:117: all] Error 2 |
|
Changing line #6 in |
|
Output for make -C /lib/modules/5.16.17-sun50iw9/build M=/root/rtw88 modules
make[1]: Entering directory '/usr/src/linux-headers-5.10.0-16-arm64'
make[1]: Leaving directory '/usr/src/linux-headers-5.10.0-16-arm64'
Install rtw88 SUCCESS |
|
Sorry that I missed that error. The latest kernels have the updated sdio_ids.h, but this repo needs to carry them as a separate file. Does it work? |
|
Do I have to do some extra steps to get the driver to work? I checked for the |
|
You do not need to blacklist anything. No kernel contains the SDIO driver. What does 'lsmod | grep rtw' show? |
|
Nothing, seems like the driver didn't start |
|
Ohh I see my mistake. I had issues installing the linux headers for my kernel and picked another version with the When running just |
|
That error means that the kernel headers are not installed. |
|
Is there a way to compile + install it when compiling the kernel? I did this with the |
|
I did a quick look, but that should work. |
|
Alright I managed to install the linux headers and build it on my SoC, but it doesn't seem to start: mangopi:/lib/modules/6.3.0-g58390c8ce1bd-dirty# find -name rtw88
./build/drivers/net/wireless/realtek/rtw88
./kernel/drivers/net/wireless/realtek/rtw88
mangopi:/lib/modules/6.3.0-g58390c8ce1bd-dirty# dmesg | grep rtw
mangopi:/lib/modules/6.3.0-g58390c8ce1bd-dirty# lsmod
Module Size Used by Not tainted
cfg80211 389120 0
rfkill 28672 1 cfg80211
ipv6 446464 18 [permanent]
mangopi:/lib/modules/6.3.0-g58390c8ce1bd-dirty# |
|
The SDIO device table in this driver contained device 0x024c, 0xD723, but the other driver also had 0x024c, 0xD724. I added the new one to the table and pushed a fix. Do another 'git pull' and rebuild. |
|
Hey! I rebuild it, and the output of the commands I executed above are still the same, but I tried to run Maybe it's because I'm running the mainline kernel, I'll try stable and report back. |
|
Okay that was my mistake when creating the kernel headers, I fixed it. Now, after running |
|
Do a 'sudo dmesh | grep renamed'. That will tell you the name of the device, which may not be wlan0. |
|
Hey, sorry for the late answer, I was busy during the weekend. I assume you mean At least when using the driver from this repository here ( |
|
Please do a reboot followed by the command 'lsmod|grep rtw'. Post the output. Next, run the dommand 'sudo dmesg -t > dmesg.txt' and attach dmesg.txt to this issue. |
|
I did add |
|
Your dmesg shows that the device is being recognized, but no indication that a driver is being attached. Knowing that, I rechecked the SDIO device table, and found that I had done that wrong. I just pushed a fix that I think is correct. Please pull and rebuild. Do the dmesg.txt thing again after you rebuild and reboot. |
|
We definitely gained a bit that time, but we are missing the firmware, which does not make any sense. That firmware is installed with a 'sudo make install'. Run the commands 'ls /lib/firmware' and /lib/firmware/rtw88' and post the output. |
|
I reported this problem upstream to the guys that wrote rtw8723ds.c in the following E-mail: Martin and Jernej, It took a bit of working through some problems, but the user now has the rtw8723ds loading and starting. The first problem other than the mechanics of building and installing the driver on his SoC was that there is a second SDIO vendor ID/device ID for his device, namely 0x024c:0xd724. As I am carrying a local copy of sdio_ids.h, that was relatively easy to fix. At the moment, when the device starts, the log shows the following: This problem is beyond my knowledge of SDIO. Thanks for any help you can give.I will let you know when they provide a fix or some test code. Larry |
|
Great thanks! |
|
Learning a lot is one of the goals. :) I heard back from the guy that wrote sdio.c. He said "This looks like an issue with the Allwinner SDIO controller. We can I added his patch to the code. Do another git pull and test. Thanks. |
|
Hey, I pulled the changes and compiled it again. Now, wlan0 manages to become ready, but after a bit, an error shows up. In the first boot I actually managed to do a |
|
It seems pretty random when this error shows up, I managed to do some more network related stuff after a reboot and in this try, it crashed 180 seconds after boot. |
|
Yes, we are close. I sent the BUG splat to the author of sdio.c. I will let you know when we are ready for another test. |
|
I have not heard back from the author as of this morning. I added a little code that should detect the problem and go on. Let me know what dmesg says now about this problem. |
|
There you go: |
|
Thanks - try again Long-distance debugging is so much fun. BTW, As I recall, you ssh into the SoC. Any chance I can ssh into that host? |
|
Hey, no I'm connecting over a serial console. The SoC only has a wifi interface and when I'm testing it, it's not really possible to use SSH ;) Also I'm having some issues opening a console over SSH at the moment, but scp for example work. I still need to fix this. I will try the new code later today and will report back. |
|
Still looks like the same bug :/ |
|
I am really lost on this problem. The strance thing is that the traceback shows skb_find_text just before skb_panic. The strange part is that skb_find_text if only called from within net/sched/em_text.c, and some of the netfilter code. The latter is part of the firewall code. The former is used for QoS scheduling. What does the command 'lsmod | grep sch' show? If that is blank, could you turn off the firewall to see if that makes any difference? Let me know what you find. The person that wrote rtw8723ds.c has just taken delivery of an SoC like yours, and hopes to get it running this weekend. |
|
One of the developers wrote to tell me of a section in the vendor driver where a packet is dropped when there is a CRC error. I added this to this driver. Pllease pull and test again. Thanks. |
|
Hey! I pulled the changes and tested it again. Now it shows |
|
It fails scanning for networks. I tried running |
|
We at least learned why the skb overrun happened. We are now testing whether aggregation is the problem. Do a git pull and remake. Thanks for testing. |
|
No problem, I'm happy to help! It still shows the same warnings. |
|
I just pushed new code that will report the parameters from the "Invalid RX packet size!" messages so that we can see what is wrong. Again, thanks for testing. |
|
I think you made a mistake when displaying the |
|
Thanks for fixing my mistakes. The sdio.c gurus have suggested another change, which I have pushed along with the fix you found. Please try. |
|
There is another fix this morning that made one system work. Do a pull and try again. |
|
Hey, I just compiled it again: |
|
That is disappointing. Just to verify, you do have commit d708f01496a3 ("rtw88: Correctly handle RX operations"). I just removed some debug stuff and pushed again. Pull and try. Thanks. |
|
Yes I just verified it, I'm on |
|
Now you should be on 7da3cc1238f543eacd4c1a7d44f7b770f4d2a448. |
|
Now the kernel log gets spammed with warnings: |
|
I asked for a copy of sdio.c that works and pushed it. I must have screwed this one up somewhere. At least he did not report any warnings in his logs. Rinse and repeat! |
|
It works!!! 🎉 I was able to do Here is the kernel log, if you still need it: Thank you very much!! |
|
That is what we like - a clean dmesg. I am going to close this issue. If something else comes up, open a new one under rtw88. |
Hey, I'm trying to include this driver in my kernel configuration and I'm failing to get it to compile properly. I appreciate any help! <3
Environment
Kernel version I am trying to build:
6.1.26Target arch:
arm64Host OS:
Debian GNU/Linux 11 (bullseye)Kernel setup
6.1.26kernel:git clone --depth 1 --branch linux-6.1.y https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.gitgit clone --depth 1 https://github.com/lwfinger/rtl8723ds drivers/net/wireless/realtek/rtl8723dsdrivers/net/wireless/realtek/rtl8723ds/Kconfigand deleted the hypens around--help--drivers/net/wireless/realtek/Kconfigfile and insertedsource "drivers/net/wireless/realtek/rtl8723ds/Kconfig"drivers/net/wireless/realtek/Makefilefile and insertedobj-$(CONFIG_RTL8723DS) += rtl8723ds/Kernel config
I used the default config with
make ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- defconfigand addedCONFIG_RTL8723DS=yto include this driver.Compiling
This resulted in the following error:
The text was updated successfully, but these errors were encountered: