Orange Pi R1 IPSec freezing Problem with large amounts of traffic / e.g. iperf3

[Ford_Prefect]

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

[5kft]

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.

[Igor]

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?

[guidol]

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 

[guidol]

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)
 

[5kft]

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?

 

[guidol]

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?

[Ford_Prefect]

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:~# 

 

[Ford_Prefect]

 

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

 

[5kft]

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).

[Ford_Prefect]

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

[Igor]

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

 

[Ford_Prefect]

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

[Ford_Prefect]

BTW:  I tried to use the ethernet devices vice versa and still, the same happens...

 

[5kft]

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)

[Ford_Prefect]

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 

 

 

 

[5kft]

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?

[Ford_Prefect]

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

 

[Ford_Prefect]

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.

 

 

[Guidalpi]

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.