raschid Posted June 24, 2017 Posted June 24, 2017 BTW, this is what the log shows when connecting to an AP in the pathed 4.11 version based on fifteenhex' driver: [ 1066.119194] wlan0: authenticate with 80:1f:02:d0:14:52 [ 1066.119308] ieee80211 phy0: ignore IEEE80211_CONF_CHANGE_MONITOR (0)IEEE80211_CONF_CHANGE_IDLE (1) [ 1066.119797] wlan0: send auth to 80:1f:02:d0:14:52 (try 1/3) [ 1066.132610] wlan0: authenticated [ 1066.139306] wlan0: associate with 80:1f:02:d0:14:52 (try 1/3) [ 1066.143502] wlan0: RX AssocResp from 80:1f:02:d0:14:52 (capab=0x411 status=0 aid=2) [ 1066.143616] ieee80211 phy0: vif 0, configuring tx [ 1066.144216] ieee80211 phy0: vif 0, configuring tx [ 1066.145063] ieee80211 phy0: vif 0, configuring tx [ 1066.145649] ieee80211 phy0: vif 0, configuring tx [ 1066.149919] wlan0: associated [ 1066.150199] IPv6: ADDRCONF(NETDEV_CHANGE): wlan0: link becomes ready [ 1066.233457] Unable to handle kernel NULL pointer dereference at virtual address 0000000c [ 1066.241694] pgd = c0004000 [ 1066.244420] [0000000c] *pgd=00000000 [ 1066.248019] Internal error: Oops: 5 [#1] SMP THUMB2 [ 1066.252902] Modules linked in: aes_arm(+) ccm xradio_wlan sun8i_codec_analog mac80211 snd_soc_core snd_pcm_dmaengine snd_pcm cfg80211 rfkill sun8i_ths thermal_sys uio_pdrv_genirq uio usb_f_acm u_serial g_serial libcomposite [ 1066.272814] CPU: 0 PID: 2543 Comm: cryptomgr_test Not tainted 4.11.3-sun8i #21 [ 1066.280041] Hardware name: Allwinner sun8i Family [ 1066.284754] task: cebf0e80 task.stack: c82be000 [ 1066.289309] PC is at crypto_remove_spawns+0x7c/0x154 [ 1066.294283] LR is at 0xc82bff28 [ 1066.297437] pc : [<c042da00>] lr : [<c82bff28>] psr: a00b0033 sp : c82bff18 ip : c0b24440 fp : cdc94a28 [ 1066.308924] r10: 00000401 r9 : c82bff50 r8 : c0b24448 [ 1066.314159] r7 : c82bff18 r6 : cd800e88 r5 : cd800fc0 r4 : 00000000 [ 1066.320696] r3 : cdc94e88 r2 : bf9ba000 r1 : 00000000 r0 : c82bff20 [ 1066.327234] Flags: NzCv IRQs on FIQs on Mode SVC_32 ISA Thumb Segment none [ 1066.334552] Control: 50c5387d Table: 4829c06a DAC: 00000051 [ 1066.340306] Process cryptomgr_test (pid: 2543, stack limit = 0xc82be210) [ 1066.347015] Stack: (0xc82bff18 to 0xc82c0000) [ 1066.351384] ff00: cd5163c0 cd5163c0 [ 1066.359579] ff20: cdc94fd8 cd800fc0 c82bff28 c82bff28 cdc94200 c0b24440 c0b23158 00000401 [ 1066.367810] ff40: bf9ba028 bf9ba000 bf9ba068 c042dcab c82bff50 c82bff50 00000000 cd813540 [ 1066.376035] ff60: 00000000 c9c8e300 c82be000 cd813540 c04321b1 c828fd08 ceb6f89c c04321bb [ 1066.384261] ff80: ceb6f880 c012c7bb ffffffff c9c8e300 c012c6e1 00000000 00000000 00000000 [ 1066.392486] ffa0: 00000000 00000000 00000000 c0105f31 00000000 00000000 00000000 00000000 [ 1066.400710] ffc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 [ 1066.408934] ffe0: 00000000 00000000 00000000 00000000 00000013 00000000 ffffffff ffffffff [ 1066.417177] [<c042da00>] (crypto_remove_spawns) from [<c042dcab>] (crypto_alg_tested+0xe7/0x13c) [ 1066.426021] [<c042dcab>] (crypto_alg_tested) from [<c04321bb>] (cryptomgr_test+0xb/0x18) [ 1066.434169] [<c04321bb>] (cryptomgr_test) from [<c012c7bb>] (kthread+0xdb/0x100) [ 1066.441625] [<c012c7bb>] (kthread) from [<c0105f31>] (ret_from_fork+0x11/0x20) [ 1066.448897] Code: 681c 42a3 d013 681c (68e3) 459c [ 1066.453970] ---[ end trace 23a7480ff1a672b0 ]--- Assiciation to an AP finishes successfully, but then the driver seems to fail returning a NULL pointer: [ 1066.149919] wlan0: associated [ 1066.150199] IPv6: ADDRCONF(NETDEV_CHANGE): wlan0: link becomes ready [ 1066.233457] Unable to handle kernel NULL pointer dereference at virtual address 0000000c [ 1066.241694] pgd = c0004000 [ 1066.244420] [0000000c] *pgd=00000000 [ 1066.248019] Internal error: Oops: 5 [#1] SMP THUMB2 [ 1066.252902] Modules linked in: aes_arm(+) ccm xradio_wlan sun8i_codec_analog mac80211 snd_soc_core snd_pcm_dmaengine snd_pcm cfg80211 rfkill sun8i_ths thermal_sys uio_pdrv_genirq uio usb_f_acm u_serial g_serial libcomposite
zador.blood.stained Posted June 24, 2017 Posted June 24, 2017 25 minutes ago, raschid said: [ 1066.289309] PC is at crypto_remove_spawns+0x7c/0x154 When did you build this kernel and with what build script version?
raschid Posted June 24, 2017 Posted June 24, 2017 13 minutes ago, zador.blood.stained said: When did you build this kernel and with what build script version? The file date for the kernel is the 3rd of June. Not sure about the script version, but i guess it was current at that time. Why?
zador.blood.stained Posted June 24, 2017 Posted June 24, 2017 1 minute ago, raschid said: The file date for the kernel is the 3rd of June. Not sure about the script version, but i guess it was current at that time. Why? This type of crashes (aes-arm related) should have been fixed yesterday by this commit, so I would suggest to rebuild the kernel.
raschid Posted June 25, 2017 Posted June 25, 2017 16 hours ago, zador.blood.stained said: This type of crashes (aes-arm related) should have been fixed yesterday by this commit, so I would suggest to rebuild the kernel. Nice - that fixed it. [ 74.030917] systemd[1]: apt-daily.timer: Adding 1h 13min 16.687045s random time. [ 177.557914] xradio_wlan mmc1:0001:1: missed interrupt [ 236.371472] IPv6: ADDRCONF(NETDEV_UP): wlan0: link is not ready [ 283.880879] wlan0: authenticate with 80:1f:02:d0:__:__ [ 283.880976] ieee80211 phy0: ignore IEEE80211_CONF_CHANGE_MONITOR (0)IEEE80211_CONF_CHANGE_IDLE (1) [ 283.883019] wlan0: send auth to 80:1f:02:d0:__:__ (try 1/3) [ 283.897534] wlan0: authenticated [ 283.907946] wlan0: associate with 80:1f:02:d0:__:__ (try 1/3) [ 283.911220] wlan0: RX AssocResp from 80:1f:02:d0:__:__ (capab=0x411 status=0 aid=5) [ 283.911463] ieee80211 phy0: vif 0, configuring tx [ 283.911941] ieee80211 phy0: vif 0, configuring tx [ 283.912366] ieee80211 phy0: vif 0, configuring tx [ 283.912788] ieee80211 phy0: vif 0, configuring tx [ 283.915753] wlan0: associated [ 283.915973] IPv6: ADDRCONF(NETDEV_CHANGE): wlan0: link becomes ready [ 284.018331] ieee80211 phy0: CCMP_PAIRWISE keylen=16! No more "xradio_wlan mmc1:0001:1: received frame has no key status" message spamming the logs. Great. Thx, Zador 1
martinayotte Posted June 25, 2017 Posted June 25, 2017 18 hours ago, zador.blood.stained said: This type of crashes (aes-arm related) should have been fixed yesterday by this commit, so I would suggest to rebuild the kernel. Yes, thanks Zador to have figured out ! I've tested it on my side too, and right, it fix the xradio perfectly ! Maybe we should re-enabled it in the nightlies ?
raschid Posted June 25, 2017 Posted June 25, 2017 1 minute ago, martinayotte said: Yes, thanks Zador to have figured out ! I've tested it on my side too, and right, it fix the xradio perfectly ! Maybe we should re-enabled it in the nightlies ? Yep (in my humble opinion)
zador.blood.stained Posted June 25, 2017 Posted June 25, 2017 2 minutes ago, martinayotte said: Yes, thanks Zador to have figured out ! I've tested it on my side too, and right, it fix the xradio perfectly ! It just fixes it barely enough to work without crashing (and fix is not related to the xradio driver, it's a kernel-wide fix) 2 minutes ago, martinayotte said: Maybe we should re-enabled it in the nightlies ? My opinion here would be "definitely no", we had enough crap about this driver and none of that was fixed (packet losses, open AP connection, virtual interfaces, P2P mode, etc.) 1
martinayotte Posted June 25, 2017 Posted June 25, 2017 1 minute ago, zador.blood.stained said: My opinion here would be "definitely no" Ok, then ... I will keep it as private build...
zador.blood.stained Posted June 25, 2017 Posted June 25, 2017 6 minutes ago, martinayotte said: Ok, then ... I will keep it as private build... I mean it still is available as an out of tree module, but it requires some effort to enable and shifts responsibility for the module quality from us to the repository owner.
raschid Posted June 25, 2017 Posted June 25, 2017 I am fully aware that that there have been issues in the past with some peoples expectations regarding this driver. But this very thread shows that a significant fraction of users seem to be fine with its limited function and performance. The download page for the OPi Zero already provides ample warning regarding the "module quality". 1
ldiaz Posted June 25, 2017 Posted June 25, 2017 That's great news at least this solution will be a solution from some users. The driver is crapy but at least permit transmitting wireless which is a must in some applications. I understand to not include the solution in standard images. There is , however, the option to include as an option in the build tool for those that assume the risk of this crashy driver. As far as I understood to make it work it is needed to do following steps: build with newest patches that solve (aes-arm) crashes. Use correct fifteenhex' driver compatible with 4.11. I think this can be done changing the current add-xradio-wireless-driver.patch.disabled with the correct version. Still if it is remain as disabled it could be enabled manually by the user and compile the correct version. Use XRADIO_* kernel settings to activate the configuration and compilation. By default they can be commented (unset) but the user can remove the contents and get the driver compiled installed in custom builds. Provide a suitable DTS that inform the kernel that the xr819 is present with valid params. Current build system do not do configure it. Can this be done with an overlay? If yes then it can be included in the overlay section of the build script so it get compiled and can be activated by the user in armbianEnv.txt. If this approach is possible we can find a compromise between not supporting the driver in standard images but easy for custom compilation activation. What do you think? Regards,
zador.blood.stained Posted June 25, 2017 Posted June 25, 2017 1 minute ago, ldiaz said: There is , however, the option to include as an option in the build tool for those that assume the risk of this crashy driver. And this is possible already using the userpatches functionality. @martinayotte or anybody else can update existing xradio patch while leaving it disabled, and developers who build their own kernels will have a relatively easy way to activate it by copying or symlinking this patch and using KERNEL_CONFIGURE=yes to change the kernel config.
ldiaz Posted June 25, 2017 Posted June 25, 2017 Quote And this is possible already using the userpatches functionality. @martinayotte or anybody else can update existing xradio patch while leaving it disabled, and developers who build their own kernels will have a relatively easy way to activate it by copying or symlinking this patch and using KERNEL_CONFIGURE=yes to change the kernel config. Yes that would cover points 1,2,3 of my proposal. Would it be possible to implement the 4 point (DTS part) with an overlay?
raschid Posted June 25, 2017 Posted June 25, 2017 the DTS file can be patched with the same userpatch in one patch.
ldiaz Posted June 25, 2017 Posted June 25, 2017 Quote the DTS file can be patched with the same userpatch in one patch. That would be even better. do you think @martinayotte will be able to do it from his private build? 1
raschid Posted June 25, 2017 Posted June 25, 2017 I hope so. You could try my userpatch until he does: https://drive.google.com/file/d/0B47UwibE8mfvRXYzR0p4SGJ4Vnc/view?usp=sharing Copy it to userpatches/kernel/sun8i-dev/ Don't forget to set KERNEL_CONFIGURE="yes" and set XRADIO to manual (m). 1
martinayotte Posted June 25, 2017 Posted June 25, 2017 For the changes to DTS, maybe I can look to append them directly into the add-xradio-wireless-driver.patch.disabled when I will get chance.
raschid Posted June 26, 2017 Posted June 26, 2017 8 hours ago, martinayotte said: For the changes to DTS, maybe I can look to append them directly into the add-xradio-wireless-driver.patch.disabled when I will get chance. @martinayotte Would you update the actual driver code to your build as well? It seems the driver code in the current add-xradio-wireless-driver.patch.disabled is still pre 4.11.
raschid Posted June 26, 2017 Posted June 26, 2017 Quick speedtest using speedtest-cli (I know, I know ...): Test 1 - 1,5m from AP, no walls Testing download speed........................................ Download: 13.20 Mbit/s Testing upload speed.................................................. Upload: 5.42 Mbit/s Upload is limited by the ISP connection, dowload isn't (100Mbit/s download, 6Mbit/s upload). Repeats show similar results. No/few error messages (xradio_wlan mmc1:0001:1: missed interrupt) Test 2 - 8m from AP, 1 wall Testing download speed........................................ Download: 1.77 Mbit/s Testing upload speed.................................................. Upload: 0.88 Mbit/s fairly terrible - no errors.
ldiaz Posted June 26, 2017 Posted June 26, 2017 I confirm that raschid patch worked also for me. It include botth DTS mods for opizero and the patched driver for 4.11. May thanks for the success. I will some perfomance test also. As regards distance to AP I think this could be improved with a better antenna. The one that come with the zero seems really low quality, 1
raschid Posted June 26, 2017 Posted June 26, 2017 Some quick results on packet loss measured via tcpdump: Medium traffic for 60 seconds (using tcpdump via ssh, i.e. tcpdump measuring (and driving) its own console output): 65149 packets captured 65198 packets received by filter 46 packets dropped by kernel negligible packet loss on kernel level. Full blast with speedtest-cli running in parallel to the above scenario: 111886 packets captured 113448 packets received by filter 1562 packets dropped by kernel less than 2% packet loss on kernel level. At least in this scenario the driver seems to be quite robust.
raschid Posted June 26, 2017 Posted June 26, 2017 8 hours ago, raschid said: Test 2 - 8m from AP, 1 wall Testing download speed........................................ Download: 1.77 Mbit/s Testing upload speed.................................................. Upload: 0.88 Mbit/s fairly terrible - no errors. Repeated this test with a sligtly different position (still ca. 8m, 1 Wall): Testing download speed........................................ Download: 8.67 Mbit/s Testing upload speed.................................................. Upload: 5.49 Mbit/s much better and probably more realistic ... one more Test: EDIT: removed third test due to errors in the test setup, sorry.
kutysam Posted June 26, 2017 Posted June 26, 2017 just a note, if you do a ping test to lets say 8.8.8.8, it will be VERY erratic, like 300ms, 200ms, 600ms,200ms etc. but if u do a ping test after sudo ping -s 1 -i 0.2 <orangePiWifiIp> you will see 1ms 1ms 2ms 3ms 1ms... etc. the xradio needs 'constant' connectivity to have a 'smooth' output i realize.
kutysam Posted June 26, 2017 Posted June 26, 2017 @raschid is there anyway to make this work without building a new kernel ? As in, with the current nightly, can i add in something to make the wireless work?
raschid Posted June 26, 2017 Posted June 26, 2017 23 minutes ago, kutysam said: @raschid is there anyway to make this work without building a new kernel ? As in, with the current nightly, can i add in something to make the wireless work? Sorry @kutysam, but I not think that this is possible ... unfortunately
martinayotte Posted June 26, 2017 Posted June 26, 2017 6 hours ago, raschid said: Would you update the actual driver code to your build as well? It seems the driver code in the current add-xradio-wireless-driver.patch.disabled is still pre 4.11. No needs, as I've done the changes already almost 2 months ago to match 4.11 API.
raschid Posted June 26, 2017 Posted June 26, 2017 3 hours ago, martinayotte said: No needs, as I've done the changes already almost 2 months ago to match 4.11 API. Thank you, @martinayotte. Hmm, if I rename add-xradio-wireless-driver.patch.disabled to -xradio-wireless-driver.patch (and move it to userpatches/kernel/sun8i-dev/) I get fatal compiler errors: drivers/net/wireless/xradio/bh.c: In function ‘xradio_register_bh’: drivers/net/wireless/xradio/bh.c:46:9: error: variable ‘param’ has initializer but incomplete type struct sched_param param = { .sched_priority = 1 }; ^~~~~~~~~~~ drivers/net/wireless/xradio/bh.c:46:32: error: ‘struct sched_param’ has no member named ‘sched_priority’ struct sched_param param = { .sched_priority = 1 }; ^~~~~~~~~~~~~~ drivers/net/wireless/xradio/bh.c:46:49: warning: excess elements in struct initializer struct sched_param param = { .sched_priority = 1 }; ^ drivers/net/wireless/xradio/bh.c:46:49: note: (near initialization for ‘param’) drivers/net/wireless/xradio/bh.c:46:21: error: storage size of ‘param’ isn’t known struct sched_param param = { .sched_priority = 1 }; ^~~~~ drivers/net/wireless/xradio/bh.c:46:21: warning: unused variable ‘param’ [-Wunused-variable] scripts/Makefile.build:294: recipe for target 'drivers/net/wireless/xradio/bh.o' failed make[4]: *** [drivers/net/wireless/xradio/bh.o] Error 1 scripts/Makefile.build:553: recipe for target 'drivers/net/wireless/xradio' failed make[3]: *** [drivers/net/wireless/xradio] Error 2 scripts/Makefile.build:553: recipe for target 'drivers/net/wireless' failed make[2]: *** [drivers/net/wireless] Error 2 scripts/Makefile.build:553: recipe for target 'drivers/net' failed make[1]: *** [drivers/net] Error 2 make[1]: *** Waiting for unfinished jobs.... The diff used by the above patch appears pre 4.11. Am I missing something here?
martinayotte Posted June 26, 2017 Posted June 26, 2017 Oh ! You're right ! Back in May, when I've done the job, and when we decided to remove that support, I've never committed the patch fix, it is sitting on my tree : diff lib/patch/kernel/sun8i-dev/add-xradio-wireless-driver.patch.disabled lib/patch/kernel/sun8i-dev/add-xradio-wireless-driver.patch 1902c1902 < @@ -0,0 +1,880 @@ --- > @@ -0,0 +1,884 @@ 1922a1923,1926 > +struct sched_param { > + int sched_priority; > +}; > + 1948d1951 < + struct sched_param param = { .sched_priority = 1 }; 1963a1967 > + struct sched_param param = { .sched_priority = 1 }; 12076c12080 < @@ -0,0 +1,266 @@ --- > @@ -0,0 +1,267 @@ 12092a12097 > +#include <linux/module.h> 13601c13606 < + ieee80211_cqm_rssi_notify(priv->vif, cqm_evt, --- > + ieee80211_cqm_rssi_notify(priv->vif, cqm_evt, rcpiRssi, I will probably commit it soon, but leaving it disabled ...
Recommended Posts