René Kliment

I've been running 4.17.14-sunxi for 4 days straight now and it's crunching two `openssl speed` in a loop at 1200 MHz. So far so good. Maybe this patch has something to do with it? https://github.com/armbian/build/commit/3326ccc11648e5ff482102ec401b22cc795006ae I don't have time to compare with and without, but I'm super glad it works now :-)

Yeah, so can confirm the thing with my log too. [314330.237556] INFO: rcu_sched detected stalls on CPUs/tasks: [314330.243170] (detected by 2, t=107378770 jiffies, g=3815634, c=3815633, q=30640) [314330.250673] All QSes seen, last rcu_sched kthread activity 107378777 (421779489-314400712), jiffies_till_next_fqs=3, root ->qsmask 0x0 [314330.263135] rcu_sched kthread starved for 107378790 jiffies! g3815634 c3815633 f0x2 RCU_GP_WAIT_FQS(3) ->state=0x0 ->cpu=2 [314330.274266] RCU grace-period kthread stack dump: [314330.237556] INFO: rcu_sched detected stalls on CPUs/task

Board quality is definitely a factor. However, it worked fine for me in early 4.14 kernels, then got broken, then got fixed again and now it's broken again so it seems like a kernel and/or uboot issue. Let's hope it will magically fix itself again :-O I can confirm that it froze with 4.17.6. I've upgraded to 4.17.8 and connected the serial console to catch the dmesg output when it freezes again.

Yes, I can confirm I had freezes on my OPi +2e with a few latest 4.14.x kernels and I had to cap the CPU freq to 648 MHz - anything above would lead to a system freeze. I don't have a log unfortunately, but I believe it would be same as yours. I see there is kernel 4.17.6 available, testing it now to see if it is fixed or not. Maybe a patch that fixed this before got left out? @Igor

This is my very dirty script that seems to work for me: https://gist.github.com/renekliment/707ea4a2dc3f11fc15ed8085f506c57e

Yes, it seems that .17 and .18 work fine. Thanks!

The only workaround I have been able to come up so far is capping the CPU frequency pretty low - 480 MHz max - bigger wouldn't work for me and would always stall after a couple of hours. I've been able to run it for 2 days straight now with cpufreq-set --max 500Mhz

Happens with both idle and busy Pi. I've been trying to rsync+ssh from a remote to an USB connected HDD. The HDD has its own power. Also, the Pi has a heat sink, so no overheating either. This is the weirdest thing ...

Hello everyone. This happens on my OrangePi after a couple of hours of running. I don't think this happened before installing the kernel 4.14. I haven't changed my power supply, which should be working well - custom DC/DC converter connected to GPIO pins. Is anyone else experiencing this? Anything I can do? [19155.760977] INFO: rcu_sched self-detected stall on CPU [19155.760983] INFO: rcu_sched self-detected stall on CPU [19155.760997] INFO: rcu_sched detected stalls on CPUs/tasks: [19155.761010] 2-...: (1 ticks this GP) idle=18a/1/0 softirq=332295/332295 fqs=0 [19155.761017] 0-

So if I understand this correctly ... even though I have the mali.ko, there is no easy way of using it in X currently? How does this differ from using the legacy kernel / stack? I thought the difference was only in the kernel and user-space stuff should be more or less the same. Could you please elaborate? Also, it seems that I only get mali.ko, not mali_drm.ko ... what's the relation and is that what's preventing the use of something useful? I am very inexperienced with the graphics stack, so if those are super silly questions, I am sorry to bother.