The failures don't appear to follow an Ubuntu release, a host
architecture, or the guest architecture being tested. So did something
change externally? Looking at the data:

Prior to June 2020, we only saw a 2.7% failure rate (3/112).
Starting in June, that's grown to 25% (8/32). This is across all releases, so 
it's unlikely due to a change in edk2 itself (eoan/focal releases haven't 
changed recently).

Perhaps something changed with our test systems. Just looking at armhf
tests, time to run a test seems to have gone up, on average, since then
- +6s/+3s/+6s for AARCH64/ARM/X86 guests, respectively. What's also
interesting is that, again just looking at armhf, 100% of the time (7/7)
we had a timeout, there was another test very close to timing out (>=
30s). When no timeouts occurred, only 13% (6/46) had any test close to
timing out.

What that says to me is that this is unlikely to be an actual hang.
Rather, sometimes we get a test host w/ less available resources[*], and
the odds of that have gone up recently for some reason. I'll therefore
plan to bump the timeout to 60s to see if that resolves the issue.


[*] Hard to say what resource(s) could be limited here - one theory is that 
QEMU is waiting on available entropy, but it could just be CPU.

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1885186

Title:
  autopkgtests sometimes timeout

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/edk2/+bug/1885186/+subscriptions

-- 
ubuntu-bugs mailing list
[email protected]
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

Reply via email to