Ford_Prefect Posted November 10, 2020 Posted November 10, 2020 (edited) Hi, I have quiet a problem getting ipsec/strongswan running on my Orange Pi R1. IPSec is configured fine and it connects to my vpn gatway by establishing and ikev2 connection with the help of transform (xfrm) interfaces. After connection everything works fine, but not for long. When I transfer large amounts of data (e.g. iperf3) the whole Orange Pi R1 freezes suddenly. This occours almost immideatly, sometimes i get a couple of seconds a data stream, but mostly it freezes at once. Currently I use even the lates "Linux orangepi-r1 5.9.1-sunxi #20.08.14 SMP Tue Oct 20 23:01:54 CEST 2020 armv7l GNU/Linux" Kernel, and I upgraded the whole installation to bullseye. I firstly guesst a weak power supply, but now I rule that out because a stresstest and even compiling a kernel works absolutely fine. Furthermore, there is nothing attached to the device despite one ethernet link. I also tried using only the other ethernet port, but still the same (after the freeze, you immediatly cannot ping the devise, neither via ipsec nor directly in the same ethernet segment. a tcpdump on the same ethernet segment shows that absolutely now packets are received any more) The serial console is not connected right now, I will connect it later to see if there are any other hints - but if it is not a "freeze" there will be a kernel oops or something like that. Did anybody had a similar problem? The short time iperf3 was getting packets it topped out at about 40 MBit/s - just for the records --- but only for a couple of seconds.... Thanks a lot! Cheers, Fort Prefect Edited November 10, 2020 by Ford_Prefect 0 Quote
Igor Posted November 10, 2020 Posted November 10, 2020 2 minutes ago, Ford_Prefect said: Currently I use even the lates "Linux orangepi-r1 5.9.1-sunxi #20.08.14 SMP Tue Oct 20 23:01:54 CEST 2020 armv7l GNU/Linux" Kernel, and I upgraded the whole installation to bullseye. My first guess will be DVFS which is causing us troubles for some time and has been reworked a few times. Not sure if we are stable with it yet and certainly this is a guess with bleeding edge 5.9.y ... which was not tested much. A possible workaround is to set fixed CPU speed (you can use armbian-config) or changing its governor. Anything else would require much more investigation. Is the same happening with official builds from the download section? 0 Quote
guidol Posted November 10, 2020 Posted November 10, 2020 1 hour ago, Ford_Prefect said: I have quiet a problem getting ipsec/strongswan running on my Orange Pi R1. This occours almost immideatly, sometimes i get a couple of seconds a data stream, but mostly it freezes at once. Currently I use even the lates "Linux orangepi-r1 5.9.1-sunxi #20.08.14 SMP Tue Oct 20 23:01:54 CEST 2020 armv7l GNU/Linux" Kernel, and I upgraded the whole installation to bullseye. I also tried using only the other ethernet port, but still the same (after the freeze, you immediatly cannot ping the devise, neither via ipsec nor directly in the same ethernet segment. a tcpdump on the same ethernet segment shows that absolutely now packets are received any more) Did anybody had a similar problem? The short time iperf3 was getting packets it topped out at about 40 MBit/s - just for the records --- but only for a couple of seconds.... I tested my OPi R1 these days with kernel 5.10.0-rc2 and got problems with eth0 like on some versions in the past. You could see this issue in dmesg showing the eth0-device-link going down/up serveral times (eth0 ist the ethernet-port near the serial-ttl-port, the other enx-ethernet is connectec via usb) My enx-ethernet device is working here fine, but now my eth0 device has stopped working completly I use /etc/network/interfaces for setting the IP. armbian does set the IP but eth0 cant use the net ___ ____ _ ____ _ / _ \| _ \(_) | _ \/ | | | | | |_) | | | |_) | | | |_| | __/| | | _ <| | \___/|_| |_| |_| \_\_| Welcome to Armbian 20.11.0-trunk Buster with Linux 5.10.0-rc2-sunxi No end-user support: built from trunk package bsp-kernel[20.11.0-trunk] u-boot[20.11.0-trunk] dtb [20.11.0-trunk] firmware [20.11.0-trunk] config[20.11.0-trunk] branch[dev] root@opi-r1-101(192.168.6.101):~# ifconfig enxc0742bffe8ff: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500 inet 192.168.6.101 netmask 255.255.255.0 broadcast 192.168.6.255 ether c0:74:2b:ff:e8:ff txqueuelen 1000 (Ethernet) RX packets 247 bytes 17017 (16.6 KiB) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 90 bytes 9447 (9.2 KiB) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 System diagnosis information has been uploaded to http://ix.io/2DDi 0 Quote
guidol Posted November 10, 2020 Posted November 10, 2020 13 hours ago, Igor said: Is the same happening with official builds from the download section? Also got the problem with the official download-image Armbian_20.08.1_Orangepi-r1_buster_current_5.8.5.img eth0 orange/green led does lit , orange stays, green blink for some seconds, both goes off: like last year: [ 33.780717] vcc3v0: disabling [ 33.780731] vcc5v0: disabling [ 33.877210] dwmac-sun8i 1c30000.ethernet eth0: Link is Up - 100Mbps/Full - flow control rx/tx [ 34.901031] dwmac-sun8i 1c30000.ethernet eth0: Link is Down [ 37.973216] dwmac-sun8i 1c30000.ethernet eth0: Link is Up - 100Mbps/Full - flow control rx/tx [ 38.996979] dwmac-sun8i 1c30000.ethernet eth0: Link is Down [ 40.021229] dwmac-sun8i 1c30000.ethernet eth0: Link is Up - 100Mbps/Full - flow control rx/tx [ 41.044983] dwmac-sun8i 1c30000.ethernet eth0: Link is Down [ 42.069337] dwmac-sun8i 1c30000.ethernet eth0: Link is Up - 100Mbps/Full - flow control rx/tx [ 43.093067] dwmac-sun8i 1c30000.ethernet eth0: Link is Down or here: https://serverfault.com/questions/585442/eth0-nic-link-is-down-repeating-message-in-kernel-log usb/enx-ether is OK: [ 432.833832] IPv6: ADDRCONF(NETDEV_CHANGE): enxc0742bffe8ff: link becomes ready [ 432.834587] r8152 3-1:1.0 enxc0742bffe8ff: carrier on power is enough/good from a original RPI-powersupply (5.1V) 0 Quote
5kft Posted November 10, 2020 Posted November 10, 2020 I think that more research is needed here, as the problem is non-obvious. Unfortunately I can't reproduce any issues on my OrangePi R1 with either 5.8.5 or 5.9.5. @Igor this doesn't appear to be DVFS related; the DTs are correct and the board is correctly maxed at 1GHz (but it can support 1.3GHz via the overclocking overlay). I can successfully run all of "openssl speed -multi 4", throttling is fine, etc. Using iperf3 testing, I can't reproduce any issues on my board with the Ethernet interfaces either; both eth0 and enxc0742bfffa39 work properly for me... I'm seeing 94Mbps on both eth0 and enxc0742bfffa39 (for testing, I purged network-manager and statically set the IPs in /etc/network/interfaces.d/) - here is the iperf3 server output for the two runs from the R1: Spoiler ----------------------------------------------------------- Server listening on 5201 ----------------------------------------------------------- Accepted connection from 192.168.3.8, port 47388 [ 5] local 192.168.3.2 port 5201 connected to 192.168.3.8 port 47390 [ ID] Interval Transfer Bitrate [ 5] 0.00-10.00 sec 112 MBytes 94.1 Mbits/sec [ 5] 10.00-20.00 sec 112 MBytes 94.1 Mbits/sec [ 5] 20.00-30.00 sec 112 MBytes 94.1 Mbits/sec [ 5] 30.00-30.01 sec 93.3 KBytes 90.7 Mbits/sec - - - - - - - - - - - - - - - - - - - - - - - - - [ ID] Interval Transfer Bitrate [ 5] 0.00-30.01 sec 337 MBytes 94.1 Mbits/sec receiver ----------------------------------------------------------- Server listening on 5201 ----------------------------------------------------------- Accepted connection from 192.168.3.7, port 34552 [ 5] local 192.168.3.2 port 5201 connected to 192.168.3.7 port 34554 [ ID] Interval Transfer Bitrate [ 5] 0.00-10.00 sec 112 MBytes 93.8 Mbits/sec [ 5] 10.00-20.00 sec 112 MBytes 94.2 Mbits/sec [ 5] 20.00-30.00 sec 112 MBytes 94.2 Mbits/sec [ 5] 30.00-30.01 sec 89.1 KBytes 93.6 Mbits/sec - - - - - - - - - - - - - - - - - - - - - - - - - [ ID] Interval Transfer Bitrate [ 5] 0.00-30.01 sec 337 MBytes 94.1 Mbits/sec receiver ----------------------------------------------------------- Server listening on 5201 ----------------------------------------------------------- Of course this is not to say that there isn't a problem, but with this simple/quick iperf3 testing I can't reproduce anything on my board. @Ford_Prefect I think it would be interesting to see what your serial console shows. @guidol would it be possible to get serial console output for your situation as well? 0 Quote
guidol Posted November 10, 2020 Posted November 10, 2020 3 hours ago, 5kft said: @guidol would it be possible to get serial console output for your situation as well? Which serial ouput do you need/mean? From the boot-process while using eth0? 0 Quote
Ford_Prefect Posted November 11, 2020 Author Posted November 11, 2020 Hi, First of all, this all happens only when I use ipsec it seems - If I transfer large amounts of data directly, the enpxxx Interface (USB) and the internal attached eth0 everything works fine. I also set the gouvernor to "performance" and highest CPU Frequency. I attached the Serial Port and found out the following: The Raspi does not freeze, the USB enpxxx Interface seizes operation nearly instantaniously.... Via serial Port I the device itself worked just fine, but the ethernet Port crashed.... Is there any workaround? I mean.... using a 2 Port SBC and attaching an additional USB Ethernet NIC is not really my goal here....;-) 19.234179] sun8i-ce 1c15000.crypto: Fallback for ecb-aes-sun8i-ce is ecb-aes-neonbs [ 19.853360] IPv6: ADDRCONF(NETDEV_CHANGE): enxc0742bffecdb: link becomes ready [ 19.862969] r8152 3-1:1.0 enxc0742bffecdb: carrier on [ 33.779552] vcc3v0: disabling [ 33.779566] vcc5v0: disabling [ 84.442046] IPsec XFRM device driver [ 93.795697] sun8i-ce 1c15000.crypto: Fallback for cbc-des3-sun8i-ce is cbc(des3_ede-generic) [ 93.817912] sun8i-ce 1c15000.crypto: Fallback for cbc-aes-sun8i-ce is cbc-aes-neonbs [ 93.818110] sun8i-ce 1c15000.crypto: Fallback for cbc-aes-sun8i-ce is cbc-aes-neonbs [ 93.818189] sun8i-ce 1c15000.crypto: Fallback for cbc-aes-sun8i-ce is cbc-aes-neonbs [ 93.818269] sun8i-ce 1c15000.crypto: Fallback for ecb-aes-sun8i-ce is ecb-aes-neonbs [ 93.818333] sun8i-ce 1c15000.crypto: Fallback for ecb-aes-sun8i-ce is ecb-aes-neonbs [ 93.818397] sun8i-ce 1c15000.crypto: Fallback for ecb-aes-sun8i-ce is ecb-aes-neonbs [ 93.947310] sun8i-ce 1c15000.crypto: Fallback for cbc-des3-sun8i-ce is cbc(des3_ede-generic) [ 93.947424] sun8i-ce 1c15000.crypto: Fallback for cbc-aes-sun8i-ce is cbc-aes-neonbs [ 93.947493] sun8i-ce 1c15000.crypto: Fallback for cbc-aes-sun8i-ce is cbc-aes-neonbs [ 93.947559] sun8i-ce 1c15000.crypto: Fallback for cbc-aes-sun8i-ce is cbc-aes-neonbs [ 93.947624] sun8i-ce 1c15000.crypto: Fallback for ecb-aes-sun8i-ce is ecb-aes-neonbs [ 93.947686] sun8i-ce 1c15000.crypto: Fallback for ecb-aes-sun8i-ce is ecb-aes-neonbs [ 93.947780] sun8i-ce 1c15000.crypto: Fallback for ecb-aes-sun8i-ce is ecb-aes-neonbs [ 138.039764] sun8i-ce 1c15000.crypto: Fallback for cbc-des3-sun8i-ce is cbc(des3_ede-generic) [ 138.039876] sun8i-ce 1c15000.crypto: Fallback for cbc-aes-sun8i-ce is cbc-aes-neonbs [ 138.039993] sun8i-ce 1c15000.crypto: Fallback for cbc-aes-sun8i-ce is cbc-aes-neonbs [ 138.040070] sun8i-ce 1c15000.crypto: Fallback for cbc-aes-sun8i-ce is cbc-aes-neonbs [ 138.040137] sun8i-ce 1c15000.crypto: Fallback for ecb-aes-sun8i-ce is ecb-aes-neonbs [ 138.040200] sun8i-ce 1c15000.crypto: Fallback for ecb-aes-sun8i-ce is ecb-aes-neonbs [ 138.040260] sun8i-ce 1c15000.crypto: Fallback for ecb-aes-sun8i-ce is ecb-aes-neonbs [ 138.450617] sun8i-ce 1c15000.crypto: Fallback for cbc-aes-sun8i-ce is cbc-aes-neonbs [ 138.451559] sun8i-ce 1c15000.crypto: Fallback for cbc-aes-sun8i-ce is cbc-aes-neonbs [ 141.806447] NOHZ: local_softirq_pending 08 [ 142.498226] sun8i-ce 1c15000.crypto: Fallback for cbc-aes-sun8i-ce is cbc-aes-neonbs [ 142.498636] sun8i-ce 1c15000.crypto: Fallback for cbc-aes-sun8i-ce is cbc-aes-neonbs [ 142.660627] sun8i-ce 1c15000.crypto: Fallback for cbc-aes-sun8i-ce is cbc-aes-neonbs [ 142.660959] sun8i-ce 1c15000.crypto: Fallback for cbc-aes-sun8i-ce is cbc-aes-neonbs [ 142.831695] sun8i-ce 1c15000.crypto: Fallback for cbc-aes-sun8i-ce is cbc-aes-neonbs [ 142.832064] sun8i-ce 1c15000.crypto: Fallback for cbc-aes-sun8i-ce is cbc-aes-neonbs [ 143.809585] NOHZ: local_softirq_pending 08 [ 144.810432] NOHZ: local_softirq_pending 08 [ 145.813047] NOHZ: local_softirq_pending 08 [ 146.814295] NOHZ: local_softirq_pending 08 [ 147.815793] NOHZ: local_softirq_pending 08 [ 148.817676] NOHZ: local_softirq_pending 08 [ 149.818676] NOHZ: local_softirq_pending 08 [ 150.820421] NOHZ: local_softirq_pending 08 [ 151.821924] NOHZ: local_softirq_pending 08 [...] [ 143.809585] NOHZ: local_softirq_pending 08 [ 144.810432] NOHZ: local_softirq_pending 08 [ 145.813047] NOHZ: local_softirq_pending 08 [ 146.814295] NOHZ: local_softirq_pending 08 [ 147.815793] NOHZ: local_softirq_pending 08 [ 148.817676] NOHZ: local_softirq_pending 08 [ 149.818676] NOHZ: local_softirq_pending 08 [ 150.820421] NOHZ: local_softirq_pending 08 [ 151.821924] NOHZ: local_softirq_pending 08 [ 206.542170] rcu: INFO: rcu_sched self-detected stall on CPU [ 206.542193] rcu: 0-....: (5249 ticks this GP) idle=06a/1/0x40000004 softirq=6817/6817 fqs=2590 [ 206.542199] (t=5251 jiffies g=11233 q=139) [ 206.542205] NMI backtrace for cpu 0 [ 206.542215] CPU: 0 PID: 309 Comm: 1c15000.crypto- Tainted: G C 5.9.1-sunxi #20.08.14 [ 206.542219] Hardware name: Allwinner sun8i Family [ 206.542250] [<c010d415>] (unwind_backtrace) from [<c01097a5>] (show_stack+0x11/0x14) [ 206.542265] [<c01097a5>] (show_stack) from [<c0574801>] (dump_stack+0x75/0x84) [ 206.542280] [<c0574801>] (dump_stack) from [<c0579d33>] (nmi_cpu_backtrace+0x6b/0x94) [ 206.542292] [<c0579d33>] (nmi_cpu_backtrace) from [<c0579e15>] (nmi_trigger_cpumask_backtrace+0xb9/0xe0) [ 206.542307] [<c0579e15>] (nmi_trigger_cpumask_backtrace) from [<c01706ab>] (rcu_dump_cpu_stacks+0xab/0xc8) [ 206.542320] [<c01706ab>] (rcu_dump_cpu_stacks) from [<c016fb23>] (rcu_sched_clock_irq+0x5e3/0x7ac) [ 206.542333] [<c016fb23>] (rcu_sched_clock_irq) from [<c0176641>] (update_process_times+0x29/0x70) [ 206.542345] [<c0176641>] (update_process_times) from [<c0184b57>] (tick_sched_timer+0x37/0x74) [ 206.542357] [<c0184b57>] (tick_sched_timer) from [<c0177089>] (__hrtimer_run_queues+0xf1/0x250) [ 206.542368] [<c0177089>] (__hrtimer_run_queues) from [<c0177ab1>] (hrtimer_interrupt+0xcd/0x1fc) [ 206.542383] [<c0177ab1>] (hrtimer_interrupt) from [<c07a9c7b>] (arch_timer_handler_phys+0x27/0x2c) [ 206.542398] [<c07a9c7b>] (arch_timer_handler_phys) from [<c0165acb>] (handle_percpu_devid_irq+0x53/0x1a0) [ 206.542414] [<c0165acb>] (handle_percpu_devid_irq) from [<c01611b5>] (generic_handle_irq+0x29/0x34) [ 206.542426] [<c01611b5>] (generic_handle_irq) from [<c0161671>] (__handle_domain_irq+0x41/0x80) [ 206.542438] [<c0161671>] (__handle_domain_irq) from [<c058628f>] (gic_handle_irq+0x3b/0x70) [ 206.542449] [<c058628f>] (gic_handle_irq) from [<c0100b65>] (__irq_svc+0x65/0x94) [ 206.542455] Exception stack(0xcc97fa20 to 0xcc97fa68) [ 206.542465] fa20: cb8d2660 000064b2 000064b1 000064b1 cdf2b0c0 cb8d2640 00000000 00000032 [ 206.542474] fa40: 00000000 00000002 cb8d2660 00000000 00000004 cc97fa70 c08d6bd3 c0953d84 [ 206.542478] fa60: 800d0133 ffffffff [ 206.542492] [<c0100b65>] (__irq_svc) from [<c0953d84>] (_raw_spin_lock+0x28/0x38) [ 206.542507] [<c0953d84>] (_raw_spin_lock) from [<c08d6bd3>] (xfrm_input+0x137/0xce0) [ 206.542519] [<c08d6bd3>] (xfrm_input) from [<c08cb1cb>] (xfrm4_esp_rcv+0x27/0x38) [ 206.542532] [<c08cb1cb>] (xfrm4_esp_rcv) from [<c0877a0f>] (ip_protocol_deliver_rcu+0x27/0x214) [ 206.542544] [<c0877a0f>] (ip_protocol_deliver_rcu) from [<c0877c37>] (ip_local_deliver_finish+0x3b/0x40) [ 206.542554] [<c0877c37>] (ip_local_deliver_finish) from [<c0877cd5>] (ip_local_deliver+0x99/0xa4) [ 206.542563] [<c0877cd5>] (ip_local_deliver) from [<c0877d5f>] (ip_rcv+0x7f/0x84) [ 206.542577] [<c0877d5f>] (ip_rcv) from [<c0815295>] (__netif_receive_skb_core+0x41d/0xa78) [ 206.542590] [<c0815295>] (__netif_receive_skb_core) from [<c0815c6b>] (__netif_receive_skb_list_core+0x97/0x130) [ 206.542600] [<c0815c6b>] (__netif_receive_skb_list_core) from [<c0815e33>] (netif_receive_skb_list_internal+0x12f/0x1e0) [ 206.542609] [<c0815e33>] (netif_receive_skb_list_internal) from [<c0815fc9>] (gro_normal_list.part.0+0x15/0x24) [ 206.542618] [<c0815fc9>] (gro_normal_list.part.0) from [<c0816939>] (napi_complete_done+0x85/0x160) [ 206.542654] [<c0816939>] (napi_complete_done) from [<bf8d4dd5>] (r8152_poll+0x4a9/0x51c [r8152]) [ 206.542686] [<bf8d4dd5>] (r8152_poll [r8152]) from [<c0816ad1>] (net_rx_action+0xbd/0x2c4) [ 206.542696] [<c0816ad1>] (net_rx_action) from [<c0101367>] (__do_softirq+0xcf/0x260) [ 206.542707] [<c0101367>] (__do_softirq) from [<c0120df5>] (irq_exit+0x79/0x98) [ 206.542717] [<c0120df5>] (irq_exit) from [<c0161675>] (__handle_domain_irq+0x45/0x80) [ 206.542727] [<c0161675>] (__handle_domain_irq) from [<c058628f>] (gic_handle_irq+0x3b/0x70) [ 206.542737] [<c058628f>] (gic_handle_irq) from [<c0100b65>] (__irq_svc+0x65/0x94) [ 206.542741] Exception stack(0xcc97fdf8 to 0xcc97fe40) [ 206.542747] fde0: 000000c3 00000000 [ 206.542756] fe00: c9aca488 00000004 00000020 cb8d2640 00000000 00000004 00000002 00000002 [ 206.542765] fe20: cb8d2660 00000000 cb9c7c50 cc97fe48 c08d9353 c085fab2 400d0033 ffffffff [ 206.542778] [<c0100b65>] (__irq_svc) from [<c085fab2>] (netlink_has_listeners+0x4a/0x58) [ 206.542791] [<c085fab2>] (netlink_has_listeners) from [<c08d9353>] (xfrm_replay_advance+0x3b/0x68) [ 206.542804] [<c08d9353>] (xfrm_replay_advance) from [<c08d6e25>] (xfrm_input+0x389/0xce0) [ 206.542819] [<c08d6e25>] (xfrm_input) from [<bf86d075>] (crypto_finalize_request+0x31/0x7c [crypto_engine]) [ 206.542838] [<bf86d075>] (crypto_finalize_request [crypto_engine]) from [<bf878afd>] (sun8i_ce_handle_cipher_request+0x295/0x5b4 [sun8i_ce]) [ 206.542852] [<bf878afd>] (sun8i_ce_handle_cipher_request [sun8i_ce]) from [<bf86d407>] (crypto_pump_work+0x123/0xd1c [crypto_engine]) [ 206.542866] [<bf86d407>] (crypto_pump_work [crypto_engine]) from [<c01347c7>] (kthread_worker_fn+0x6f/0x13c) [ 206.542879] [<c01347c7>] (kthread_worker_fn) from [<c01354f3>] (kthread+0xeb/0x10c) [ 206.542888] [<c01354f3>] (kthread) from [<c0100159>] (ret_from_fork+0x11/0x38) [ 206.542893] Exception stack(0xcc97ffb0 to 0xcc97fff8) [ 206.542899] ffa0: 00000000 00000000 00000000 00000000 [ 206.542907] ffc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 [ 206.542914] ffe0: 00000000 00000000 00000000 00000000 00000013 00000000 [ 269.559043] rcu: INFO: rcu_sched self-detected stall on CPU [ 269.559067] rcu: 0-....: (21003 ticks this GP) idle=06a/1/0x40000004 softirq=6817/6817 fqs=10441 [ 269.559073] (t=21005 jiffies g=11233 q=456) [ 269.559079] NMI backtrace for cpu 0 [ 269.559089] CPU: 0 PID: 309 Comm: 1c15000.crypto- Tainted: G C 5.9.1-sunxi #20.08.14 [ 269.559092] Hardware name: Allwinner sun8i Family [ 269.559122] [<c010d415>] (unwind_backtrace) from [<c01097a5>] (show_stack+0x11/0x14) [ 269.559136] [<c01097a5>] (show_stack) from [<c0574801>] (dump_stack+0x75/0x84) [ 269.559152] [<c0574801>] (dump_stack) from [<c0579d33>] (nmi_cpu_backtrace+0x6b/0x94) [ 269.559164] [<c0579d33>] (nmi_cpu_backtrace) from [<c0579e15>] (nmi_trigger_cpumask_backtrace+0xb9/0xe0) [ 269.559178] [<c0579e15>] (nmi_trigger_cpumask_backtrace) from [<c01706ab>] (rcu_dump_cpu_stacks+0xab/0xc8) [ 269.559192] [<c01706ab>] (rcu_dump_cpu_stacks) from [<c016fb23>] (rcu_sched_clock_irq+0x5e3/0x7ac) [ 269.559205] [<c016fb23>] (rcu_sched_clock_irq) from [<c0176641>] (update_process_times+0x29/0x70) [ 269.559217] [<c0176641>] (update_process_times) from [<c0184b57>] (tick_sched_timer+0x37/0x74) [ 269.559229] [<c0184b57>] (tick_sched_timer) from [<c0177089>] (__hrtimer_run_queues+0xf1/0x250) [ 269.559241] [<c0177089>] (__hrtimer_run_queues) from [<c0177ab1>] (hrtimer_interrupt+0xcd/0x1fc) [ 269.559255] [<c0177ab1>] (hrtimer_interrupt) from [<c07a9c7b>] (arch_timer_handler_phys+0x27/0x2c) [ 269.559270] [<c07a9c7b>] (arch_timer_handler_phys) from [<c0165acb>] (handle_percpu_devid_irq+0x53/0x1a0) [ 269.559287] [<c0165acb>] (handle_percpu_devid_irq) from [<c01611b5>] (generic_handle_irq+0x29/0x34) [ 269.559299] [<c01611b5>] (generic_handle_irq) from [<c0161671>] (__handle_domain_irq+0x41/0x80) [ 269.559310] [<c0161671>] (__handle_domain_irq) from [<c058628f>] (gic_handle_irq+0x3b/0x70) [ 269.559322] [<c058628f>] (gic_handle_irq) from [<c0100b65>] (__irq_svc+0x65/0x94) [ 269.559327] Exception stack(0xcc97fa20 to 0xcc97fa68) [ 269.559336] fa20: cb8d2660 000064b2 000064b1 000064b1 cdf2b0c0 cb8d2640 00000000 00000032 [ 269.559345] fa40: 00000000 00000002 cb8d2660 00000000 00000004 cc97fa70 c08d6bd3 c0953d84 [ 269.559350] fa60: 800d0133 ffffffff [ 269.559363] [<c0100b65>] (__irq_svc) from [<c0953d84>] (_raw_spin_lock+0x28/0x38) [ 269.559379] [<c0953d84>] (_raw_spin_lock) from [<c08d6bd3>] (xfrm_input+0x137/0xce0) [ 269.559391] [<c08d6bd3>] (xfrm_input) from [<c08cb1cb>] (xfrm4_esp_rcv+0x27/0x38) [ 269.559403] [<c08cb1cb>] (xfrm4_esp_rcv) from [<c0877a0f>] (ip_protocol_deliver_rcu+0x27/0x214) [ 269.559414] [<c0877a0f>] (ip_protocol_deliver_rcu) from [<c0877c37>] (ip_local_deliver_finish+0x3b/0x40) [ 269.559424] [<c0877c37>] (ip_local_deliver_finish) from [<c0877cd5>] (ip_local_deliver+0x99/0xa4) [ 269.559433] [<c0877cd5>] (ip_local_deliver) from [<c0877d5f>] (ip_rcv+0x7f/0x84) [ 269.559448] [<c0877d5f>] (ip_rcv) from [<c0815295>] (__netif_receive_skb_core+0x41d/0xa78) [ 269.559461] [<c0815295>] (__netif_receive_skb_core) from [<c0815c6b>] (__netif_receive_skb_list_core+0x97/0x130) [ 269.559471] [<c0815c6b>] (__netif_receive_skb_list_core) from [<c0815e33>] (netif_receive_skb_list_internal+0x12f/0x1e0) [ 269.559481] [<c0815e33>] (netif_receive_skb_list_internal) from [<c0815fc9>] (gro_normal_list.part.0+0x15/0x24) [ 269.559490] [<c0815fc9>] (gro_normal_list.part.0) from [<c0816939>] (napi_complete_done+0x85/0x160) [ 269.559525] [<c0816939>] (napi_complete_done) from [<bf8d4dd5>] (r8152_poll+0x4a9/0x51c [r8152]) [ 269.559547] [<bf8d4dd5>] (r8152_poll [r8152]) from [<c0816ad1>] (net_rx_action+0xbd/0x2c4) [ 269.559557] [<c0816ad1>] (net_rx_action) from [<c0101367>] (__do_softirq+0xcf/0x260) [ 269.559569] [<c0101367>] (__do_softirq) from [<c0120df5>] (irq_exit+0x79/0x98) [ 269.559578] [<c0120df5>] (irq_exit) from [<c0161675>] (__handle_domain_irq+0x45/0x80) [ 269.559588] [<c0161675>] (__handle_domain_irq) from [<c058628f>] (gic_handle_irq+0x3b/0x70) [ 269.559598] [<c058628f>] (gic_handle_irq) from [<c0100b65>] (__irq_svc+0x65/0x94) [ 269.559602] Exception stack(0xcc97fdf8 to 0xcc97fe40) [ 269.559607] fde0: 000000c3 00000000 [ 269.559616] fe00: c9aca488 00000004 00000020 cb8d2640 00000000 00000004 00000002 00000002 [ 269.559626] fe20: cb8d2660 00000000 cb9c7c50 cc97fe48 c08d9353 c085fab2 400d0033 ffffffff [ 269.559639] [<c0100b65>] (__irq_svc) from [<c085fab2>] (netlink_has_listeners+0x4a/0x58) [ 269.559652] [<c085fab2>] (netlink_has_listeners) from [<c08d9353>] (xfrm_replay_advance+0x3b/0x68) [ 269.559665] [<c08d9353>] (xfrm_replay_advance) from [<c08d6e25>] (xfrm_input+0x389/0xce0) [ 269.559679] [<c08d6e25>] (xfrm_input) from [<bf86d075>] (crypto_finalize_request+0x31/0x7c [crypto_engine]) [ 269.559696] [<bf86d075>] (crypto_finalize_request [crypto_engine]) from [<bf878afd>] (sun8i_ce_handle_cipher_request+0x295/0x5b4 [sun8i_ce]) [ 269.559710] [<bf878afd>] (sun8i_ce_handle_cipher_request [sun8i_ce]) from [<bf86d407>] (crypto_pump_work+0x123/0xd1c [crypto_engine]) [ 269.559724] [<bf86d407>] (crypto_pump_work [crypto_engine]) from [<c01347c7>] (kthread_worker_fn+0x6f/0x13c) [ 269.559736] [<c01347c7>] (kthread_worker_fn) from [<c01354f3>] (kthread+0xeb/0x10c) [ 269.559746] [<c01354f3>] (kthread) from [<c0100159>] (ret_from_fork+0x11/0x38) [ 269.559750] Exception stack(0xcc97ffb0 to 0xcc97fff8) [ 269.559756] ffa0: 00000000 00000000 00000000 00000000 [ 269.559765] ffc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 [ 269.559772] ffe0: 00000000 00000000 00000000 00000000 00000013 00000000 root@orangepi-r1:~# 0 Quote
Solution 5kft Posted November 11, 2020 Solution Posted November 11, 2020 I'm not an expert in this area whatsoever, but this problem looks like an upstream kernel issue, and perhaps is related to this fallback deadlock fix? https://git.kernel.org/pub/scm/linux/kernel/git/herbert/cryptodev-2.6.git/commit/?id=a2715fbdc6fc387e85211df917a4778761ec693d The posted fix patch is only applicable to kernel v5.10; just in case you want to give it a try, I've uploaded a ToT test build of v5.10-rc3 with this kernel patch applied: https://drive.google.com/file/d/1Eg_cn3bEYsRFZ3vrP9Mc0fxJjPREczcW/view. Again, I'm not sure if this will fix the problem, but there are a number of changes in cryptodev here compared to kernel v5.9, so it might be worth a try. 1 Quote
Ford_Prefect Posted November 12, 2020 Author Posted November 12, 2020 Hi, Thanks for your work, I tested your kernel packages yesterday and everything works flawlessly now. I get about 40 to 50 MBps throughput with Ipsec now without stalling and "breaking" the Interface. I am happy, thanks alot! Cheers Ford Prefect Quote I'm not an expert in this area whatsoever, but this problem looks like an upstream kernel issue, and perhaps is related to this fallback deadlock fix? https://git.kernel.org/pub/scm/linux/kernel/git/herbert/cryptodev-2.6.git/commit/?id=a2715fbdc6fc387e85211df917a4778761ec693d 2 Quote
5kft Posted November 12, 2020 Posted November 12, 2020 5 hours ago, Ford_Prefect said: Hi, Thanks for your work, I tested your kernel packages yesterday and everything works flawlessly now. I get about 40 to 50 MBps throughput with Ipsec now without stalling and "breaking" the Interface. I am happy, thanks alot! Cheers Ford Prefect Wonderful - this is great to hear! It is a new patch, so keep an eye on the pull requests for the kernels regarding this change, I'm sure it will get pulled into v5.10 soon (and hopefully backported to v5.9 as well). 0 Quote
Ford_Prefect Posted December 20, 2020 Author Posted December 20, 2020 (edited) On 11/12/2020 at 4:10 PM, 5kft said: Wonderful - this is great to hear! It is a new patch, so keep an eye on the pull requests for the kernels regarding this change, I'm sure it will get pulled into v5.10 soon (and hopefully backported to v5.9 as well). strange thing happened.... even I have pinned the current kernel in apt (and it is still there) after some apt upgrades the same thing happens again as in the beginning.... The device was powered on 24/7 since November 12th and worked flawlessly...... and now this.... Cannot explain why :-/ Cheers Ford Edited December 20, 2020 by Ford_Prefect 0 Quote
Igor Posted December 21, 2020 Posted December 21, 2020 13 hours ago, Ford_Prefect said: even I have pinned the current kernel in apt If we look together into the logs, we might spot the problem: armbianmonitor -u 0 Quote
Ford_Prefect Posted December 22, 2020 Author Posted December 22, 2020 (edited) Hi, I just got some time and attached my serial port again....: root@orangepi-r1:~# ping 192.168.202.1 PING 192.168.202.1 (192.168.202.1) 56(84) bytes of data. 64 bytes from 192.168.202.1: icmp_seq=1 ttl=64 time=26.2 ms 64 bytes from 192.168.202.1: icmp_seq=2 ttl=64 time=25.2 ms 64 bytes from 192.168.202.1: icmp_seq=3 ttl=64 time=27.0 ms ^C --- 192.168.202.1 ping statistics --- 3 packets transmitted, 3 received, 0% packet loss, time 2003ms rtt min/avg/max/mdev = 25.205/26.143/27.000/0.735 ms root@orangepi-r1:~# iperf3 -c 192.168.202.1 Connecting to host 192.168.202.1, port 5201 [ 5] local 192.168.202.2 port 51956 connected to 192.168.202.1 port 5201 [ ID] Interval Transfer Bitrate Retr Cwnd [ 5] 0.00-1.00 sec 517 KBytes 4.23 Mbits/sec 1 1.22 KBytes [ 5] 1.00-2.00 sec 0.00 Bytes 0.00 bits/sec 0 1.22 KBytes [ 5] 2.00-3.00 sec 0.00 Bytes 0.00 bits/sec 0 1.22 KBytes [ 5] 3.00-4.00 sec 0.00 Bytes 0.00 bits/sec 0 1.22 KBytes [ 5] 4.00-5.00 sec 0.00 Bytes 0.00 bits/sec 0 1.22 KBytes CTRL-A Z for help | 115200 8N1 | NOR | Minicom 2.7.1 | VT102 | Offline | ttyUSB0 I used the kernel from November 11th which 5kft has kindly provided and worked flawlessly untile a couple of days when apt meant he has to update uboot an the kernel to a newer version despite i set it "on hold".... but even a downgrade does not change anything. Linux orangepi-r1 5.10.0-rc3-sunxi #trunk SMP Wed Nov 11 15:03:40 UTC 2020 armv7l GNU/Linux root@orangepi-r1:~# Since Armbianmonitor -U still does not hide my personal IPv6 prefix I uploaded the edited output here: http://104.168.35.206/ietooyai EDIT: wait..... logging in via ssh and let the serial console open for a dmesg -w i got this, whet simply pinging over my xfrm ipsec tunnel: [ 268.956055] sun8i-ce 1c15000.crypto: Fallback for ecb-aes-sun8i-ce is ecb-aes-neonbs [ 268.956194] sun8i-ce 1c15000.crypto: Fallback for ecb-aes-sun8i-ce is ecb-aes-neonbs [ 268.956332] sun8i-ce 1c15000.crypto: Fallback for ecb-aes-sun8i-ce is ecb-aes-neonbs [ 395.756162] sun8i-ce 1c15000.crypto: Fallback for cbc-aes-sun8i-ce is cbc(aes-generic) [ 395.756973] sun8i-ce 1c15000.crypto: Fallback for cbc-aes-sun8i-ce is cbc(aes-generic) [ 400.555283] NOHZ tick-stop error: Non-RCU local softirq work is pending, handler #08!!! [ 401.556432] NOHZ tick-stop error: Non-RCU local softirq work is pending, handler #08!!! [ 402.562189] NOHZ tick-stop error: Non-RCU local softirq work is pending, handler #08!!! [ 403.559759] NOHZ tick-stop error: Non-RCU local softirq work is pending, handler #08!!! [ 404.560813] NOHZ tick-stop error: Non-RCU local softirq work is pending, handler #08!!! [ 405.017837] sun8i-ce 1c15000.crypto: Fallback for cbc-aes-sun8i-ce is cbc(aes-generic) [ 405.018398] sun8i-ce 1c15000.crypto: Fallback for cbc-aes-sun8i-ce is cbc(aes-generic) [ 405.562329] NOHZ tick-stop error: Non-RCU local softirq work is pending, handler #08!!! [ 406.563600] NOHZ tick-stop error: Non-RCU local softirq work is pending, handler #08!!! [ 407.565302] NOHZ tick-stop error: Non-RCU local softirq work is pending, handler #08!!! [ 408.566290] NOHZ tick-stop error: Non-RCU local softirq work is pending, handler #08!!! [ 409.570524] NOHZ tick-stop error: Non-RCU local softirq work is pending, handler #08!!! When starting my iperf3 test to the other site of the ipsec tunnel this happenens...: [ 540.338679] sched: RT throttling activated [ 560.110930] rcu: INFO: rcu_sched self-detected stall on CPU [ 560.110977] rcu: 2-....: (5250 ticks this GP) idle=9f6/1/0x40000004 softirq=10405/10406 fqs=2582 [ 560.110994] (t=5251 jiffies g=16009 q=76) [ 560.111009] NMI backtrace for cpu 2 [ 560.111032] CPU: 2 PID: 321 Comm: 1c15000.crypto- Tainted: G C 5.10.0-rc3-sunxi #trunk [ 560.111043] Hardware name: Allwinner sun8i Family [ 560.111098] [<c010cbbd>] (unwind_backtrace) from [<c010966d>] (show_stack+0x11/0x14) [ 560.111131] [<c010966d>] (show_stack) from [<c0977aff>] (dump_stack+0x75/0x82) [ 560.111166] [<c0977aff>] (dump_stack) from [<c0592063>] (nmi_cpu_backtrace+0x8f/0xb0) [ 560.111198] [<c0592063>] (nmi_cpu_backtrace) from [<c0592139>] (nmi_trigger_cpumask_backtrace+0xb5/0xe0) [ 560.111227] [<c0592139>] (nmi_trigger_cpumask_backtrace) from [<c0972609>] (rcu_dump_cpu_stacks+0xab/0xc8) [ 560.111260] [<c0972609>] (rcu_dump_cpu_stacks) from [<c0171a65>] (rcu_sched_clock_irq+0x5c5/0x794) [ 560.111294] [<c0171a65>] (rcu_sched_clock_irq) from [<c0178bc7>] (update_process_times+0x4f/0x78) [ 560.111325] [<c0178bc7>] (update_process_times) from [<c018723b>] (tick_sched_timer+0x37/0x74) [ 560.111356] [<c018723b>] (tick_sched_timer) from [<c01795b7>] (__hrtimer_run_queues+0xdf/0x224) [ 560.111387] [<c01795b7>] (__hrtimer_run_queues) from [<c0179fa5>] (hrtimer_interrupt+0xcd/0x200) [ 560.111422] [<c0179fa5>] (hrtimer_interrupt) from [<c07c532f>] (arch_timer_handler_phys+0x27/0x2c) [ 560.111456] [<c07c532f>] (arch_timer_handler_phys) from [<c0166763>] (handle_percpu_devid_irq+0x53/0x184) [ 560.111486] [<c0166763>] (handle_percpu_devid_irq) from [<c0161f1d>] (generic_handle_irq+0x29/0x34) [ 560.111513] [<c0161f1d>] (generic_handle_irq) from [<c01623d9>] (__handle_domain_irq+0x41/0x80) [ 560.111542] [<c01623d9>] (__handle_domain_irq) from [<c059e5db>] (gic_handle_irq+0x63/0x74) [ 560.111570] [<c059e5db>] (gic_handle_irq) from [<c0100b65>] (__irq_svc+0x65/0x94) [ 560.111584] Exception stack(0xcbab1aa0 to 0xcbab1ae8) [ 560.111609] 1aa0: ca9546e0 00000a01 00000a00 00000a00 cd337600 ca9546c0 00000000 00000032 [ 560.111632] 1ac0: 00000000 00000002 ca9546e0 00000000 00000007 cbab1af0 c08f5673 c09818cc [ 560.111645] 1ae0: 800f0133 ffffffff [ 560.111676] [<c0100b65>] (__irq_svc) from [<c09818cc>] (_raw_spin_lock+0x28/0x38) [ 560.111705] [<c09818cc>] (_raw_spin_lock) from [<c08f5673>] (xfrm_input+0x137/0xce4) [ 560.111736] [<c08f5673>] (xfrm_input) from [<c08e9b33>] (xfrm4_esp_rcv+0x27/0x38) [ 560.111769] [<c08e9b33>] (xfrm4_esp_rcv) from [<c0895a97>] (ip_protocol_deliver_rcu+0x27/0x214) [ 560.111799] [<c0895a97>] (ip_protocol_deliver_rcu) from [<c0895cbf>] (ip_local_deliver_finish+0x3b/0x44) [ 560.111827] [<c0895cbf>] (ip_local_deliver_finish) from [<c0895d1d>] (ip_local_deliver+0x55/0xbc) [ 560.111855] [<c0895d1d>] (ip_local_deliver) from [<c0895e0b>] (ip_rcv+0x87/0x94) [ 560.111884] [<c0895e0b>] (ip_rcv) from [<c08301ab>] (__netif_receive_skb_core+0x3cb/0xaac) [ 560.111912] [<c08301ab>] (__netif_receive_skb_core) from [<c0830c0f>] (__netif_receive_skb_list_core+0x97/0x130) [ 560.111937] [<c0830c0f>] (__netif_receive_skb_list_core) from [<c0830dd7>] (netif_receive_skb_list_internal+0x12f/0x1e4) [ 560.111963] [<c0830dd7>] (netif_receive_skb_list_internal) from [<c0830f61>] (gro_normal_list.part.0+0x15/0x24) [ 560.111988] [<c0830f61>] (gro_normal_list.part.0) from [<c08318cd>] (napi_complete_done+0x85/0x160) [ 560.112054] [<c08318cd>] (napi_complete_done) from [<bf962dd9>] (r8152_poll+0x4a9/0x51c [r8152]) [ 560.112117] [<bf962dd9>] (r8152_poll [r8152]) from [<c0831a65>] (net_rx_action+0xbd/0x2bc) [ 560.112143] [<c0831a65>] (net_rx_action) from [<c0101367>] (__do_softirq+0xcf/0x26c) [ 560.112169] [<c0101367>] (__do_softirq) from [<c0120799>] (irq_exit+0x79/0x98) [ 560.112195] [<c0120799>] (irq_exit) from [<c01623dd>] (__handle_domain_irq+0x45/0x80) [ 560.112222] [<c01623dd>] (__handle_domain_irq) from [<c059e5db>] (gic_handle_irq+0x63/0x74) [ 560.112247] [<c059e5db>] (gic_handle_irq) from [<c0100b65>] (__irq_svc+0x65/0x94) [ 560.112261] Exception stack(0xcbab1e70 to 0xcbab1eb8) [ 560.112278] 1e60: 00000000 00000000 ca855f88 0000000c [ 560.112301] 1e80: cd337b40 ca9546c0 00000000 00000004 00000002 00000002 ca9546e0 00000000 [ 560.112322] 1ea0: c9fc6250 cbab1ec0 c08f78bd c08f58c4 000f0033 ffffffff [ 560.112347] [<c0100b65>] (__irq_svc) from [<c08f58c4>] (xfrm_input+0x388/0xce4) [ 560.112379] [<c08f58c4>] (xfrm_input) from [<bf89a075>] (crypto_finalize_request+0x31/0x7c [crypto_engine]) [ 560.112420] [<bf89a075>] (crypto_finalize_request [crypto_engine]) from [<bf952b6f>] (sun8i_ce_cipher_run+0x27/0x2c [sun8i_ce]) [ 560.112456] [<bf952b6f>] (sun8i_ce_cipher_run [sun8i_ce]) from [<bf89a407>] (crypto_pump_work+0x123/0xd1c [crypto_engine]) [ 560.112489] [<bf89a407>] (crypto_pump_work [crypto_engine]) from [<c013421b>] (kthread_worker_fn+0x6f/0x13c) [ 560.112519] [<c013421b>] (kthread_worker_fn) from [<c0134f3b>] (kthread+0xeb/0x10c) [ 560.112545] [<c0134f3b>] (kthread) from [<c0100159>] (ret_from_fork+0x11/0x38) [ 560.112558] Exception stack(0xcbab1fb0 to 0xcbab1ff8) [ 560.112575] 1fa0: 00000000 00000000 00000000 00000000 [ 560.112597] 1fc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 [ 560.112616] 1fe0: 00000000 00000000 00000000 00000000 00000013 00000000 ---> and there it hangs Cheers Ford Edited December 22, 2020 by Ford_Prefect 0 Quote
Ford_Prefect Posted December 23, 2020 Author Posted December 23, 2020 BTW: I tried to use the ethernet devices vice versa and still, the same happens... 0 Quote
5kft Posted December 23, 2020 Posted December 23, 2020 It might be worth trying to reinstall the original posted -rc3 version again (esp. the dtb and image debs), just to see if that helps? (Just force an install via dpkg -i *.deb) 0 Quote
Ford_Prefect Posted December 23, 2020 Author Posted December 23, 2020 19 hours ago, Ford_Prefect said: Linux orangepi-r1 5.10.0-rc3-sunxi #trunk SMP Wed Nov 11 15:03:40 UTC 2020 armv7l GNU/Linux root@orangepi-r1:~# Hi 5kft, I did..... and I also uninstalled ii armbian-config 21.11.4 all Armbian configuration utility ii armbian-firmware 21.02.0-trunk.29 all Linux firmware ii linux-buster-root-current-orangepi-r1 21.02.0-trunk.30 armhf Armbian tweaks for buster on orangepi-r1 (current branch) ii linux-dtb-current-sunxi 21.02.0-trunk.24 armhf Linux DTB, version 5.9.15-sunxi armhf ii linux-image-current-sunxi 21.02.0-trunk.24 armhf Linux kernel, version 5.9.15-sunxi ii linux-libc-dev:armhf 5.9.11-1 armhf Linux support headers for userspace development ii linux-u-boot-orangepi-r1-current 21.02.0-trunk.12 armhf Uboot loader 2020.10 So currently these are installed, and no change :-( ii linux-image-dev-sunxi 20.11.0-trunk armhf Linux kernel, version 5.10.0-rc3-sunxi ii linux-dtb-dev-sunxi 20.11.0-trunk armhf Linux DTB, version 5.10.0-rc3-sunxi ii linux-headers-dev-sunxi 20.11.0-trunk armhf Linux kernel headers for 5.10.0-rc3-sunxi on Wonder what I am missing? something else must have been broken when doing a apt upgrade... Cheers, Ford 0 Quote
5kft Posted December 23, 2020 Posted December 23, 2020 Unfortunately I'm not an expert in RCU stalls (https://www.kernel.org/doc/Documentation/RCU/stallwarn.txt). Do you have other processes running on the device that could be impacting the system? E.g., what does "top" show while you try to use networking? 0 Quote
Ford_Prefect Posted December 23, 2020 Author Posted December 23, 2020 there is nothing despite 'normal background processes' running in the background. This device is only connecting to my ipsec gateway and - if it works, should do some basic routing. Currently the device is not running, but the most cpu intense background activity might be autoupdate apt or an updatedb of locate.... Nearly all cpu power is going in the encryption in that moment. Cheers, FP 0 Quote
Ford_Prefect Posted December 31, 2020 Author Posted December 31, 2020 Hi, has no one an Idea what I could try? Installing "the old" dtb's and kernels does not make any difference. Changing to a nightly build doesn't change anything either. Regaring arm based CPUs you don't find too much information about the 'CPU stalled' Problem, though :-( Cheers + Happy new Year Ford. 0 Quote
Guidalpi Posted October 28, 2021 Posted October 28, 2021 Hello, I´ve just upgraded my OrangePiPcPlus xenial armbian (3.x kernel) to bionic and I´m facing the same kernel freeze problem when using ipsec (strongswan). My system had more than 200 days uptime and since I´ve upgraded to kernel 5.10 I´m facing these problems. First I´ve upgraded Ubuntu (do-release-upgrade) and had no problems (more than a week uptime). Since I´ve changed the kernel version, the system started freezing daily. Have you managed how to avoid those stalls in your configuration? Otherwise, I´ll try to downgrade to 3.x kernel (even if it is not supported anymore). Regards, Guilherme. On 12/31/2020 at 4:11 PM, Ford_Prefect said: Hi, has no one an Idea what I could try? Installing "the old" dtb's and kernels does not make any difference. Changing to a nightly build doesn't change anything either. Regaring arm based CPUs you don't find too much information about the 'CPU stalled' Problem, though :-( Cheers + Happy new Year Ford. 0 Quote
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.