From: Patrick Robb <probb@iol.unh.edu>
To: Stephen Hemminger <stephen@networkplumber.org>
Cc: David Marchand <david.marchand@redhat.com>, dev <dev@dpdk.org>,
Aaron Conole <aconole@redhat.com>,
ci@dpdk.org, Cody Cheng <ccheng@iol.unh.edu>
Subject: Re: pcapng_autotest unit test false positive
Date: Mon, 1 Apr 2024 18:26:44 -0400 [thread overview]
Message-ID: <CAJvnSUDZF9oTtj9yg12WuYRAQSVLsqxdFbdtFNu5Om1S1sWB4g@mail.gmail.com> (raw)
In-Reply-To: <20240322163430.444bed0c@hermes.local>
On Fri, Mar 22, 2024 at 7:34 PM Stephen Hemminger
<stephen@networkplumber.org> wrote:
>
>
> Could you build a simple test to see if TSC every runs backwards on
> this machine. Or there could be yet another math error.
> Or maybe container TSC is huge an wrapping around?
>
> The point of the test is to make sure that there wasn't wraparound errors.
Sorry about the wait on this one, but we did write that simple C
program to check for whether TSC ever runs backwards on this system.
It gets TSC using __rdtsc() because that's the same approach from the
x86 rte_cycles.c. And it just loops for 10 seconds or so and compares
n TSC to n-1 TSC, and if n's TSC is ever less than n-1's TSC it prints
a message saying so. Otherwise at the end it prints that TSC is
working normally. From running this the first time, it showed TSC as
never running backwards. Another thing I can do is trigger a full set
of testing (so that the system is under normal load) and then run the
tsc checking program concurrently.
Another idea - maybe multiple timestamps are gathered from different
CPU registers during the same test, and they are misaligned for that
reason. Maybe we can try reducing the cores for each unit test to 1
and checking whether the issue persists.
Or there could be another math error as you say.
And I should mention that now that I'm looking at this more closely I
did see that unfortunately all these fail results are coming from a
new debian 12 x86 environment which was added a few weeks ago, but
mistakenly labeled as debian 11 x86. So, the fact that fails started
can be explained by the fact that we added this new debian 12
container recently.
So, I'll try a few more things and keep yall updated.
next prev parent reply other threads:[~2024-04-01 22:26 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-03-20 18:02 David Marchand
2024-03-22 17:12 ` Patrick Robb
2024-03-22 23:34 ` Stephen Hemminger
2024-04-01 22:26 ` Patrick Robb [this message]
2024-04-02 0:46 ` Stephen Hemminger
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CAJvnSUDZF9oTtj9yg12WuYRAQSVLsqxdFbdtFNu5Om1S1sWB4g@mail.gmail.com \
--to=probb@iol.unh.edu \
--cc=aconole@redhat.com \
--cc=ccheng@iol.unh.edu \
--cc=ci@dpdk.org \
--cc=david.marchand@redhat.com \
--cc=dev@dpdk.org \
--cc=stephen@networkplumber.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).