Lime2 mainline kernel with Debian 9 (stretch) becomes unresponsive (forced reboot required)

[denox]

Hi all,

 

I've been using the A20-Lime2 together with Armbian for about two years now and I love the effort that the developers and the community have put into this amazing product. Until not too long ago I was on Debian 8 (jessie) on the legacy kernel for webcam compatibility reasons (after having tried switching to mainline from time to time). With the release of Debian 9 I finally had everything that I was looking for in the mainline kernel so I decided to upgrade to Debian 9 and then switch to the mainline kernel.

 

I'm currently on ARMBIAN 5.38 stable with 4.14.15-sunxi and just had to force a reboot. The server I'm running is mainly a webserver, emailserver and home monitoring server (webcam). It also sends me things worth looking into periodically to email using logcheck. I'm no expert by any stretch of the imagination and consider myself more of a linux enthusiast with some basic knowledge and a lot of patience to research and experiment.

 

Since my upgrade to stretch and mainline kernel I've noticed sporadic freezes (which brings back memories of years ago with power supply, before changing my setup). I believe it may have something to do with mysql and/or php-fpm consuming a lot of memory. Logcheck warns me of a kernel panic from time to time and forces a restart of mysql. I actually have a daily restart of services script to avoid those services from clogging up too much memory. The freezes are unrecoverable (after waiting several days). While the kernel LED is still indicating activity, as is the LAN light, nothing is responding otherwise (not through debug UART, not through SSH or web or any other port, not through HDMI output [no signal]).

 

Prior to my upgrade, so while I was on legacy kernel and jessie, I had uptimes for about 6 months until I rebooted for a security update, and then another uptime of again 6 months before I decided to upgrade to stretch. It's why I don't believe it's related to my SD card, or power setup (USB OTG), or USB peripherals. As I'm writing this I am going to disable mysql and php services for a while to see if I still get the freeze or if my initial suspicion about memory hogs/kernel panics may be correct.

 

I've had these freezes occur several times, and after it occurred the last time I decided to do a system check-up, fix some minor things and run some diagnostics (based on a topic on providing debug output from tkaiser). You can see that initial debug output here: http://ix.io/F9A from 2/2/2018.

After freezing up again when I was reading RSS feeds (through tt-rss) on my own hosted webserver, I waited a couple of days and forced a reboot today. That debug output can be found here: http://ix.io/Fmj from 2/6/2018.

 

I noticed that both outputs have the same shutdown log (from 1/28 when I was on 4.13.16-sunxi), I'm not sure why that is, or if that will help or prevent troubleshooting assistance. 

 

Hopefully with this background and details someone will be able to spot something that looks off, or some explanation as I'm hopeful to identify and resolve the issue.

 

Update on 2/6 at 8:10 PM: after reading this post on (under)powering an SBC through Micro USB, I wanted to clarify that because of some mistakes that I had made about 2 years ago, my A20 LIME2 cannot be powered on through it's PWR jack. I somehow must have messed that up and as such I have been using USB OTG to power my board. Again, I don't think that this is the cause as I have a good power supply (had issues with that 2 years ago and bought a good one) and haven't had issues on the legacy kernel in the past 2 years, but it's always possible that the mainline kernel responds differently to power fluctuations (or causes them more so).

I'm running the armbian monitor submodule (since 9 AM this morning) that reports loads and DC-IN every 5 seconds to see what the latest reported data is upon crashing (if it crashes again now that I have turned off php/mysql/dovecot/postfix services). So far, in the past 11 hours, I'm seeing (of 7337 measures):

* CPU min: 528Mhz, max: 960Mhz, average: 915Mhz

* Load min: 0.06, max: 2.7, average: 0.49

* CPU load min: 2%, max: 100%, average: 18%

* CPU temp min: 41.4°C, max: 50.4°C, average: 43.8°C

* DC-IN min: 4.86V, max: 5V, average: 4.96V

[bananapinas]

I think I got the same or similar issue with a banana pi pro.

 

I used the board about a year with the latest bananian os without an issue, rock solid, uptimes up to 1 month (then planed shutdown for backup image of the sd card).

2.5" hdd attached through the SATA port.

Now I migrated to the latest 5.38 debian with mainline kernel .

Output of armbian-monitor -u here: http://ix.io/Fpe

 

Sporadic "freezes" - after just one hour runtime or (max for now) 14h. 

 

Symptoms:

