Rockpi S Wifi Intermittent Stalls/Hanging

[lrose]

Armbianmonitor:

http://ix.io/2y5A

I have a v1.2 Rockpi S with 512MB of RAM, while using the latest Armbian Focal and Buster images (20.08.1 with kernel 4.4.y), I have been experiencing WIFI issues.  The device connects to the Access Point and maintains the connection but every minute or two the SSH connection hangs or freezes for several seconds and then comes back and prints everything that when on during the period it was not responsive.  When I used the images with the 5.8.y kernel, I did not experience the same issue.  In all cases wired ethernet (eth0) is not effected by the issue.  Continuously pinging a local system shows the below result.   Other WIFI devices on the same network do not experience this issue and I have tested it on two separate Rockpi S devices and 2 different Micro-SD cards.  The power supply is a 15W USB-C power supply and I do not suspect it to be the issue.  

 

$ ping 192.168.1.1
PING 192.168.1.1 (192.168.1.1) 56(84) bytes of data.
64 bytes from 192.168.1.1: icmp_seq=1 ttl=64 time=4.55 ms
64 bytes from 192.168.1.1: icmp_seq=2 ttl=64 time=4.18 ms
64 bytes from 192.168.1.1: icmp_seq=3 ttl=64 time=4.06 ms
64 bytes from 192.168.1.1: icmp_seq=4 ttl=64 time=4.70 ms
64 bytes from 192.168.1.1: icmp_seq=5 ttl=64 time=6.50 ms
64 bytes from 192.168.1.1: icmp_seq=6 ttl=64 time=3.42 ms
64 bytes from 192.168.1.1: icmp_seq=7 ttl=64 time=5.48 ms
64 bytes from 192.168.1.1: icmp_seq=8 ttl=64 time=6.84 ms
64 bytes from 192.168.1.1: icmp_seq=9 ttl=64 time=3.41 ms
64 bytes from 192.168.1.1: icmp_seq=10 ttl=64 time=4.34 ms
64 bytes from 192.168.1.1: icmp_seq=11 ttl=64 time=5.94 ms
64 bytes from 192.168.1.1: icmp_seq=12 ttl=64 time=6005 ms
64 bytes from 192.168.1.1: icmp_seq=13 ttl=64 time=4998 ms
64 bytes from 192.168.1.1: icmp_seq=14 ttl=64 time=3990 ms
64 bytes from 192.168.1.1: icmp_seq=15 ttl=64 time=2982 ms
64 bytes from 192.168.1.1: icmp_seq=16 ttl=64 time=1974 ms
64 bytes from 192.168.1.1: icmp_seq=17 ttl=64 time=966 ms
64 bytes from 192.168.1.1: icmp_seq=18 ttl=64 time=3.58 ms
64 bytes from 192.168.1.1: icmp_seq=19 ttl=64 time=3.26 ms
64 bytes from 192.168.1.1: icmp_seq=20 ttl=64 time=5.30 ms
 

Steps to reproduce:

1. Install Armbian Focal with Kernel 4.4.y (Armbian_20.08.1_Rockpi-s_focal_legacy_4.4.228_minimal.img.xz)

2. Complete the standard installation/setup using wired ethernet

3. Configure and enable WIFI access using armbian-config on the wlan0 interface (note: same issue occurs when p2p0 is used)

4. Disconnect the eth0 cable

5. SSH to Rockpi S using WIFI/wlan0

6. Execute ping command to another device on the local network

 

Not sure where else to look to see if I can identify the cause, any pointers would be appreciated.

 

[Igor]

2 hours ago, lrose said:

When I used the images with the 5.8.y kernel, I did not experience the same issue.

What prevents you to use this kernel? 4.4.y is significantly lower quality and will be dropped and will not be supported any more the moment most of the features are here. 4.4.y is a private kernel which was frozen that board specific features were developed. Wireless driver was probably never updated while in modern kernel it was many times. Also the whole wifi / network sub system is much more recent.

 

2 hours ago, lrose said:

I have been experiencing WIFI issues

I would assume you also observe this issue on Radxa stock builds? 

[piter75]

11 hours ago, lrose said:

Not sure where else to look to see if I can identify the cause, any pointers would be appreciated.

To tell you the truth I did not pay much attention to wifi when bringing ROCK Pi S to Armbian ;-)

One thing is certain - Radxa's image is plagued by the same issue.

 

Care to test this image?

It was built with Armbian's master and a bit fresher wifi driver.

For me it still has stalls but they are much shorter - ~1s vs ~6s currently.

[lrose]

Note: I am new the forums and there is a posting rate limit in place.  Currently it looks like I can only post once every 24 hours for the moment so my turn around is slow.

 

On 9/19/2020 at 5:28 AM, Igor said:

What prevents you to use this kernel?

 

There are a couple issues that I ran into with the newer kernel builds.

