Nanopi M4v2 - crash/freeze

[Dyfcom]

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]

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]

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]

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.

[Dyfcom]

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]

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!

[Werner]

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]

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]

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.

[piter75]

The experiment failed for me so do not bother testing with the image 

[Dyfcom]

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