All of lore.kernel.org
 help / color / mirror / Atom feed
From: Havard Skinnemoen <hskinnemoen@google.com>
To: Peter Maydell <peter.maydell@linaro.org>
Cc: qemu-arm <qemu-arm@nongnu.org>,
	QEMU Developers <qemu-devel@nongnu.org>,
	 IS20 Avi Fishman <Avi.Fishman@nuvoton.com>,
	CS20 KFTing <kfting@nuvoton.com>,
	 Patrick Venture <venture@google.com>,
	Hao Wu <wuhaotsh@google.com>, Thomas Huth <thuth@redhat.com>
Subject: Re: [PATCH v3 4/6] hw/misc: Add npcm7xx random number generator
Date: Mon, 2 Nov 2020 08:50:47 -0800	[thread overview]
Message-ID: <CAFQmdRZOKLb6=NJoeY9U3eYq3rbG_OWGFDDZdGTf8vjVOA11TQ@mail.gmail.com> (raw)
In-Reply-To: <CAFEAcA8YvmFA7=7+CGVpubVScuKPdy+OQdmJdfMD+Fmk+Hb0SA@mail.gmail.com>

On Mon, Nov 2, 2020 at 3:36 AM Peter Maydell <peter.maydell@linaro.org> wrote:
>
> On Fri, 23 Oct 2020 at 22:06, Havard Skinnemoen <hskinnemoen@google.com> wrote:
> >
> > The RNG module returns a byte of randomness when the Data Valid bit is
> > set.
> >
> > This implementation ignores the prescaler setting, and loads a new value
> > into RNGD every time RNGCS is read while the RNG is enabled and random
> > data is available.
> >
> > A qtest featuring some simple randomness tests is included.
>
> > +int main(int argc, char **argv)
> > +{
> > +    int ret;
> > +
> > +    g_test_init(&argc, &argv, NULL);
> > +    g_test_set_nonfatal_assertions();
>
> While I was looking at this test case I noticed that it
> calls g_test_set_nonfatal_assertions(). Why does it do that?
> In our entire set of tests, only the npcm7xx test cases call
> that function, and they don't explain why they're a special
> case that needs to do so.

It's often useful to see more than the first failure when debugging
tests. Using the randomness flakiness as an example, it's very useful
to know if more than just one of the randomness tests fail. If I
remove g_test_set_nonfatal_assertions, I get:

**
ERROR:../../../tests/qtest/npcm7xx_rng-test.c:256:test_first_byte_runs:
assertion failed (calc_runs_p(buf.l, sizeof(buf) * BITS_PER_BYTE) >
0.01): (0.00204666737 > 0.01)
Bail out! ERROR:../../../tests/qtest/npcm7xx_rng-test.c:256:test_first_byte_runs:
assertion failed (calc_runs_p(buf.l, sizeof(buf) * BITS_PER_BYTE) >
0.01): (0.00204666737 > 0.01)
Aborted

which doesn't even tell me the name of the test that failed, let alone
anything about whether any subsequent tests passed.

Also note that it doesn't provide a clear "not ok" signal, which makes
life difficult for any downstream processing of the TAP output. It
looks like the test unexpectedly crashed.

Compare this to the output with g_test_set_nonfatal_assertions:

**
ERROR:../../../tests/qtest/npcm7xx_rng-test.c:232:test_first_byte_monobit:
assertion failed (calc_monobit_p(buf, sizeof(buf)) > 0.01):
(4.78548397e-05 > 0.01)
# ERROR:../../../tests/qtest/npcm7xx_rng-test.c:232:test_first_byte_monobit:
assertion failed (calc_monobit_p(buf, sizeof(buf)) > 0.01):
(4.78548397e-05 > 0.01)
not ok 5 /arm/npcm7xx_rng/first_byte/monobit
ok 6 /arm/npcm7xx_rng/first_byte/runs

which clearly shows that the "first_byte/monobit" test failed, and the
subsequent "first_byte/runs" test passed.

But none of this is really specific to the RNG test, so I can remove
it if you prefer for consistency.

Havard


  reply	other threads:[~2020-11-02 16:53 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-10-23 21:06 [PATCH v3 0/6] Additional NPCM7xx features, devices and tests Havard Skinnemoen via
2020-10-23 21:06 ` [PATCH v3 1/6] tests/qtest: Make npcm7xx_timer-test conditional on CONFIG_NPCM7XX Havard Skinnemoen via
2020-10-24  5:26   ` Thomas Huth
2020-10-23 21:06 ` [PATCH v3 2/6] Move npcm7xx_timer_reached_zero call out of npcm7xx_timer_pause Havard Skinnemoen via
2020-10-23 21:06 ` [PATCH v3 3/6] hw/timer: Adding watchdog for NPCM7XX Timer Havard Skinnemoen via
2020-10-23 21:06 ` [PATCH v3 4/6] hw/misc: Add npcm7xx random number generator Havard Skinnemoen via
2020-10-30 13:34   ` Peter Maydell
2020-10-30 15:43     ` Havard Skinnemoen
2020-11-02 11:36   ` Peter Maydell
2020-11-02 16:50     ` Havard Skinnemoen [this message]
2020-11-02 17:13       ` Peter Maydell
2020-11-02 18:21         ` Havard Skinnemoen
2020-10-23 21:06 ` [PATCH v3 5/6] hw/arm/npcm7xx: Add EHCI and OHCI controllers Havard Skinnemoen via
2020-10-23 21:06 ` [PATCH v3 6/6] hw/gpio: Add GPIO model for Nuvoton NPCM7xx Havard Skinnemoen via
2020-10-26 17:15 ` [PATCH v3 0/6] Additional NPCM7xx features, devices and tests Peter Maydell

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='CAFQmdRZOKLb6=NJoeY9U3eYq3rbG_OWGFDDZdGTf8vjVOA11TQ@mail.gmail.com' \
    --to=hskinnemoen@google.com \
    --cc=Avi.Fishman@nuvoton.com \
    --cc=kfting@nuvoton.com \
    --cc=peter.maydell@linaro.org \
    --cc=qemu-arm@nongnu.org \
    --cc=qemu-devel@nongnu.org \
    --cc=thuth@redhat.com \
    --cc=venture@google.com \
    --cc=wuhaotsh@google.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.