QA » openQA Project » openQA Tests

It might have something to do with bad performance on arm workers.

It is not a performance issue, after printing the logs, I can see the below errors:

-valgrind --tool=memcheck --trace-children=yes ./valgrind-test 2>/dev/null
+valgrind -v --tool=memcheck --trace-children=yes ./valgrind-test

logs:

+ valgrind -v --tool=memcheck --trace-children=yes ./valgrind-test
==2050== Memcheck, a memory error detector
==2050== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==2050== Using Valgrind-3.18.1-42b08ed5bd-20211015 and LibVEX; rerun with -h for copyright info
==2050== Command: ./valgrind-test
==2050== 
--2050-- Valgrind options:
--2050--    -v
--2050--    --tool=memcheck
--2050--    --trace-children=yes
--2050-- Contents of /proc/version:
--2050--   Linux version 5.14.21-150400.24.28-default (geeko@buildhost) (gcc (SUSE Linux) 7.5.0, GNU ld (GNU Binutils; SUSE Linux Enterprise 15) 2.37.20211103-150100.7.37) #1 SMP PREEMPT_DYNAMIC Mon Oct 10 15:21:12 UTC 2022 (f82da2c)
--2050-- 
--2050-- Arch and hwcaps: ARM64, LittleEndian, v8-atomics
--2050-- Page sizes: currently 4096, max supported 65536
--2050-- Valgrind library directory: /usr/lib/valgrind
--2050-- Reading syms from /var/tmp/valgrind-test
--2050-- Reading syms from /lib64/ld-2.31.so
--2050-- Reading syms from /usr/lib/valgrind/memcheck-arm64-linux
--2050--    object doesn't have a symbol table
--2050--    object doesn't have a dynamic symbol table
--2050-- Scheduler: using generic scheduler lock implementation.
--2050-- Reading suppressions file: /usr/lib/valgrind/default.supp
==2050== embedded gdbserver: reading from /tmp/vgdb-pipe-from-vgdb-to-2050-by-root-on-susetest
==2050== embedded gdbserver: writing to   /tmp/vgdb-pipe-to-vgdb-from-2050-by-root-on-susetest
==2050== embedded gdbserver: shared mem   /tmp/vgdb-pipe-shared-mem-vgdb-2050-by-root-on-susetest
==2050== 
==2050== TO CONTROL THIS PROCESS USING vgdb (which you probably
==2050== don't want to do, unless you know exactly what you're doing,
==2050== or are doing some strange experiment):
==2050==   /usr/lib/valgrind/../../bin/vgdb --pid=2050 ...command...
==2050== 
==2050== TO DEBUG THIS PROCESS USING GDB: start GDB like this
==2050==   /path/to/gdb ./valgrind-test
==2050== and then give GDB the following command
==2050==   target remote | /usr/lib/valgrind/../../bin/vgdb --pid=2050
==2050== --pid is optional if only one valgrind process is running
==2050== 

VEX: Mismatch detected between RDMA and atomics features.
     Found: v8-atomics
Cannot continue. Good-bye

vex storage: T total 0 bytes allocated
vex storage: P total 0 bytes allocated

valgrind: the 'impossible' happened:
   LibVEX called failure_exit().

However, I can't see the issue on my local setup, it might have something to do with the hardware configration.

My setup:
# lscpu|grep Flags
Flags:                           fp asimd evtstrm aes pmull sha1 sha2 crc32 cpuid

openQA workers:
# lscpu; echo 5GZT6-$?-
Architecture:           aarch64
  CPU op-mode(s):       64-bit
  Byte Order:           Little Endian
CPU(s):                 4
  On-line CPU(s) list:  0-3
Vendor ID:              Cavium
  Model name:           ThunderX 88XX
    Model:              1
    Thread(s) per core: 1
    Core(s) per socket: 4
    Socket(s):          1
    Stepping:           0x1
    BogoMIPS:           200.00
    Flags:              fp asimd evtstrm aes pmull sha1 sha2 crc32 atomics cpuid
NUMA:                   
  NUMA node(s):         1
  NUMA node0 CPU(s):    0-3

Let me try to file a bug

https://bugzilla.suse.com/show_bug.cgi?id=1204685

Check if the fix is checked in: http://openqa.suse.de/tests/10071023