Dyfcom Posted May 3, 2020 Posted May 3, 2020 Hey, I am using a Nanopi M4v2 with a Satahat as server for openmediavault and plex. Since I got a lot of freezes/crashes (every 24-72h, the Nanopi lost the connection, and the green LED isn't blinking anymore) with "Armbian 20.02.7 buster current 5.4.28" on a SD-Card. I plugged a SSD in and used the nand-install script with a clean installed SD-Card. But this doesn't help, the problem is still there. The log got spamed with this: May 3 13:17:03 nanopi brcm_patchram_plus_rk3399[1338]: writing May 3 13:17:03 nanopi brcm_patchram_plus_rk3399[1338]: 01 4c fc ff 3d 01 22 00 00 0d 05 00 00 50 fb 31 May 3 13:17:03 nanopi brcm_patchram_plus_rk3399[1338]: 00 ff ff 00 00 0d 05 00 00 64 f9 31 00 ff ff 00 May 3 13:17:03 nanopi brcm_patchram_plus_rk3399[1338]: 00 0d 0a 00 00 78 fb 31 00 ff ff 00 00 0d 0a 00 May 3 13:17:03 nanopi brcm_patchram_plus_rk3399[1338]: 00 60 f9 31 00 ff ff 00 00 05 09 00 00 74 fb 31 May 3 13:17:03 nanopi brcm_patchram_plus_rk3399[1338]: 00 ff ff 00 00 05 09 00 00 4c f9 31 00 ff ff 00 May 3 13:17:03 nanopi brcm_patchram_plus_rk3399[1338]: 00 09 08 00 00 5c fb 31 00 ff ff 00 00 09 08 00 May 3 13:17:03 nanopi brcm_patchram_plus_rk3399[1338]: 00 44 f9 31 00 ff ff 00 00 09 09 00 00 54 fb 31 May 3 13:17:03 nanopi brcm_patchram_plus_rk3399[1338]: 00 ff ff 00 00 09 09 00 00 50 f9 31 00 ff ff 00 May 3 13:17:03 nanopi brcm_patchram_plus_rk3399[1338]: 00 0f 07 00 00 60 fb 31 00 ff ff 00 00 0f 07 00 May 3 13:17:03 nanopi brcm_patchram_plus_rk3399[1338]: 00 5c f9 31 00 ff ff 00 00 0e 09 00 00 6c fb 31 May 3 13:17:03 nanopi brcm_patchram_plus_rk3399[1338]: 00 ff ff 00 00 0e 09 00 00 24 01 60 00 ff 00 00 May 3 13:17:03 nanopi brcm_patchram_plus_rk3399[1338]: 00 65 00 00 00 34 01 60 00 ff 00 00 00 9b 00 00 May 3 13:17:03 nanopi brcm_patchram_plus_rk3399[1338]: 00 38 01 60 00 ff 00 00 00 65 00 00 00 48 01 60 May 3 13:17:03 nanopi brcm_patchram_plus_rk3399[1338]: 00 ff 00 00 00 9b 00 00 00 98 f8 31 00 ff ff 00 May 3 13:17:03 nanopi brcm_patchram_plus_rk3399[1338]: 00 d9 7f 00 00 9c f8 31 00 ff ff 00 00 34 33 00 May 3 13:17:03 nanopi brcm_patchram_plus_rk3399[1338]: 00 a0 f8 31 00 ff ff 00 00 a3 0f 00 00 a4 f8 31 May 3 13:17:03 nanopi brcm_patchram_plus_rk3399[1338]: 00 ff ff May 3 13:17:03 nanopi brcm_patchram_plus_rk3399[1338]: received 7 May 3 13:17:03 nanopi brcm_patchram_plus_rk3399[1338]: 04 0e 04 01 4c fc 00 and this: May 3 13:17:04 nanopi brcm_patchram_plus_rk3399[1338]: writing May 3 13:17:04 nanopi brcm_patchram_plus_rk3399[1338]: 01 4c fc 05 ba 62 0d 00 00 May 3 13:17:04 nanopi brcm_patchram_plus_rk3399[1338]: received 7 May 3 13:17:04 nanopi brcm_patchram_plus_rk3399[1338]: 04 0e 04 01 4c fc 00 after 10mins when this happens in the logs, the Nanopi lost his connection. Over armbian-config I created the logs here. I tested a clean armbian install on a brand-new SanDisk SD-Card, without any other installation before, but there was exactly the same problem, after 24-72h of running. Thanks for helping and greeting!
NicoD Posted May 3, 2020 Posted May 3, 2020 1 hour ago, Dyfcom said: I tested a clean armbian install on a brand-new SanDisk SD-Card, without any other installation before, but there was exactly the same problem, after 24-72h of running. Hi. Could you try the same with the legacy kernel instead of mainline? I think that one is more stable.
Dyfcom Posted May 3, 2020 Author Posted May 3, 2020 5 hours ago, NicoD said: Hi. Could you try the same with the legacy kernel instead of mainline? I think that one is more stable. I will try. Or trying the Bionic v5.4? Is the current version (v5.4) still in like a "beta"? Because there is a Kernel 5.6 listed under the downloads section.
piter75 Posted May 3, 2020 Posted May 3, 2020 30 minutes ago, Dyfcom said: I will try. Or trying the Bionic v5.4? Mainline kernel is known to be unstable for this board Legacy is the way to go for now if you want it stable. 1
Dyfcom Posted May 5, 2020 Author Posted May 5, 2020 On 5/3/2020 at 10:57 PM, piter75 said: Mainline kernel is known to be unstable for this board Legacy is the way to go for now if you want it stable. On 4.4 I can reboot, without hardreset The weird thing is, that under the 4.4 plex Videos only plays 1-5mins. So I tried emby and look, all my other plex problems are solved too I hope the Nanopi is stable now!
Dyfcom Posted May 7, 2020 Author Posted May 7, 2020 On 5/3/2020 at 4:47 PM, NicoD said: Hi. Could you try the same with the legacy kernel instead of mainline? I think that one is more stable. It is running. The log isn't full with Hex-code. Thank! 1
Werner Posted May 7, 2020 Posted May 7, 2020 Hm should the "supported" tag be removed from any kernel but 4.4 for now? Other kernels simply seem not to cut it at this time.
Dyfcom Posted May 7, 2020 Author Posted May 7, 2020 1 minute ago, Werner said: Hm should the "supported" tag be removed from any kernel but 4.4 for now? Other kernels simply seem not to cut it at this time. I can only talk about the server version (buster and bionic), the 5.4 kernel isn't working for that, because this happens random after 6-72h. I think a lot of people using the 5.4 as a Desktop. So there are turning the nanopi off, after their finished their todo-stuff and don't run in this problem. But supported is that sadly not But I don't know why not more people noticed this problem...
piter75 Posted May 10, 2020 Posted May 10, 2020 (edited) On 5/7/2020 at 5:47 PM, Dyfcom said: 5.4 kernel isn't working for that, because this happens random after 6-72h On 5/7/2020 at 5:47 PM, Dyfcom said: But I don't know why not more people noticed this problem There are some older threads where people noticed it too, myself included Would you like to participate in testing of a possible cure workaround for those issues? Here is the image build off the master with RAM settings tweaked a bit: https://drive.google.com/open?id=1H4K-1sBUttbeHZUaE_J-t-P5cjYiqPU7 If you want to build the image yourself you can use this branch of Armbian build system: https://github.com/armbian/build/tree/nanopi-m4v2-stability-fix I have mine restarted several times with those settings and I see no crashes on boot/reboot but it certainly needs some longer uptime testing to be deemed successful. Edited May 11, 2020 by piter75 the experiment failed - I observed memory issues again with tweaked configuration. 2
piter75 Posted May 11, 2020 Posted May 11, 2020 The experiment failed for me so do not bother testing with the image
Dyfcom Posted May 17, 2020 Author Posted May 17, 2020 On 5/11/2020 at 1:04 PM, piter75 said: The experiment failed for me so do not bother testing with the image That is frustrating. I will stay with the 4.4 Kernel
Recommended Posts