- no hdmi output after turning on monitor.

- the green onboard led was used for "cpu" as trigger - led is just on so I assume 100% CPU usage.

- the blue onboard led was used for "mmc0" - zero activity then

- green led of eth0 blinks periodic

- yellow led of eth0 blinks sporadic 

- ssh no connect possible

 

After repowering and startup CPU shows high temperature after login (nearly 50°C).

 

System is used as nextcloud and samba server.  Installed packages mainly are

nginx, mariadb, php7/fpm, samba, default-jdk-headless, proftpd-basic, nfs-kernel-server

 

Every time while freezing there was no special user activity, at night or early in the morning.

At max one nextcloud windows client syncing, all other clients (user / hardware :)) sleeping or not at home.

 

So far I tried:

 

1)

Monitoring CPU load / processes with top every minute and write to a file on the sdcard.

Last full output @08:13:16 (yesterday)

 

top - 08:13:16 up  1:09,  2 users,  load average: 0,09, 0,14, 0,13
Tasks: 128 total,   1 running,  88 sleeping,   0 stopped,   0 zombie
%Cpu(s):  2,2 us,  6,1 sy,  0,1 ni, 91,3 id,  0,3 wa,  0,0 hi,  0,0 si,  0,0 st
KiB Mem :  1022524 total,   587192 free,   162788 used,   272544 buff/cache
KiB Swap:   131068 total,   131068 free,        0 used.   800756 avail Mem 

  PID USER      PR  NI    VIRT    RES    SHR S  %CPU %MEM     TIME+ COMMAND
 4499 root      20   0    8664   3092   2680 R  16,7  0,3   0:00.08 top
    1 root      20   0   25928   5484   3808 S   0,0  0,5   0:08.51 systemd
    2 root      20   0       0      0      0 S   0,0  0,0   0:00.01 kthreadd
    4 root       0 -20       0      0      0 I   0,0  0,0   0:00.00 kworker/0:+
    6 root       0 -20       0      0      0 I   0,0  0,0   0:00.00 mm_percpu_+
    7 root      20   0       0      0      0 S   0,0  0,0   0:00.16 ksoftirqd/0
.....

 

 

 

Next output 1 min later was interrupted while writing (?)

top - 08:14:17 up  1:10,  2 users,  load average: 0,08, 0,12, 0,13
Tasks: 128 total,   1 running,  88 sleeping,   0 stopped,   0 zombie
%Cpu(s):  2,2 us,  6,1 sy,  0,1 ni, 91,4 id,  0,3 wa,  0,0 hi,  0,0 si,  0,0 st
KiB Mem :  1022524 total,   587148 free,   162820 used,   272556 buff/cache
KiB Swap:   131068 total,   131068 free,        0 used.   800732 avail Mem 

  PID USER      PR  NI    VIRT    RES    SHR S  %CPU %MEM     TIME+ COMMAND
 4528 root      20   0    8664   3116   2704 R  20,0  0,3   0:00.07 top
 4481 root      20   0       0      0      0 I   5,0  0,0   0:02.14 kworker/1:0
    1 root      20   0   25928   5484   3808 S   0,0  0,5   0:08.52 systemd
    2 root      20   0       0      0      0 S   0,0  0,0   0:00.01 kthreadd
    4 root       0 -20       0      0      0 I   0,0  0,0   0:00.00 kworker/0:+
    6 root       0 -20       0      0      0 I   0,0  0,0   0:00.00 mm_percpu_+
    7 root      20   0       0      0      0 S   0,0  0,0   0:00.16 ksoftirqd/0
    8 root      20   0       0      0      0 I   0,0  0,0   0:00.69 rcu_sched
    9 root      20   0       0      0      0 I   0,0  0,0   0:00.00 rcu_bh
   10 root      rt   0       0      0      0 S   0,0  0,0   0:00.03 migration/0
   11 root      20   0       0      0      0 S   0,0  0,0   0:00.00 cpuhp/0
   12 root      20   0       0      0      0 S   0,0  0,0   0:00.00 cpuhp/1
   13 root      rt   0       0      0      0 S   0,0  0,0   0:00.03 migration/1
   14 root      20   0       0      0      0 S   0,0  0,0   0:00.46 ksoftirqd/1
   16 root       0 -20       0      0      0 I   0,0  0,0   0:00.00 kworker/1:+
   17 root      20   0       0      0      0 S   0,0  0,0   0:00.02 kdevtmpfs
   18 root       0 -20       0      0      0 I   0,0  0,0   0:00.00 netns
   21 root      20   0       0      0      0 S   0,0  0,0   0:00.00 oom_reaper
   22 root       0 -20       0      0      0 I   0,0  0,0   0:00.00 writeback
   23 root      20   0       0      0      0 S   0,0  0,0   0:00.00 kcompactd0
   24 root      25   5       0      0      0 S   0,0  0,   <-- here it ends

 

 

