On 1/8/24 22:02, Ilya Maximets wrote: > On 1/8/24 17:22, Eelco Chaudron wrote: >> >> >> On 8 Jan 2024, at 17:07, Ilya Maximets wrote: >> >>> On 1/8/24 17:01, Eelco Chaudron wrote: >>>> >>>> >>>> On 2 Jan 2024, at 12:19, Ilya Maximets wrote: >>>> >>>>> On 12/19/23 13:41, Eelco Chaudron wrote: >>>>>> Updating this image is a requirement for the kernel system-traffic >>>>>> tests to pass on Ubuntu. In addition, 20.04 might be replaced, >>>>>> as soon as 24.04 comes out. Or we need to do this when it becomes >>>>>> EOL in April 2025. >>>>>> >>>>>> Signed-off-by: Eelco Chaudron <[email protected]> >>>>>> Acked-by: Simon Horman <[email protected]> >>>>>> --- >>>>>> .github/workflows/build-and-test.yml | 4 ++-- >>>>>> 1 file changed, 2 insertions(+), 2 deletions(-) >>>>>> >>>>>> diff --git a/.github/workflows/build-and-test.yml >>>>>> b/.github/workflows/build-and-test.yml >>>>>> index 5d441157c..acb57ac46 100644 >>>>>> --- a/.github/workflows/build-and-test.yml >>>>>> +++ b/.github/workflows/build-and-test.yml >>>>>> @@ -12,7 +12,7 @@ jobs: >>>>>> name: dpdk gcc >>>>>> outputs: >>>>>> dpdk_key: ${{ steps.gen_dpdk_key.outputs.key }} >>>>>> - runs-on: ubuntu-20.04 >>>>>> + runs-on: ubuntu-22.04 >>>>>> timeout-minutes: 30 >>>>>> >>>>>> steps: >>>>>> @@ -89,7 +89,7 @@ jobs: >>>>>> TESTSUITE: ${{ matrix.testsuite }} >>>>>> >>>>>> name: linux ${{ join(matrix.*, ' ') }} >>>>>> - runs-on: ubuntu-20.04 >>>>>> + runs-on: ubuntu-22.04 >>>>>> timeout-minutes: 30 >>>>>> >>>>>> strategy: >>>>>> >>>>> >>>>> Hi, Eelco. Could you also apply this to branches down to 2.17? >>>>> We'll need to keep the image updated there as well since they are >>>>> going to be supported likely beyond 20.04 availability in GHA. >>>>> >>>>> Assuming these branches should work fine with 22.04 (I didn't check). >>>> >>>> I was trying 2.17 and up, and it works from 3.1 as we ditched the kernel >>>> compilation. >>>> On 2.17 and 3.0: >>> >>> Hmm. We're not building the kernel module on 3.0. Are you sure? >> >> It builds 5.3 for AFXDP, >> https://github.com/chaudron/ovs/actions/runs/7449650175/job/20266758856 > > Ah, makes sense. > > I think that we can move this one to 5.4. We're only using > 5.3 because it was the first kernel introducing AF_XDP and > it doesn't support needs_wakeup functionality and we wanted > to test this code path for some reason. However, users of > AF_XDP should not really use that kernel anyway, it is way > too old and doesn't support important functionality like the > 'needs_wakeup' flags. Switching to 5.4 should be fine in > this case. And we should actually make needs_wakeup support > mandatory at some point and remove the conditional compilation. > Switching to 5.4 should cover the 3.0 branch. 5.4 is also > a longterm release. > > For the 2.17, it seems the build fails on kernel 3.16. > 3.16 got its final release in 2020 along with the end of life > of Debian 8. So, I think, it's fine to just remove 3.16 > from the test matrix.
The 'test 3.16' tests do not really require the kernel, i.e. do not rely on the kernel version much. Can potentially be bumped to 4.14, which is the currently oldest supported upstream kernel. > > What do you think? > >> >> //Eelco >> >>>> >>>> HOSTLD scripts/dtc/dtc >>>> /usr/bin/ld: scripts/dtc/dtc-parser.tab.o:(.bss+0x20): multiple >>>> definition of `yylloc'; scripts/dtc/dtc-lexer.lex.o:(.bss+0x0): first >>>> defined here >>>> collect2: error: ld returned 1 exit status >>>> make[1]: *** [scripts/Makefile.host:99: scripts/dtc/dtc] Error 1 >>>> make: *** [Makefile:1281: scripts_dtc] Error 2 >>>> Error: Process completed with exit code 2. >>>> >>>> HOSTLD arch/x86/tools/relocs >>>> /usr/bin/ld: arch/x86/tools/relocs_64.o:(.bss+0x0): multiple definition >>>> of `per_cpu_load_addr'; arch/x86/tools/relocs_32.o:(.bss+0x0): first >>>> defined here >>>> collect2: error: ld returned 1 exit status >>>> make[1]: *** [scripts/Makefile.host:127: arch/x86/tools/relocs] Error 1 >>>> >>>> A quick search online resulted, in using an older compiler, or applying a >>>> kernel patch :) >>>> >>>> I guess we could apply the patches needed for the specific versions, but >>>> maybe you have better ideas? >>>> >>>> //Eelco >>>> >> > _______________________________________________ dev mailing list [email protected] https://mail.openvswitch.org/mailman/listinfo/ovs-dev
