Jump to content

Nanopi M4v2 - crash/freeze


Dyfcom

Recommended Posts

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!

 

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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 :thumbup:

 

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 B)

 

I hope the Nanopi is stable now!

Link to comment
Share on other sites

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!

Link to comment
Share on other sites

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.

 

grafik.png.d525ab8c66bab163e56840c425a6a9e9.png

Link to comment
Share on other sites

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.

 

grafik.png.d525ab8c66bab163e56840c425a6a9e9.png

 

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 :unsure:

 

But I don't know why not more people noticed this problem...

Link to comment
Share on other sites

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 by piter75
the experiment failed - I observed memory issues again with tweaked configuration.
Link to comment
Share on other sites

Guest
This topic is now closed to further replies.
×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines