Hi,
I've recently gotten a kind of bug I was waiting for many years.
In fact I wondered if it would still come up as each year made it less likely.
But it happened and I got a crash report of someone using dpdk a
rather old pre sse4.2 hardware.
=> https://bugs.launchpad.net/ubuntu/+source/dpdk/+bug/2009635/comments/9
The reporter was nice and tried the newer 22.11, but that is just as affected.
I understand that DPDK, as a project, has set this as the minimal
accepted hardware capability.
But due to some programs - in this case UHD - being able to do many
other things it might happen that UHD or any else just links to DPDK
(as it could be used with it) and due to that runs into a crash when
loading. In theory other tools like collectd which has dpdk support
would be affected by the same.
Example:
root@1bee22d20ca0:/# uhd_usrp_probe
Illegal instruction (core dumped)
(gdb) bt
#0 0x00007f4b2d3a3374 in rte_srand () from
/lib/x86_64-linux-gnu/librte_eal.so.23
#1 0x00007f4b2d3967ec in ?? () from /lib/x86_64-linux-gnu/librte_eal.so.23
#2 0x00007f4b2e5d1fbe in call_init (l=<optimized out>,
argc=argc@entry=1, argv=argv@entry=0x7ffeabf5b488,
env=env@entry=0x7ffeabf5b498)
at ./elf/dl-init.c:70
#3 0x00007f4b2e5d20a8 in call_init (env=0x7ffeabf5b498,
argv=0x7ffeabf5b488, argc=1, l=<optimized out>) at ./elf/dl-init.c:33
#4 _dl_init (main_map=0x7f4b2e6042e0, argc=1, argv=0x7ffeabf5b488,
env=0x7ffeabf5b498) at ./elf/dl-init.c:117
#5 0x00007f4b2e5ea8b0 in _dl_start_user () from /lib64/ld-linux-x86-64.so.2
#6 0x0000000000000001 in ?? ()
#7 0x00007ffeabf5c844 in ?? ()
#8 0x0000000000000000 in ?? ()
Right now all we could do is:
a) say bad luck old hardware (not nice)
b) make super complex alternative builds with and without dpdk support
c) ask the DPDK project to work on non sse4.2 (unlikely and too late
in 2023 I guess)
d) Somehow make the initialization graceful (that is what I'm RFC here)
If we could manage to get that DPDK to ensure the lib loading paths
are SSE4.2 free.
Then we could check the capabilities on the actual initialization and
return a proper bad result instead of a crash.
Due to that only real-users of DPDK would be required to have
sufficiently new hardware.
And OTOH users of software that links, but in the current config would
not use DPDK would suffer less.
WDYT?
Maybe it has been already discussed and I did neither remember nor find it?
--
Christian Ehrhardt
Senior Staff Engineer, Ubuntu Server
Canonical Ltd
