Jump to content

Orange Pi Zero /4.11.0-sun8i/ wlan0 is gone

hpapagaj

By hpapagaj
in Allwinner sunxi

 Share

Recommended Posts

raschid

raschid

Posted
Posted

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

 

 

Link to comment
Share on other sites
raschid

raschid

Posted
Posted
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?

Link to comment
Share on other sites
raschid

raschid

Posted
Posted
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
Link to comment
Share on other sites
martinayotte

martinayotte

Posted
Posted
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 ?

 

Link to comment
Share on other sites
raschid

raschid

Posted
Posted
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)

Link to comment
Share on other sites
zador.blood.stained

zador.blood.stained

Posted
Posted
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
Link to comment
Share on other sites
raschid

raschid

Posted
Posted

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
Link to comment
Share on other sites
ldiaz

ldiaz

Posted
Posted

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:

  1. build with newest patches that solve (aes-arm) crashes.  :thumbup:
  2. 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.  
  3. 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.
  4. 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,

 

Link to comment
Share on other sites
zador.blood.stained

zador.blood.stained

Posted
Posted
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.

Link to comment
Share on other sites
ldiaz

ldiaz

Posted
Posted
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?

 

 

Link to comment
Share on other sites
raschid

raschid

Posted
Posted
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.

Link to comment
Share on other sites
raschid

raschid

Posted
Posted

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.

 

 

Link to comment
Share on other sites
ldiaz

ldiaz

Posted
Posted

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
Link to comment
Share on other sites
raschid

raschid

Posted
Posted

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.

Link to comment
Share on other sites
raschid

raschid

Posted
Posted
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.

Link to comment
Share on other sites
kutysam

kutysam

Posted
Posted

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.

Link to comment
Share on other sites
martinayotte

martinayotte

Posted
Posted
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.

Link to comment
Share on other sites
raschid

raschid

Posted
Posted
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?

Link to comment
Share on other sites
martinayotte

martinayotte

Posted
Posted

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 ...

Link to comment
Share on other sites
Guest
This topic is now closed to further replies.
 Share
Go to topic listing
×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines

  I accept