* [PATCH] tests/qtest: Bump timeouts of boot_sector_test()-based tests to 610 seconds
@ 2024-01-24 8:44 Thomas Huth
2024-01-24 8:49 ` Daniel P. Berrangé
0 siblings, 1 reply; 2+ messages in thread
From: Thomas Huth @ 2024-01-24 8:44 UTC (permalink / raw)
To: qemu-devel; +Cc: Peter Maydell, Daniel P . Berrangé
We're still seeing timeouts in qtests that use a TCG payload with TCI
on a slow k8s runner:
https://gitlab.com/qemu-project/qemu/-/jobs/5990992722
So we should bump the timeout of cdrom-test to see whether that
fixes the issue.
Now, cdrom-test, as bios-tables-test, pxe-test and vmgenid-test use
the boot_sector_test() function for running a TCG payload. That
function already uses an internal timeout of 600 seconds with
the remark that the test could be slow with TCI.
Thus from the outer meson test runner side, we should not use less
than 600 seconds as timeout values for these tests. Let's bump them
on the meson side to 610 seconds so that the tests themselves can
run with their internal 600 seconds timeout and have some additional
seconds on top for reporting the outcome.
Signed-off-by: Thomas Huth <thuth@redhat.com>
---
tests/qtest/meson.build | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/tests/qtest/meson.build b/tests/qtest/meson.build
index d22aec6734..84a055a7d9 100644
--- a/tests/qtest/meson.build
+++ b/tests/qtest/meson.build
@@ -1,16 +1,18 @@
slow_qtests = {
'aspeed_smc-test': 360,
- 'bios-tables-test' : 540,
+ 'bios-tables-test' : 610,
+ 'cdrom-test' : 610,
'device-introspect-test' : 720,
'migration-test' : 480,
'npcm7xx_pwm-test': 300,
'npcm7xx_watchdog_timer-test': 120,
'qom-test' : 900,
'test-hmp' : 240,
- 'pxe-test': 600,
+ 'pxe-test': 610,
'prom-env-test': 360,
'boot-serial-test': 360,
'qos-test': 120,
+ 'vmgenid-test': 610,
}
qtests_generic = [
--
2.43.0
^ permalink raw reply related [flat|nested] 2+ messages in thread
* Re: [PATCH] tests/qtest: Bump timeouts of boot_sector_test()-based tests to 610 seconds
2024-01-24 8:44 [PATCH] tests/qtest: Bump timeouts of boot_sector_test()-based tests to 610 seconds Thomas Huth
@ 2024-01-24 8:49 ` Daniel P. Berrangé
0 siblings, 0 replies; 2+ messages in thread
From: Daniel P. Berrangé @ 2024-01-24 8:49 UTC (permalink / raw)
To: Thomas Huth; +Cc: qemu-devel, Peter Maydell
On Wed, Jan 24, 2024 at 09:44:12AM +0100, Thomas Huth wrote:
> We're still seeing timeouts in qtests that use a TCG payload with TCI
> on a slow k8s runner:
>
> https://gitlab.com/qemu-project/qemu/-/jobs/5990992722
>
> So we should bump the timeout of cdrom-test to see whether that
> fixes the issue.
> Now, cdrom-test, as bios-tables-test, pxe-test and vmgenid-test use
> the boot_sector_test() function for running a TCG payload. That
> function already uses an internal timeout of 600 seconds with
> the remark that the test could be slow with TCI.
> Thus from the outer meson test runner side, we should not use less
> than 600 seconds as timeout values for these tests. Let's bump them
> on the meson side to 610 seconds so that the tests themselves can
> run with their internal 600 seconds timeout and have some additional
> seconds on top for reporting the outcome.
>
> Signed-off-by: Thomas Huth <thuth@redhat.com>
> ---
> tests/qtest/meson.build | 6 ++++--
> 1 file changed, 4 insertions(+), 2 deletions(-)
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
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 :|
^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~2024-01-24 8:50 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2024-01-24 8:44 [PATCH] tests/qtest: Bump timeouts of boot_sector_test()-based tests to 610 seconds Thomas Huth
2024-01-24 8:49 ` Daniel P. Berrangé
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).