• Content Count

  • Joined

  • Last visited

  1. 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.
  2. 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 'Ar
  3. 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
  4. where do I need to disable this? Sent from my iPhone using Tapatalk
  5. 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 :-(
  6. great news. Did you have any success with the Gig eth issue?
  7. 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
  8. 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 :-(
  9. no, it's missing. But I found it under File systems > Network File Systems and selected the respective options :-)
  10. Hi Tony, I downloaded from git clone cd build ./ 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?
  11. 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 ( - 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?
  12. 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
  13. 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
  14. 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
  15. 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 :-(