Mikhail Kulinich

  • Content Count

    6
  • Joined

  • Last visited

About Mikhail Kulinich

  • Rank
    Newbie

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Just curious, if I build an image based on 5.8 or 5.9 branches, it will contain those fixes, right?
  2. Nice! Thanks! This patch was pushed yesterday to orange-pi-5.9 branch, 2 commits below : https://github.com/megous/linux/commit/417a54f606c4ccf75023da0d165febe1a30e2764#diff-874a1d4d688766992a150cf3b81a4d8c https://github.com/megous/linux/commit/a42d5d4f49814e98cc7420d433d2a2f1c2ce8996#diff-874a1d4d688766992a150cf3b81a4d8c orange-pi-5.8 branch has those patches as well: https://github.com/megous/linux/commit/1808a619f48d2380d528d3f3d3778c48edba6116#diff-874a1d4d688766992a150cf3b81a4d8c https://github.com/megous/linux/commit/5566c7d7c9288d62792d6f9075
  3. Was this patch ever added to upstream? Experiencing the same issue with couple of OrangePI One boards.
  4. I notice similar freezes on some of my OrangePI One boards: Aug 11 04:01:10 kernel: [11045.901932] asix 3-1.4.1:1.0 asix: link up, 100Mbps, full-duplex, lpa 0x41E1 Aug 11 04:05:50 kernel: [11326.227650] INFO: rcu_sched detected stalls on CPUs/tasks: Aug 11 04:05:50 kernel: [11326.227679] 3-...: (1 ticks this GP) idle=992/1/0 softirq=363926/363926 fqs=1 Aug 11 04:05:50 kernel: [11326.227681] (detected by 2, t=41234 jiffies, g=193459, c=193458, q=5) Aug 11 04:05:50 kernel: [11326.227697] Sending NMI from CPU 2 to CPUs 3: Aug 11 04:05:50 kernel: [11326.227720] NMI backtrace for cp
  5. The system runs automated tests (using Robot Framework, python tool), interacts via CAN bus (using Intrepid ValueCAN3) with system under test, does some unheavy networking. This was not happening on kernel 4.13.15, but started to happen on 4.19.50. I've separate issue on Github for Intrepid as their driver gives a call stack during boot up. However, not sure if this is related.
  6. At 19:54:55 kernel crash happens. That for some reason forces system to change time to Aug 24 1978. systemd reacts to that situation strangely, which puts system under unresponsive state, like infinite loop, potentially causing 100% cpu occupation (this is guess now) The printouts "Aug 24 07:45:10 ptc_lab_collab3_node17 systemd[20635]: Time has been changed" follows many times per second until node is rebooted manually. The kernel version: 4.19.50-sunxi #5.89 SMP Fri Jun 14 01:50:58 EDT 2019 armv7l armv7l armv7l GNU/Linux Aug 10 19:45:01 ptc_lab_collab3_node17 CRON[32019]: p