2)

Using as accesspoint:

I used the new armbian system as an access point (wlan0->eth0 bridge) with br0 in /etc/network/interfaces and hostapd.

I disabled this again - it was the only difference in usage between bananian and armbian. Did not help

 

3)

Power:

powering while using with bananian was done through the micro usb port, and the hdd was attached to the onboard power jack - worked without an issue.

I thought about improving this while migrating to armbian and changed to another power supply and powering the hdd directly from this and powering the board through the now unsed jack (which previously powered the hdd).

I changed this back to the old power supply and wiring scheme - result unknown, waiting to see if it happens again.

 

 

Note: other changes from bananian to armbian were:

- using another SD card - but same model (transcend ultimate 600x 8GB, as recommended here https://docs.armbian.com/User-Guide_Getting-Started/).

The card used for armbian was brand new. Maybe dd the armbian system to the previously used bananian sd card?

 

- 2.5" hdd upgraded from seagate 250GB to western digital 1TB - could this worth the change back?

 

Any ideas what to check / look for?

 

Any help very appreciated. I'm not  an expert in linux but got some basic skills and aim to learn

[chwe]

6 minutes ago, bananapinas said:

System is used as nextcloud and samba server.  Installed packages mainly are

nginx, mariadb, php7/fpm, samba, default-jdk-headless, proftpd-basic, nfs-kernel-server

Did you ever thought about using a OMV image? https://sourceforge.net/projects/openmediavault/files/Other armhf images/

@tkaiser spend quite a lot of time in optimization for such NAS use cases.  I think Nextcloud is no-longer supported by OMV but owncloud should be, but you've to read though their forum/documentation stuff to be sure...  

Not that I want to stop you from trying it on your own, but I like the provided OMV images.  

[bananapinas]

2 minutes ago, chwe said:

Did you ever thought about using a OMV image? https://sourceforge.net/projects/openmediavault/files/Other armhf images/

 

yes I tried it once before setting up my own solution about a year ago. I did not really like it then

It seemed slow and overloaded, and I prefer(ed) nextcloud over owncload. 

 

But both the old bananian and new armbian systems were/are working really fine, everything is ok - apart from the freezes...

 

[chwe]

1 minute ago, bananapinas said:

yes I tried it once before setting up my own solution about a year ago.

I expect that this changed a lot since @tkaiser is working on it.. It's based on armbian (not newest kernel, but a 'recent one'). And he did a lot to bring this up smoothly. In case you're interested in reading... 

 

5 minutes ago, bananapinas said:

I prefer(ed) nextcloud over owncload.

doesn't mean that you can't use nextcloud... It's just not integrated in OMV (to my knowledge) so you've to setup it by your own..  My OMV on the HC1 has also nginx on it besides from OMV for some other use cases... Doesn't mean that you can't install other things to it. But in comparison to other OMV images, you can sure that they are 'made with love'...  Means a lot of testing & thinking what's important for a good real-world performance not just benchmarking.. 

[bananapinas]

Maybe I'll have a look at it, but I'm not sure if this would help at all.

If it's an hardware issue  (board, sd card, hdd, powering) this wouldn't change  anything - also I don't believe it is, as it worked before, and I'll after the next freeze change hdd and sd card back to the "bananian system originals".

And if it's an os issue it would stay there with armbian, sooner or later also OMV will use the 5.38 kernel I think (?).

 

But before trying something completely else like OMV I'd like to try to get this freezing issue fixed... just need to know how to find out.. would a serial console UART log help here?

 

[bananapinas]

I additionaly observed now with armbianmonitor -m that the cpu frequency seems to be fixed at 960mhz with just one lower value 528mhz, even if there is no heavy load (load = 0.15-0.3, %cpu avg. <10%, cpu temp ~33-34°C).

So it looks like cpufrequtils are working, but why is the frequency that high..? 

 

[Igor]

1 hour ago, bananapinas said:

also I don't believe it is, as it worked before, and I'll after the next freeze change

Our repository stock kernels for at least two years in the past. It looks like the problem was found in the latest update and until this is not solved (it can take few days or weeks, perhaps is already solved upstream) the simplest way is to roll kernel one or two versions back ... and your system should work stable. We also provide a feature in armbian-config to freeze kernel updating and you only update non-critical packages when issuing apt-update & upgrade. Do that after you are satisfied with kernel stability.

[bananapinas]

Hi Igor, 

 

thanks for the reply. Does "was found in the latest update" means "it's a known issue, problem found" or "it could be the latest kernel update"? Sorry as obviously i'm not a native speaker.. 

And - never did this - how do i roll back a kernel? After that I'll freeze for some weeks..

 

TIA!

 

 

 

 

[Igor]

30 minutes ago, bananapinas said:

it could be the latest kernel update

Since you and other people are reporting similar problems, this is becoming a known issue, but we don't know what is causing this, nor we have a solution, except rolling back with a kernel.

To check what is available:

apt-cache policy linux-image-next-sunxi

Install specific version:

apt install linux-image-next-sunxi=VERSION linux-dtb-next-sunxi=VERSION

Do the same with u-boot: (check versions first, they might be different than kernel)

apt install linux-u-boot-bananapipro-next=VERSION

 

In general, help out with this table: https://www.armbian.com/kernel/ and adjust board name appropriately.

Please do report back, how it went.

[bananapinas]

Great, thanks.

apt-cache policy shows version 5.35 and 5.31 for uboot and image. image 5.32 has no matching uboot. So I'll try 5.35 first and if it occurs again I'll try 5.31.

 

But so far your help is really appreciated.

I really like the armbian project and will use it on my raspberries and banana pi (without pro) soon also.

 

Donation on the way

[denox]

I'll keep monitoring my machine, without some services running, to see if it crashes again to try and isolate whether or not it is power (or peak) consumption related.

 

After the next crash I will also roll back the kernel and try again.

[Igor]

One good testing point is latest nightly builds to check if this issue is already fixed.

 

armbian-config -> nightly + reboot

[Igor]

Kernel for H3/H5 and A20/A10 has been updated and pushed to the repository. I made 24h severe burn-in testings with three boards: Cubietruck, Orangepi 2E and Orangepi Prime. I did nasty things to them and all are still running.

[guidol]

1 hour ago, Igor said:

Kernel for H3/H5 has been updated and pushed to the repository.

@Igor is it OK/right that some H3/H5 system does show -after update - a lower armbian-version than 5.41 in the welcome-message
even when they received Linux DTB/Kernel 5.41?

 

I got following systems with Linux DTB/kernel 5.41 and the following armbian-version in the welcome-message:
OPi One - 5.38

Opi Zero Plus 5.37

sample:
root@opi-zeroplus:~# dpkg -l |grep -i '5.41'
ii  hostapd                                      2:2.6-4~armbian5.41.180208+1      arm64        IEEE 802.11 AP and IEEE 802.1X/WPA/WPA2/EAP Authenticator
ii  linux-dtb-next-sunxi64                       5.41.180208                       arm64        Linux DTB, version 4.14.18-sunxi64
ii  linux-image-next-sunxi64                     5.41.180208                       arm64        Linux kernel, version 4.14.18-sunxi64
ii  linux-u-boot-orangepizeroplus-next           5.41.180208                       arm64        Uboot loader 2017.11
ii  sunxi-tools                                  1.4.2-2~armbian5.41.180208+1      arm64        tools for working with Allwinner (sunxi) ARM processors

Sunvell R69 User-built 5.40

 

 

5.41 is shown right at
OPi R1

Opi Zero mainline

NanoPi Neo/Core2

 

 

 

[Igor]

The system version will not change since updates were made only to the kernel. It's safe to ignore. Also for those who temporally switched to the beta, you just switch back to stable. Kernel will remain "5.41.180208" until it will be updated with a more recent stable version. Switching repository back to stable is important.

[vlad59]

I tried to update my Banana Pi but the no new kernel is found, I use apt.uk.armbian.com is it normal ?

[Igor]

26 minutes ago, vlad59 said:

I tried to update my Banana Pi but the no new kernel is found, I use apt.uk.armbian.com is it normal ?

(new) repository script update forgot to trigger a mirror update. Fixed now.

[vlad59]

thanks, I'll upgrade tomorrow morning (too late here

[vlad59]

Upgraded and it's working fine, I'll get back to you if there are problem

[odoll]

My cubietruck was also running very stable for month, but I found this thread, because I also seem to have this "freezing" issue since I updated from v5.37? to v5.38. Hoped v5.41 "bugfix update on sunxi/sunxi64 kernel" solved it, but I still have those freezes after a couple of hours / few days. (ssh still connects, but I don't get to a prompt, thus I have to power cycle.)

 

I'll make a backup of the SD in tomorrows maint window (when family's gone ;-) and try to downgrade as advised by Igor.

 

PS: downgraded to v5.35 (there's no 5.37 for me)

apt install linux-image-next-sunxi=5.35 linux-dtb-next-sunxi=5.35

and froze kernel updates via armbian-config

  ____      _     _      _                   _
 / ___|   _| |__ (_) ___| |_ _ __ _   _  ___| | __
| |  | | | | '_ \| |/ _ \ __| '__| | | |/ __| |/ /
| |__| |_| | |_) | |  __/ |_| |  | |_| | (__|   <
 \____\__,_|_.__/|_|\___|\__|_|   \__,_|\___|_|\_\


Welcome to ARMBIAN 5.38 stable Debian GNU/Linux 9 (stretch) 4.13.16-sunxi
Linux share 4.13.16-sunxi #20 SMP Fri Nov 24 19:50:07 CET 2017 armv7l

 

[denox]

Thank you for the updated kernel/fix. Unfortunately, it still results in similar behavior for me as well.

 

I'm currently trying out the following combination based on Igor's recommendation to downgrade. I also froze kernel updates via armbian-config.

* linux-dtb-next-sunxi 5.35 (both 5.38 and 5.41 resulted in similar behavior)

* linux-image-next-sunxi 5.35 (both 5.38 and 5.41 resulted in similar behavior)

* linux-u-boot-lime2-next 5.35 (5.371 resulted in similar behavior)

* linux-headers-next-sunxi 5.41 (didn't roll this back, let me know if I should; I'm asking because it's frozen through armbian-config)

* linux-stretch-root-next-lime2 5.38 (didn't roll this back, let me know if I should; I'm asking because it's frozen through armbian-config)

 

I'll monitor and report back.

[chpasha]

17 hours ago, denox said:

Thank you for the updated kernel/fix. Unfortunately, it still results in similar behavior for me as well.

I can confirm this. I experience similar issues with custom build for amlogic 905 based on armbian 5.37 / debian 9 (kernel 3.14.29) - I have pretty clean installation with only few additional software pieces like docker 17.12 (+tvheadend image) , openvpn and transmission-daemon. I tried 5.41 now and got the next freeze after about 8hours of uptime when the box was idle (I stressed it before for about 4-5 hours and it was ok, but after an hour of doing nothing it stopped responding). I'm not sure if it could help - but the most freezes I've got when compiling this docker image - 1 of every 3rd or 4th attempted resulted in box not responding. And it happens on the same operation:

pip install --no-cache-dir -U \
        gevent \
        psutil \
        requests \
        bencode \
        virtualenv

I'm testing 5.27 now

[ulf15]

I can confirm the unstable behaviour described by denox for pcDuino 3 and pcDuino 3 nano with Armbian 5.37 / 5.38 as well.  The same goes for the dev kernel 4.15 RC9. Maximum uptime was 2 days, but 5 to 20 hours was more common. 

 

My installation is pretty basic: Armbian Xenial, Desktop disabled, mariaDB, Apache2, owncloud. 

 

Last stable kernel seems to be 4.13.16 (Armbian 5.35) for both boards: uptime 6 days and counting.

 

[odoll]

On 2/14/2018 at 9:09 PM, odoll said:

PS: downgraded to v5.35 (there's no 5.37 for me)

apt install linux-image-next-sunxi=5.35 linux-dtb-next-sunxi=5.35

and froze kernel updates via armbian-config

 

On 2/22/2018 at 10:07 AM, chpasha said:

I have pretty clean installation with only few additional software pieces like docker 17.12 (+tvheadend image) , openvpn and transmission-daemon.

 

I had another freeze though having downgraded my Cubietruck to v5.35 and I also had a suspicion about tvheadend and downgraded that to 4.3-1067~g68d0bc5~xenial and froze it as well.

As the CB was running stable since the last 10 days I just unfroze the kernel and updated to v5.41, but left tvheadend at 4.3-1067~g68d0bc5~xenial.

Will keep you updated

[chpasha]

5 hours ago, odoll said:

 

 

I had another freeze though having downgraded my Cubietruck to v5.35 and I also had a suspicion about tvheadend and downgraded that to 4.3-1067~g68d0bc5~xenial and froze it as well.

I had a stable 4.2.25. But I come to conclusion that it is a docker, that makes the problems. After downgrading to 5.27 things became better - in spite of huge cpu usage the box didn't freeze completely so I could see what is causing the stress - it was dockerd daemon itself (I tried both latest 18.02 as well as previous 17.12  with same result) - it starts to use cpu power without a reason. After getting rid of it I have no problems anymore - but I had to return to ubuntu 16.04 based image since without being able to use docker some software pieces were missing in debian

[hpmux]

I've had the Ubuntu version of Armbian 4.3 running for more than two years 24/7 on my Banana Pi without any flaws (thanks  to the Armbian team for their great work). Latest kernel version was 4.8.4.

I'm using the Banana Pi mainly as a file server plus running the great little utily "udpxy" (multicast to unicast converter for IP-TV). udpxy took normally about 8% of the CPU, the rest was negligible, except during intense network traffic via samba.

A few days ago I decided to give Debian mainline a try.

 

The fresh setup of version 5.38 was immediately upgraded to 5.41. Running "top" I discovered, that kworker processes used up to 20% of the CPU and a relative high CPU temperature (about 48°C); after less than an hour the TV screen froze and the box needed a hard reset.

I found this thread and tried a downgrade to version 5.35. The CPU usage of kworkers appeared to be a bit lower, but there was still the high CPU temperature, CPU freq constantly at 960MHz, and after half an hour the dreaded freeze occurred again.

 

So I took the next step down to version 5.31. Apparently the issues are gone now. No bloated kworker processes, low CPU temperature, lower CPU idle frequency (528MHz), no freeze. Looks good, the box is up for several day now without a problem.

.

In short: 5.31 (with Kernel 4.11.5-sunxi) works fine for me, so something bad might have happened on the way to 5.35.

 

[sooperior]

Same confirmation from me! I was driving me crazy trying to find what caused the system freeze. I have disabled most of the things that can be disabled and still occurs (even thought of log2ram because removing it gave me some more time to failure).

The only difference in my case is sometimes it kernel panics and says something like "cpu 1 can not be stop". Some others it just freezes and I have to remove battery and power to restart.

 

I have discarded power source: I have some cron tasks that peak cpu and temperature and seems to tolerate correctly, without voltage drops or simillar. It just happens... ramdomly.

 

I'm running banana pi m1, latest kernel update.

[denox]

On 2/21/2018 at 10:02 AM, denox said:

Thank you for the updated kernel/fix. Unfortunately, it still results in similar behavior for me as well.

 

I'm currently trying out the following combination based on Igor's recommendation to downgrade. I also froze kernel updates via armbian-config.

* linux-dtb-next-sunxi 5.35 (both 5.38 and 5.41 resulted in similar behavior)

* linux-image-next-sunxi 5.35 (both 5.38 and 5.41 resulted in similar behavior)

* linux-u-boot-lime2-next 5.35 (5.371 resulted in similar behavior)

* linux-headers-next-sunxi 5.41 (didn't roll this back, let me know if I should; I'm asking because it's frozen through armbian-config)

* linux-stretch-root-next-lime2 5.38 (didn't roll this back, let me know if I should; I'm asking because it's frozen through armbian-config)

 

I'll monitor and report back.

 

We're 13 days later and I'm happy to report that I haven't experienced any crashes or issues on this quoted setup (downgrade to 5.35 for dtb, image and u-boot).

[odoll]

On 2/28/2018 at 11:01 AM, odoll said:

 

 

I had another freeze though having downgraded my Cubietruck to v5.35 and I also had a suspicion about tvheadend and downgraded that to 4.3-1067~g68d0bc5~xenial and froze it as well.

As the CB was running stable since the last 10 days I just unfroze the kernel and updated to v5.41, but left tvheadend at 4.3-1067~g68d0bc5~xenial.

Will keep you updated

We're 10 days later and I'm happy to report that I haven't experienced any crashes or issues on this quoted setup (since upgraded back to v5.41 (or latest for dtb, image and u-boot)), though still having frozen tvheadend at 4.3-1067~g68d0bc5~xenial.