The current timeout of 40s seems to be too low for AMD boxes (pinots and
rimavas) in the lab after XSA-455, see:

http://logs.test-lab.xenproject.org/osstest/logs/185303/test-amd64-coresched-amd64-xl/info.html

Increase the timeout to 60s.

Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
---
 ts-debian-di-install | 2 +-
 ts-debian-install    | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/ts-debian-di-install b/ts-debian-di-install
index 06c7e1f46a92..1a187dfeb9cb 100755
--- a/ts-debian-di-install
+++ b/ts-debian-di-install
@@ -76,7 +76,7 @@ sub prep () {
     target_install_packages_norec($ho, qw(lvm2));
 
     $gho= prepareguest($ho, $gn, $guesthost, 22,
-                       $disk_mb, 40);
+                       $disk_mb, 60);
 
     prepareguest_part_diskimg($ho, $gho, $disk_mb);
 }
diff --git a/ts-debian-install b/ts-debian-install
index 62db487ad15d..ef2954dd3c8e 100755
--- a/ts-debian-install
+++ b/ts-debian-install
@@ -42,7 +42,7 @@ sub prep () {
 
     $gho= prepareguest($ho, $gn, $guesthost, 22,
                        $swap_mb + $disk_mb + 2,
-                       40);
+                       60);
     target_cmd_root($ho, "umount $gho->{Lvdev} ||:");
 }
 
-- 
2.44.0

On Fri, Apr 12, 2024 at 04:11:21PM +0200, Roger Pau Monne wrote:
> The current timeout of 40s seems to be too low for AMD boxes (pinots and
> rimavas) in the lab after XSA-455, see:

There's something else we can tweak if only some machine need extra
time, it is an host property "TimeoutFactor", which can increase all
timeout for a single machine. (It's use on the cubietruck for example.)

Or is it better to just increase boot time for all (or at least those)
pv guest?

Cheers,

-- 
Anthony PERARD

On Mon, Apr 15, 2024 at 09:15:51AM +0100, Anthony PERARD wrote:
> On Fri, Apr 12, 2024 at 04:11:21PM +0200, Roger Pau Monne wrote:
> > The current timeout of 40s seems to be too low for AMD boxes (pinots and
> > rimavas) in the lab after XSA-455, see:
> 
> There's something else we can tweak if only some machine need extra
> time, it is an host property "TimeoutFactor", which can increase all
> timeout for a single machine. (It's use on the cubietruck for example.)
> 
> Or is it better to just increase boot time for all (or at least those)
> pv guest?

I did consider that, but given the timeout is just limited to PV guest
startup I considered the "TimeoutFactor" too broad.  I think
increasing the Debian PV boot timeout from 40s to 60s is a minor
adjustment, and shouldn't affect other tests.

Let me know if you still prefer to use "TimeoutFactor" and I will look
into it.

Thanks, Roger.

On Mon, Apr 15, 2024 at 10:33:19AM +0200, Roger Pau Monné wrote:
> On Mon, Apr 15, 2024 at 09:15:51AM +0100, Anthony PERARD wrote:
> > On Fri, Apr 12, 2024 at 04:11:21PM +0200, Roger Pau Monne wrote:
> > > The current timeout of 40s seems to be too low for AMD boxes (pinots and
> > > rimavas) in the lab after XSA-455, see:
> > 
> > There's something else we can tweak if only some machine need extra
> > time, it is an host property "TimeoutFactor", which can increase all
> > timeout for a single machine. (It's use on the cubietruck for example.)
> > 
> > Or is it better to just increase boot time for all (or at least those)
> > pv guest?
> 
> I did consider that, but given the timeout is just limited to PV guest
> startup I considered the "TimeoutFactor" too broad.  I think
> increasing the Debian PV boot timeout from 40s to 60s is a minor
> adjustment, and shouldn't affect other tests.
> 
> Let me know if you still prefer to use "TimeoutFactor" and I will look
> into it.

Acked-by: Anthony PERARD <anthony.perard@citrix.com>

Thanks,

-- 
Anthony PERARD

On 12/04/2024 3:11 pm, Roger Pau Monne wrote:
> The current timeout of 40s seems to be too low for AMD boxes (pinots and
> rimavas) in the lab after XSA-455, see:
>
> http://logs.test-lab.xenproject.org/osstest/logs/185303/test-amd64-coresched-amd64-xl/info.html
>
> Increase the timeout to 60s.
>
> Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>

FWIW, Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>