• The kernel 5.8.y builds do not reliably startup for me.  I have to push reset or unplug-plug-in a few times for it to boot.  I suspect but have not proven that it is this issue, I experience it right out of the box which may be different: https://forum.armbian.com/topic/15209-rockpi-s-crashing-at-startup-with-memory-errors/
• I intend to use the I2C interface and the overlays do not appear to be present in the newer kernel builds.  I can just manually add them, so not a big issue.
• The USB-A port is not recognizing the device I have connected to it.  The same device works just fine with the 4.4.y kernel builds.  Maybe there is an easy solution to this like the I2C overlay that I am just not aware of.
• Just an observation, the newer builds result in a 10C increase in idle CPU temperature (as reported in htop).  It does not appear to affect anything and it could just be a reporting issue.

 

On 9/19/2020 at 5:28 AM, Igor said:

I would assume you also observe this issue on Radxa stock builds?

 

Yes it is present in their Debian Buster build as well.

 

 

20 hours ago, piter75 said:

Care to test this image?

 

The image improved it quite a lot but like you said, the issue is still there.  With the test build the hang was only observable for about a second.

 

64 bytes from 192.168.1.1: icmp_seq=38 ttl=64 time=4.46 ms
64 bytes from 192.168.1.1: icmp_seq=39 ttl=64 time=6.54 ms
64 bytes from 192.168.1.1: icmp_seq=40 ttl=64 time=648 ms
64 bytes from 192.168.1.1: icmp_seq=41 ttl=64 time=3.74 ms
64 bytes from 192.168.1.1: icmp_seq=42 ttl=64 time=6.43 ms
...
64 bytes from 192.168.1.1: icmp_seq=163 ttl=64 time=6.54 ms
64 bytes from 192.168.1.1: icmp_seq=164 ttl=64 time=8.53 ms
64 bytes from 192.168.1.1: icmp_seq=165 ttl=64 time=1426 ms
64 bytes from 192.168.1.1: icmp_seq=166 ttl=64 time=418 ms
64 bytes from 192.168.1.1: icmp_seq=167 ttl=64 time=8.88 ms
...
64 bytes from 192.168.1.1: icmp_seq=226 ttl=64 time=4.66 ms
64 bytes from 192.168.1.1: icmp_seq=227 ttl=64 time=10.4 ms
64 bytes from 192.168.1.1: icmp_seq=228 ttl=64 time=1281 ms
64 bytes from 192.168.1.1: icmp_seq=229 ttl=64 time=274 ms
64 bytes from 192.168.1.1: icmp_seq=230 ttl=64 time=4.77 ms
64 bytes from 192.168.1.1: icmp_seq=231 ttl=64 time=6.73 ms
 

[Igor]

18 minutes ago, lrose said:

 Currently it looks like I can only post once every 24 hours for the moment so my turn around is slow.

 

It doesn't need to be faster. This is forum and we only provide best effort support - its better that is clear from the day one. We must limit speed of asking for help down since we simply do not have enough time/resources to deal with and you don't help  with the speed you are asking for assistance. Not near. We have to eat, sleep, deal with families, doing day jobs .... This is just one measure to protect regulars from pressure and stress from too aggressive newcomers ... I know it creates collateral damage but we didn't find a better way yet.

You probably understand this, but many people don't.

 

23 minutes ago, lrose said:

The kernel 5.8.y builds do not reliably startup for me.

 

But its the only kernel we / community is interested to keep together and support. Stock kernel is a base to pick thing out but nobody (except perhaps Radxa folks) will do anything serious there. And you will probably not complete a problem/project you have in one week. Not even in two ...

 

43 minutes ago, lrose said:

Yes it is present in their Debian Buster build as well.

 

Even they are unable to fix any serious problem. IMHO K5.8.y is your only long term go. More than @piter75 tried to do is (probably) not possible without deep R&D which is far outside "best effort" support.

 

24 minutes ago, lrose said:

I intend to use the I2C interface and the overlays do not appear to be present in the newer kernel builds.  I can just manually add them, so not a big issue.

 

Not complicated but again someone has to focus, do it and test. You could try and make it?

 

26 minutes ago, lrose said:

The USB-A port is not recognizing the device I have connected to it.  The same device works just fine with the 4.4.y kernel builds.  Maybe there is an easy solution to this like the I2C overlay that I am just not aware of.

Probably only not enabled in the device tree. Seems to be a minor problem.

 

57 minutes ago, lrose said:

Just an observation, the newer builds result in a 10C increase in idle CPU temperature (as reported in htop).  It does not appear to affect anything and it could just be a reporting issue.

That is the overall state of the modern kernel. Features works, but there are many small problems as such. I don't know if the calculation is wrong or there is a real issue. Not familiar with. Usually we are seeing improved thermal management in modern kernels.

[Werner]

2 hours ago, lrose said:

Currently it looks like I can only post once every 24 hours for the moment so my turn around is slow.

Limitation removed.

[lrose]

On 9/20/2020 at 12:45 PM, Igor said:

It doesn't need to be faster. This is forum and we only provide best effort support

 

I get it, any help is appreciated.   Just knowing that it is a known issue is a good start.

 

When I get some time, I will try digging into the new kernel a bit.  I don't have a lot of experience with Linux kernel and driver debugging so I have some learning to do, spend most my time either much higher or much lower in the stack.

 

[lrose]

On 9/20/2020 at 2:33 PM, Werner said:

Limitation removed.

 

Thanks!  Though it does not appear to let me post more then once a day still (which is fine but thought I'd let you know).