← Back to team overview

canonical-ubuntu-qa team mailing list archive

[Bug 2039816] [NEW] Regression for net:vrf-xfrm-tests.sh with 5.15 kernel on ARM64 node scobee-kernel

 

Public bug reported:

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 this is 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

** Affects: ubuntu-kernel-tests
     Importance: Undecided
         Status: New


** Tags: 5.15 arm64 focal jammy ubuntu-kernel-selftests

** Summary changed:

- Regression for net:vrf-xfrm-tests.sh with F-hwe-5.15 lowlatency on scobee-kernel
+ Regression for net:vrf-xfrm-tests.sh with 5.15 kernel on scobee-kernel

** Summary changed:

- Regression for net:vrf-xfrm-tests.sh with 5.15 kernel on scobee-kernel
+ Regression for net:vrf-xfrm-tests.sh with 5.15 kernel on ARM64 node scobee-kernel

** Tags added: 5.15 arm64 focal jammy ubuntu-kernel-selftests

** Description changed:

  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
+  * 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.
+ So it looks like this is 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
+  * 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

-- 
You received this bug notification because you are a member of Canonical
Platform QA Team, which is subscribed to ubuntu-kernel-tests.
https://bugs.launchpad.net/bugs/2039816

Title:
  Regression for net:vrf-xfrm-tests.sh with 5.15 kernel on ARM64 node
  scobee-kernel

Status in ubuntu-kernel-tests:
  New

Bug description:
  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 this is 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

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu-kernel-tests/+bug/2039816/+subscriptions



Follow ups