stefan.steffens

Thanks for the hint but funnily when I started from scratch with a new SD card I couldn't reproduce the crashes even under heave NFS load on GigEth :-) And this while 'kernel.hung_task_panic' was set to 1 Though I'm sure of not having changed anything (I'm using a step-by-step cook book to make sure I don't forget anything) compared to the first setup I'm now a happy user again as it's working.

TINKERBOARD FREEZES UNDER NFS LOAD Hi, I'm not sure where to post my issue but the Rockwell Eth issue which freezes my Tinkerboard under NFS load is back with the new images. So far I've been using the 'Armbian_5.59_Tinkerboard_Ubuntu_bionic_next_4.14.67_desktop' image upgraded via apt to the most recent version ( ARMBIAN 5.73 stable Ubuntu 18.04.2 LTS 4.19.20-rockchip). Based on prior advice I've added sudo ethtool -K eth0 tx off rx off to /etc/rc.local as the rk3328 is buggy on tx offloading Given the new images I've tried 'Armbian_5.75_Tinkerboard_Ubuntu_bionic_next_4.19.20_desktop' with the same entry in /etc/rc.local but as soon as I start multiple compiles via NFS the Tinkerboard freezes - just like the old image did prior to the ethtool modifications. Any idea how what might be wrong as I otherwise like some of the new features from the updated image?

Xalius' tip of disabling rx/tx offloading worked for me. For me ethtool -K eth0 tx off appeared to be sufficient, at least I haven't seen the Tinkerboard freezing on me during heave NFS load via GigEth

where do I need to disable this? Sent from my iPhone using Tapatalk

ok, given that it's only happening with the NFS client it may not be the ethernet driver at all. I now noticed multiple times that the network lights on the Tinkerboard continued to blink and RPi-Monitor did still refresh while my SSH sessions had frozen and I couldn't open any new connections. Weird behaviour and the only thing I know for sure is that heavy NFS load via GbE reproduces the freeze :-(

great news. Did you have any success with the Gig eth issue?

That would be great. The current kernel doesn't support SMB2 and later. I'll put in a pull request to get this changed as SMB1 is outdated

Some great news to share while testing continues: with the old kernel I easily could freeze the tinkerboard so that I couldn't connect anymore when putting high load on NFS mounted shares (100 Mbps and 1 Gbps). With this new kernel the NFS mount ist stable!! I've got two compiles running in parallel via SSH sessions via 100 Mbps for > 1h with CPU load > 3 @ 1800 Mhz with 70 C. That's impressive so I'm no longer worrying about CiFS Unfortunately using 1 Gbps it crashed again so still some work to be done :-(

no, it's missing. But I found it under File systems > Network File Systems and selected the respective options :-)

Hi Tony, I downloaded from git clone https://github.com/Tonymac32/build.git cd build ./compile.sh successfully generated 'Welcome to ARMBIAN 5.40 user-built Ubuntu 16.04.3 LTS 4.4.112-rockchip' which I hope is the correct one but after successful boot ran into the first problem of not being able to mount a CIFS (NFS mounts if you remember always crashed the system under load) and I'm getting the error message 'mount error: cifs filesystem not supported by the system' even though I loaded the CIFS-Utils. Is CIFS not included in the kernel?

I'd like to test too but can someone please tell me which option I'm supposed to pick: -> I select full OS build for flashing (as I don't know how to use the other option) -> don't change the kernel option -> select tinkerboard ?? Then I can chose between - Default (vendor provided / legacy) which I assume is not the correct option - Mainline (@kernel.org) - development version (which I assume to be the correct option) Can someone please confirm that the correct options so that I can test the new kernel?

I couldn't find any errors so in order to identify the root cause I switched my NFS v4 share to Samba v2 and can't get the Tinkerboard to crash anym. In other words it appears to be an issue with the NFS client and not the ethernet driver. Presumably not too many people are using NFS anymore so some issues survived. Sent from my iPhone using Tapatalk

in which logfile would I find such errors. I can still produce a freeze by working actively on NFS shares mounted via v4 from my synology NAS. Sent from my iPhone using Tapatalk

I can confirm that the mainline desktop build in combination with fast ethernet is more stable than the other builds but I did manage to crash it as well (after having been stable for almost 2 days). I've used my power meter to check that the currency did not increase significantly as the consumption which is usually in the 1-2 W range only increased to 5-6 W. Therefore I'm pretty sure that this isn't power supply related (using a 5.17V / 4A supply directly connected to the GPIO) but that there really is an instability related to the ethernet driver which can be more exposed by switching to gig eth and putting more parallel load on the NFS share.

Thanks for your support. I can confirm that my power supply provides 5.17V to the GPIO so I'm assuming this not to be a power issue. I could verify that heavy load using only the WLAN connection was stable but as soon as I added the ethernet connection and did compiles on the NFS share via that something frooze and the CPU got hot. I'm currently checking against the Mainline Desktop build to see if this should behave differently. Alternatively I could add a USB HDD to increase power consumption. This is really weird :-(

I've been testing with 4.4, 4.13 and 4.14 and almost same behaviour in all cases. On 4.13 I noticed that the Tinker isn't really crashing but stops responding, via Rpi-Monitor (which maintains connectivity longer than my ssh sessions) I can see the load increasing to > 5. I picked the Tinker as I was looking for a faster Raspi with more than 1 GB RAM as I want to consolidate my bitcoind and litecoin nodes. I've nfs mounted the blockchain from my NAS but fast eth would be sufficient for that. In addition I'm doing compiling and testing so nothing fancy...

yes, I did test the card (plus used several different ones). I've even ordered a replacement board but same results but now the punch-line: I've switched from Gig-Eth to the wireless and the board is stable. Is there a known issue with the ethernet driver that could be causing the instability

Yes, I connected both 5V pins as well as 3 ground pins via 0.75mm2 cable. To not void my warranty I didn't solder directly to the Tinkerboard but to a separate GPIO connector but I guess that shouldn't make a difference. Maybe it was just some static on the board which caused the instability as the Tinkerboard is now up for more than 30 hours and just repeatedly passed the stress test (stress -c 4 -t 60 ; sysbench --test=cpu --cpu-max-prime=20000 run --num-threads=4 ; 7z b ; timeout 120 minerd --benchmark). Tinker board crashed again but the behaviour is odd: I always log in via ssh from my PC and I've started to compile on an NFS mounted share and ran a htop in another session to track utilization. First the htop window froze and then the compile one. I could create additional SSH sessions but as soon as I typed commands they froze too. Since this crash I can easily crash it again by restarting the configure script on the NFS share and doing paralle htop or similiar in another session... Any idea what would be wrong here (or if there is a system log file that might point me to some clues)? PS: I'm running Armbian_5.35_Tinkerboard_Debian_stretch_default_4.4.102.img but had the same behaviour with Tinker OS

I'm using a 5V/3A power supply with a barrel connector that I've connected to the GPIO (both 5V pins as well as 3 ground pins via 0.75mm2 cable ). I'm still seeing the Tinkerboard stopping even in low workloads. Is there any way that I could check what's causing the issue? It's not the SDIO card and I'm only using the Network port. Sent from my iPhone using Tapatalk