[Fixed] Random pauses on S905 / X based hardware

[qstaq]

Hi All

 

I started playing with Armbian recently with some old S905 / S905X based TV Box devices I had lying around. Im working with a T95 S1, an A95X and an MXQ Pro and using the images from @balbes150 yandisk repo (thanks!)

 

Mostly everything seems to work fine except when transferring data to or from the devices (I havent tested WiFi or BT). My problem is that I cant use the ethernet to transfer any files. Network data transfers start as expected then get gradually slower and slower until after 10-15 seconds at which point data transfer stops and the device becomes unresponsive for a few minutes. Eventually I can SSH back into the device but any attempts at transferring data over the network fail as before. I have tried a USB ethernet adaptor which is normally used quite heavily on an RK3399 based device and works fine on the RK3399 armbian build but the results were the same which probably rules out a network driver issue. Anybody seen anything like this before?

 

One other thing I noticed was that all the devices had the same ethernet MAC addresses after flashing the @balbes150 images (00:15:18:01:81:31) which was strange and obviously caused a lot of network problems initially when they are all on the same LAN subnet. Is this hardcoded in the images or is it a quirk of S905 based hardware?

 

I get the same results on all 3 devices. I cant post an armbianmonitor -u because it hangs when uploading to xi.xo. Is there a way to get the local output and manually push it up to xi.xo?

 

Thanks

qstaq

[qstaq]

Update 1:

Done some more extensive testing using different network protocols. The problem only happens with encrypted data traffic. Non encrypted traffic actually flows normally and without any problems

 

HTTP, FTP, POP, IMAP all work fine. HTTPS, SCP, Samba, Wireguard, OpenVPN all fail.

 

SSH actually works fine surprisingly, maybe there is not enough data transferred in a typical SSH session to trigger the problem

 

Update 2:

armbianmonitor -u finally finished on one of the devices. It took almost 3 hours for armbianmonitor -u to complete:  http://ix.io/1Pa4

 

Update 3:

Tested an Odroid-C2 board (S905) and the problem is still there

 

Are there any known RNG issues on the S905 and its variants? This is starting to look like a lack of available entropy for the RNG system

[amirul]

If it is entropy, is haveged running? I found that on kernel >5 it needs --data-16 in /etc/default/haveged DAEMON_ARGS to run

[qstaq]

Fixed. Ill post the solution so if anyone else is having the same problem they can fix it

 

Basically haveged is not starting because it cant detect the CPU cache size and so cant feed itself all the variables it needs to start up

 

Looking through the armbianmonitor output I noticed that lscpu / cpuid is unable to detect the CPU cache sizes at all

#lscpu:
Architecture: aarch64
Byte Order: Little Endian CPU(s): 4
On-line CPU(s) list: 0-3 Thread(s) per core: 1 
Core(s) per socket: 4 
Socket(s): 1 
Vendor ID: ARM 
Model: 4 
Model name: Cortex-A53 
Stepping: r0p4 
CPU max MHz: 1512.0000
CPU min MHz: 100.0000
BogoMIPS: 48.00 
L1d cache: unknown size 
L1i cache: unknown size 
L2 cache: unknown size 
Flags: fp asimd evtstrm aes pmull sha1 sha2 crc32 cpuid

I think the S905 series has a 16kb L1 cache (correct me if Im wrong) so changing the haveged systemd unit to hard code a 16kb data size fixes the problem. Performance of encrypted traffic closely matches that of non encrypted traffic now

 

Fix is simple: just add --data=16 to the systemd unit arguments on the daemon start line

Modify /etc/default/haveged to include --data=16 on the DAEMON_ARGS line

# Configuration file for haveged
# Options to pass to haveged:
#   -w sets low entropy watermark (in bits)
DAEMON_ARGS="-w 1024 --data=16"

Edited fix as @amirul suggested the correct way to modify haveged args

[qstaq]

11 minutes ago, amirul said:

If it is entropy, is haveged running? I found that on kernel >5 it needs --data-16 in /etc/default/haveged DAEMON_ARGS to run

Yes it was all caused by lack of entropy. And yes your fix of modifying /etc/default/haveged is better than my fix of modifying the systemd unit file

 

Just set the DAEMON_ARGS="-w 1024 --data=16" in /etc/default/haveged for Kernels >5