piter75

Members
  • Content Count

    79
  • Joined

  • Last visited

About piter75

  • Rank
    Advanced Member

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. This is good but let's see if it keeps being stable. I still think that we are covering up for some other issue with this cpu frequency governor behaviour change
  2. These are all interesting finds, especially the impact of "conservative" governor. You may have just nailed it. I am eagerly looking forward for your stability results after longer runtime period. We cannot rule out the fact that the batch of cpus that got into M4V2 is simply of a bit worse bin and they cannot cope well with either 2GHz (big) or 1.5GHz (LiTTLE). It will need some more testing but if it is stable then we could probably disable the overclocking and provide an overlay for everyone who wants to verify their luck at the cpu lottery ;-) To try current kernel with 2.0/1.5 disabled one can build the image from this branch: https://github.com/armbian/build/tree/rk3399-disable-overclocking or download precompiled minimal buster image built from it: https://drive.google.com/open?id=1vgG5krvkhpEnm1oPmvQSvmuoG_hvLd9-
  3. @Matthias the original issue with tx_delay/rx_delay (as tested with iperf) was fixed in all kernels back then. The issue with tx programmable buffer length that exhibited itself with Samba is fixed only in 5.x for now.
  4. Oh... I somehow fixed my mind on the fact that it was working properly with 4.4 and fixed it only in "current" and "dev". I will verify it with 4.4 and try to fix if needed.
  5. Thanks for verifying. Now we have one less variable in this equation. Would you be able to spare some more time and test the same scenario with 5.x on NanoPi M4?
  6. Could you possibly test it with 4.x on M4v2?
  7. Did you build the kernel yourself? I have committed a fix (https://github.com/armbian/build/commit/8c93385a84e2c8847ad5cf03684bee9c58596bf7) to the build system a few days ago. It should fix issues with the most common MTU of 1500. It will be build into some future kernel / image build.
  8. Network issues are solved upstream. eMMC tweak for your board is not in the build system yet. I will prepare it soon and give you a shout.
  9. These are messages from Dynamic Memory Controller. FriendlyARM decided to delete some OPP points for it from device tree. Maybe it was causing some stability issues. Should be harmless but it's a pity that it pollutes logs though.
  10. The issue is fixed in v5.4.11 - I removed the patch from the build system for future builds.
  11. I have taken another route with this PR. I shortened the TX programmable buffer length on all rk3399 boards as all are plagued with the same issue. With this change the transfers should be stable with most used MTU of 1500 but hardware offloading could still be enabled. Higher MTUs would require further shortening of the PBL. I must admit that I suspect some timing issues with RAM on M4V2 as I also, sometimes - not often, experience kernel panics with my dev unit. The other one that is a server with NVMe hat is running solid stable but it has a different u-boot configuration. I will definitely look into this issue.
  12. See my post regarding Armbian for Rock Pi S on Radxa's forum. Since then: kernel was bumped to 4.4.207 wifi is supported Bluetooth does not work (may be quite easy to fix) and audio features are not tested. I use it as low power consumption server for MQTT / zigbee2mqtt / homebridge combo and it going on for weeks. Preliminary support for rk3308 is coming to mainline in 5.5 and for RockPiS probably in 5.6. I will probably prepare a "dev" kernel with one of 5.5 RCs soon.
  13. Add loglevel=7 to kernel cmdline and you should see more output on the console
  14. @Matthias can you repeat your test with samba after applying the following command: sudo ethtool -K eth0 tx off rx off I remember discovering dying network connection on my Rock Pi 4 and finding this issue: https://github.com/MichaIng/DietPi/issues/2028 After that I started adding the above command to a script in /etc/network/if-up.d/ on every install with ansible and had no issues anymore. Today I tested samba share on Nano Pi M4V2 with clean image (kernel 5.4.8). I successfully sent 8GiB file to a share but the transfer died after 1.7GiB when downloading from the share. I disabled offloading with the above command and successfully downloaded the whole file.
  15. Totally agree. This is the only way to get help in this case. This crossed my mind before and I think it is a good idea. We already have it in place for Rock Pi 4b (it was implemented before we had Rock Pi 4a as a separate board) and it works well when used with the same u-boot version on eMMC and SD. @raidboy you can try to use Rock Pi 4b image which has priority set to SD and see if it works better in this scenario. Nothing is guaranteed as you are mixing stages of u-boots compiled with different configurations and even different code bases so... YMMV.