Re: [Xen-devel] [xen-4.12-testing test] 143302: regressions - FAIL

[Jan Beulich <jbeulich@xxxxxxxx>]

On 29.10.2019 23:52, osstest service owner wrote:
> flight 143302 xen-4.12-testing real [real]
> http://logs.test-lab.xenproject.org/osstest/logs/143302/
> 
> Regressions :-(
> 
> Tests which did not succeed and are blocking,
> including tests which could not be run:
>  test-amd64-i386-xl-qemut-ws16-amd64  7 xen-boot          fail REGR. vs. 
> 143190
>  test-amd64-amd64-livepatch    7 xen-boot                 fail REGR. vs. 
> 143190
>  test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 14 guest-saverestore.2 
> fail REGR. vs. 143190
>  test-amd64-i386-xl-raw      19 guest-start/debian.repeat fail REGR. vs. 
> 143190

Looking at this one I see

2019-10-29 19:40:59 Z executing ssh ... root@172.16.144.29 mkdir -p 
/var/lib/xen/images/debian
mount /dev/mapper/chardonnay1--vg-debian.stretch.guest.osstest--disk 
/var/lib/xen/images/debian;
 
mount: /dev/mapper/chardonnay1--vg-debian.stretch.guest.osstest--disk is 
already mounted or /var/lib/xen/images/debian busy
       /dev/mapper/chardonnay1--vg-debian.stretch.guest.osstest--disk is 
already mounted on /var/lib/xen/images/debian
2019-10-29 19:41:00 Z command nonzero waitstatus 8192: timeout 60 ssh -o 
StrictHostKeyChecking=no -o BatchMode=yes -o ConnectTimeout=100 -o 
ServerAliveInterval=100 -o PasswordAuthentication=no -o 
ChallengeResponseAuthentication=no -o 
UserKnownHostsFile=tmp/t.known_hosts_143302.test-amd64-i386-xl-raw 
root@172.16.144.29 mkdir -p /var/lib/xen/images/debian
mount /dev/mapper/chardonnay1--vg-debian.stretch.guest.osstest--disk 
/var/lib/xen/images/debian;
 
status 8192 at Osstest/TestSupport.pm line 550.

It shouldn't be timeout, so I assume it's the mount that fails.
Some new glitch in osstest (seen also on the most recent 4.11
flight)? Or am I misreading the above? In any event I can't spot
a similar mkdir invocation in a random other test's
guest-start/debian.repeat step.

What I find further puzzling (albeit not necessarily related to the
test failure, at least the serial logs don't immediately suggest so
except for the guest no longer being there when the debug keys get
processed, but this may well have been a guest of a previous test
step) are instances of

(XEN) d25 L1TF-vulnerable L1e 8000000200000000 - Shadowing

both here and again in the corresponding 4.11 branch flight. I also
don't think it's pure coincidence that it's d1, d2, and d25 in both
cases. Yet this occurring pretty soon after the guest starts, I'd
find it more likely if all guest boot instances showed it. In any
event I'd like to ask if anyone (Jürgen in particular) has an idea
what bogus operation 32-bit Linux may be doing here. Is there
possibly still some 2-part PTE update left, where the low half gets
cleared off of a previously fine entry?

Jan

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel