On Wed, Jun 16, 2021 at 6:27 PM Owen Hilyard <ohily...@iol.unh.edu> wrote: >> - For the fast-tests testsuite, the default timeout should be 10s, not 600s. >> See timeout_seconds_fast, >> https://git.dpdk.org/dpdk/tree/app/test/meson.build#n446 >> Odd that a 600s timeout has been applied to fast-tests in your run. >> How do you invoke meson? > > > # meson test -t 600 > > I copied the invocation from the production scripts for the community lab and > removed the --suite argument.
600? -t is for timeout multiplier. The default timeout for fast tests is 10s and the logs in a previous mail show 600s for timeout, so I would expect a 60 multiplier. > >> It seems like there are multiple dpdk processes running in // in this >> environment. >> Any idea of what is happening on your system at the moment you tried >> to run this test? > > > I ran this on a VM that we keep in the same state as the production container > runners. It is not attached to our Jenkins instance, and I was the only > logged-in user. I re-ran the test suite with and without ASAN, and it seems > like this type of failure only happens when ASAN is active. The failing tests > are: eal_flags_a_opt_autotest, eal_flags_b_opt_autotest, > eal_flags_c_opt_autotest, eal_flags_main_opt_autotest, > eal_flags_misc_autotest. I've attached the log. ASAN seems to break some assumption on the default virtual base address used by the mp stuff. It might be a reason for the secondary process init failure. Still, we have probably a deadlock here, since the test should fail in a reasonable amount of time. My guess would be at some secondary process not releasing a lock and the primary ends up waiting on it. Here, a secondary process did not initialise correctly, but it tried to cleanup afterwards... per chance, do you have a crash reported in syslog? -- David Marchand
