On Wed, Jul 19, 2023 at 03:22:30PM +0200, Thomas Huth wrote:
> On 17/07/2023 20.28, Daniel P. Berrangé wrote:
> > The prom-env-test takes about 1 + 1/2 minutes in a --enable-debug
> > build. Bumping to 3 minutes will give more headroom.
> >
> > Signed-off-by: Daniel P. Berrangé <berra...@redhat.com>
> > ---
> > tests/qtest/meson.build | 1 +
> > 1 file changed, 1 insertion(+)
> >
> > diff --git a/tests/qtest/meson.build b/tests/qtest/meson.build
> > index c6da428dc5..095c98820e 100644
> > --- a/tests/qtest/meson.build
> > +++ b/tests/qtest/meson.build
> > @@ -5,6 +5,7 @@ slow_qtests = {
> > 'qom-test' : 900,
> > 'test-hmp' : 240,
> > 'pxe-test': 180,
> > + 'prom-env-test': 180,
> > }
> > qtests_generic = [
>
> I tested your patches, and initially, everything looked good now. But this
> prom-env-test them reminded me that we run some additional tests in the
> "SPEED=slow" mode ... I guess we have to take these into consideration, too?
>
> I now did a "configure --enable-debug" build and then ran:
>
> make -j$(nproc) check-qtest-ppc64 SPEED=slow
>
> and indeed, this prom-env-test is now timing out there. Also the
> device-introspect-test was timing out in SPEED=slow mode. Should we bump the
> timeout for those, or could this maybe be handled via the TIMEOUT_MULTIPLIER
> in the final patch?
My goal was "no regressions" wrt current status for people working on
common development hardware. If people are using old, or modern low
performance hardware than a timeout multiplier would be expected.
IOW, for SPEED=slow, I think we need to "do the right thing" with
the default timeouts.
With regards,
Daniel
--
|: https://berrange.com -o- https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o- https://fstop138.berrange.com :|
|: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
