marian34 Posted July 9, 2020 Posted July 9, 2020 Armbianmonitor: http://ix.io/2rfu Is there anything that can be done about it? Something will start(e.g. minisatip, mumudvb) to disproportionately use the cpu and after a short time it will crash completely. A similar configuration works well on an OPI PC(Linux orangepipc 4.10.1-sun8i #1 SMP Sun Mar 5 18:47:02 CET 2017 armv7l GNU/Linux), but with newer versions it behaves just as incorrectly. I've tested other images (ubuntu, debian), but it's the same everywhere.
Werner Posted July 9, 2020 Posted July 9, 2020 Quote 5.51 | armhf | armv7l | 4.14.55-sunxi You are way outdated. This old release is not supported anymore. How do you power the board?
marian34 Posted July 9, 2020 Author Posted July 9, 2020 Ok, but I also had the latest version from compile.sh there and it worked the same way. The board is powered enough, I tested it.
marian34 Posted July 9, 2020 Author Posted July 9, 2020 Armbianmonitor: http://ix.io/2rfI This is an extract from dmesg when it starts to freeze: [ 268.944228] rcu: INFO: rcu_sched self-detected stall on CPU [ 268.944762] rcu: 1-....: (5385 ticks this GP) idle=ee2/1/0x40000004 softirq=10708/10708 fqs=2058 [ 268.944949] (t=5250 jiffies g=17313 q=123) [ 268.945122] NMI backtrace for cpu 1 [ 268.945429] CPU: 1 PID: 89 Comm: kworker/1:1 Tainted: G C 5.4.50-sunxi #trunk [ 268.945555] Hardware name: Allwinner sun8i Family [ 268.945958] Workqueue: events dbs_work_handler [ 268.946615] [<c010dc49>] (unwind_backtrace) from [<c010a245>] (show_stack+0x11/0x14) [ 268.947066] [<c010a245>] (show_stack) from [<c0861f5b>] (dump_stack+0x6f/0x7c) [ 268.947518] [<c0861f5b>] (dump_stack) from [<c08662bf>] (nmi_cpu_backtrace+0x6b/0x94) [ 268.947940] [<c08662bf>] (nmi_cpu_backtrace) from [<c08663b9>] (nmi_trigger_cpumask_backtrace+0xd1/0xdc) [ 268.948402] [<c08663b9>] (nmi_trigger_cpumask_backtrace) from [<c016f0e1>] (rcu_dump_cpu_stacks+0x7f/0x9c) [ 268.948851] [<c016f0e1>] (rcu_dump_cpu_stacks) from [<c016e48d>] (rcu_sched_clock_irq+0x5a5/0x71c) [ 268.949292] [<c016e48d>] (rcu_sched_clock_irq) from [<c0173f19>] (update_process_times+0x29/0x50) [ 268.949689] [<c0173f19>] (update_process_times) from [<c0181ac7>] (tick_sched_timer+0x37/0x74) [ 268.950081] [<c0181ac7>] (tick_sched_timer) from [<c01748eb>] (__hrtimer_run_queues+0xef/0x230) [ 268.950509] [<c01748eb>] (__hrtimer_run_queues) from [<c017528d>] (hrtimer_interrupt+0xd1/0x1fc) [ 268.950975] [<c017528d>] (hrtimer_interrupt) from [<c07015e3>] (arch_timer_handler_phys+0x27/0x2c) [ 268.951471] [<c07015e3>] (arch_timer_handler_phys) from [<c0165193>] (handle_percpu_devid_irq+0x57/0x1a0) [ 268.951955] [<c0165193>] (handle_percpu_devid_irq) from [<c01610e5>] (generic_handle_irq+0x1d/0x28) [ 268.952378] [<c01610e5>] (generic_handle_irq) from [<c016159f>] (__handle_domain_irq+0x43/0x84) [ 268.952754] [<c016159f>] (__handle_domain_irq) from [<c0517ffd>] (gic_handle_irq+0x39/0x6c) [ 268.953128] [<c0517ffd>] (gic_handle_irq) from [<c0101ae5>] (__irq_svc+0x65/0x94) [ 268.953303] Exception stack(0xef343b70 to 0xef343bb8) [ 268.953585] 3b60: ed3caf8c 80080113 80000000 00004052 [ 268.953950] 3b80: ed3cadb0 00001000 ed3caf8c 80080113 f08f3000 00000fdf 00000021 00000001 [ 268.954258] 3ba0: 00000000 ef343bc0 bf9cbd3d c0875a9c 00080133 ffffffff [ 268.954716] [<c0101ae5>] (__irq_svc) from [<c0875a9c>] (_raw_spin_unlock_irqrestore+0x1c/0x20) [ 268.956005] [<c0875a9c>] (_raw_spin_unlock_irqrestore) from [<bf9cbd3d>] (dvb_dmx_swfilter+0xcd/0x108 [dvb_core]) [ 268.957563] [<bf9cbd3d>] (dvb_dmx_swfilter [dvb_core]) from [<bf9958ab>] (dvb_usb_data_complete+0x27/0x28 [dvb_usb]) [ 268.958095] [<bf9958ab>] (dvb_usb_data_complete [dvb_usb]) from [<ef2e6114>] (0xef2e6114)
marian34 Posted July 9, 2020 Author Posted July 9, 2020 I have a 3A adapter there and I also tested it on a PC power supply. It certainly won't be an AC adapter. There will be a bug in the kernel. Although those pc sat cards of older data on a linux PC (ubuntu, kubuntu latest) work reliably.
Igor Posted July 9, 2020 Posted July 9, 2020 1 hour ago, marian34 said: There will be a bug in the kernel. True. More precisely in the driver or somewhere close. But kernel is a work of thousands of people and we are just a few that support this project. It is good to bring this up, but you are using board we don't support (Bpi M2U) and hardware we have nothing to do with (DVB tuner) and we never provide any support. If it stopped working ... its mainly on you to fix it up, perhaps try to find if someone knows something. Even you are willing to cover debugging and fixing (count few days, perhaps weeks), we https://github.com/armbian/build/graphs/contributors?from=2020-01-08&to=2020-07-09&type=c can't afford to help you. We are overloaded with, 1000 x too many, issues already "addressed to armbian", while we have nothing to do with them and we will not do anything about ... I hope you do understand that.
marian34 Posted July 10, 2020 Author Posted July 10, 2020 Ok, I just didn't know where to turn with the problem. Don't take it as remorse. I certainly don't expect you to work on it, it's not worth it. I just thought, when it works on the older kernel, if the solution would be to turn off some new functionality in the newer kernels. We can safely let it float, thanks.
Recommended Posts