Issue found on ARM64 node scobee-kernel with:
* J-5.15.0-86.95 lowlatency
* 5.15.0-85.95~20.04.2 generic
* F-5.15.0-86.95~20.04.1 lowlatency
* F-5.15.0-87.96~20.04.1 lowlatency-64k
Test failed with:
$ sudo ./vrf-xfrm-tests.sh
No qdisc on VRF device
TEST: IPv4 no xfrm policy [ OK ]
TEST: IPv6 no xfrm policy [ OK ]
TEST: IPv4 xfrm policy based on address [FAIL]
TEST: IPv6 xfrm policy based on address [FAIL]
TEST: IPv6 xfrm policy with VRF in selector [ OK ]
TEST: IPv4 xfrm policy with xfrm device [FAIL]
TEST: IPv6 xfrm policy with xfrm device [FAIL]
netem qdisc on VRF device
TEST: IPv4 no xfrm policy [ OK ]
TEST: IPv6 no xfrm policy [ OK ]
TEST: IPv4 xfrm policy based on address [FAIL]
TEST: IPv6 xfrm policy based on address [FAIL]
TEST: IPv6 xfrm policy with VRF in selector [ OK ]
TEST: IPv4 xfrm policy with xfrm device [FAIL]
TEST: IPv6 xfrm policy with xfrm device [FAIL]
Tests passed: 6
Tests failed: 8
And this issue does not exist with the following combination:
* F-generic-5.15.0-86.96~20.04.1 howzit-kernel
* F-generic-5.15.0-86.96~20.04.1 wright-kernel
* F-generic-64k-5.15.0-85.95~20.04.2 kopter-kernel
* F-lowlatency-5.15.0-88.98~20.04.1 howzit-kernel
* F-lowlatency-5.15.0-85.94 starmie-kernel
* F-lowlatency-64k-5.15.0-85.94~20.04.1 howzit-kernel
* J-lowlatency-64k-5.15.0-85.94 starmie-kernel
* J-lowlatency-64k-5.15.0-86.95 howzit-kernel
So it looks like hardware related.
And the cause seems to be commit cb43c60 (" selftests: net: vrf-xfrm-tests: change authentication and encryption algos"), which lands on the Jammy tree since:
* Ubuntu-5.15.0-85.95
* Ubuntu-lowlatency-5.15.0-85.94
With this commit reverted, this test can pass on node scobee-kernel with 5.15.0-87-lowlatency-64k
Issue found on ARM64 node scobee-kernel with: 85.95~20. 04.2 generic 0-86.95~ 20.04.1 lowlatency 0-87.96~ 20.04.1 lowlatency-64k
* J-5.15.0-86.95 lowlatency
* 5.15.0-
* F-5.15.
* F-5.15.
Test failed with:
$ sudo ./vrf-xfrm-tests.sh
No qdisc on VRF device
TEST: IPv4 no xfrm policy [ OK ]
TEST: IPv6 no xfrm policy [ OK ]
TEST: IPv4 xfrm policy based on address [FAIL]
TEST: IPv6 xfrm policy based on address [FAIL]
TEST: IPv6 xfrm policy with VRF in selector [ OK ]
TEST: IPv4 xfrm policy with xfrm device [FAIL]
TEST: IPv6 xfrm policy with xfrm device [FAIL]
netem qdisc on VRF device
TEST: IPv4 no xfrm policy [ OK ]
TEST: IPv6 no xfrm policy [ OK ]
TEST: IPv4 xfrm policy based on address [FAIL]
TEST: IPv6 xfrm policy based on address [FAIL]
TEST: IPv6 xfrm policy with VRF in selector [ OK ]
TEST: IPv4 xfrm policy with xfrm device [FAIL]
TEST: IPv6 xfrm policy with xfrm device [FAIL]
Tests passed: 6
Tests failed: 8
And this issue does not exist with the following combination: 5.15.0- 86.96~20. 04.1 howzit-kernel 5.15.0- 86.96~20. 04.1 wright-kernel 64k-5.15. 0-85.95~ 20.04.2 kopter-kernel 5.15.0- 88.98~20. 04.1 howzit-kernel 5.15.0- 85.94 starmie-kernel 64k-5.15. 0-85.94~ 20.04.1 howzit-kernel 64k-5.15. 0-85.94 starmie-kernel 64k-5.15. 0-86.95 howzit-kernel
* F-generic-
* F-generic-
* F-generic-
* F-lowlatency-
* F-lowlatency-
* F-lowlatency-
* J-lowlatency-
* J-lowlatency-
So it looks like hardware related.
And the cause seems to be commit cb43c60 (" selftests: net: vrf-xfrm-tests: change authentication and encryption algos"), which lands on the Jammy tree since: lowlatency- 5.15.0- 85.94
* Ubuntu-5.15.0-85.95
* Ubuntu-
With this commit reverted, this test can pass on node scobee-kernel with 5.15.0- 87-lowlatency- 64k