On Wed, Aug 16, 2023 at 8:30 PM Patrick Robb <pr...@iol.unh.edu> wrote: > On Wed, Aug 16, 2023 at 10:40 AM David Marchand <david.march...@redhat.com> > wrote: >> >> Patrick, Bruce, >> >> If it was reported, I either missed it or forgot about it, sorry. >> Can you (re)share the context? >> >> >> > >> > Does the test suite pass if the mlx5 driver is disabled in the build? That >> > could confirm or refute the suspicion of where the issue is, and also >> > provide a temporary workaround while this set is merged (possibly including >> > support for disabling specific tests, as I suggested in my other email). >> >> Or disabling the driver as Bruce proposes. > > Okay, we ran the test with the mlx5 driver disabled, and it still fails. So, > this might be more of an ARM architecture issue. Ruifeng, are you still > seeing this on your test bed? > > @David you didn't miss anything, we had a unicast with ARM when setting up > the new arm container runners for unit testing a few months back. Ruifeng > also noticed the same issue and speculated about mlx5 memory leaks. He raised > the possibility of disabling the mlx5 driver too, but that option isn't great > since we want to have a uniform build process (as much as possible) for our > unit testing. Anyways, now we know that that isn't relevant. I'll forward the > thread to you in any case - let me know if you have any ideas.
The mention of "memtest1" in the mails rings a bell. I will need more detailed logs, or ideally an env where it is reproduced. One thing bothers me.. why are we not seeing this failure with ARM for Bruce v6 series? Just looking at patchwork, I would think that I can merge Bruce series as is. https://patchwork.dpdk.org/project/dpdk/patch/20230816153439.551501-12-bruce.richard...@intel.com/ -- David Marchand
