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 ... [email protected] 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 [email protected] 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 [email protected] https://lists.xenproject.org/mailman/listinfo/xen-devel
