Re: [Xen-devel] [xen-unstable test] 108068: regressions - FAIL

[Wei Liu <wei.liu2@xxxxxxxxxx>]

On Tue, May 02, 2017 at 01:45:28PM +0100, Ian Jackson wrote:
> Jan Beulich writes ("Re: [Xen-devel] [xen-unstable test] 108068: regressions 
> - FAIL"):
> > On 01.05.17 at 20:49, <osstest-admin@xxxxxxxxxxxxxx> wrote:
> > This has been recurring for the last few flights, but I wonder whether
> > 
> > 2017-05-01 13:18:52 Z executing ssh ... root@172.16.144.40 readlink 
> > /dev/italia0-vg/win.guest.osstest-disk 
> > 2017-05-01 13:18:52 Z executing ssh ... root@172.16.144.40 lvdisplay 
> > --colon /dev/italia0-vg/win.guest.osstest-disk 
> > 2017-05-01 13:18:53 Z lvdisplay output says device is still open: 
> > /dev/italia0-vg/win.guest.osstest-disk:italia0-vg:3:1:-1:2:20480000:2500:-1:0:-1:253:2
> >  
> > 2017-05-01 13:18:53 Z executing ssh ... root@172.16.144.40 umount 
> > /dev/italia0-vg/win.guest.osstest-disk 
> > umount: /dev/italia0-vg/win.guest.osstest-disk: not mounted
> > 2017-05-01 13:18:53 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_108068.test-amd64-i386-xl-qemut-winxpsp3-vcpus1
> >  root@172.16.144.40 umount /dev/italia0-vg/win.guest.osstest-disk 
> > status 8192 at Osstest/TestSupport.pm line 442.
> > 
> > indicates an environmental problem rather than a
> > software-under-test one (the more that the single commit
> > being tested can't possibly influence host or guest behavior).
> 
> This is almost certainly not an environmental problem.  What seems to
> be happening is that the guest shutdown/teardown is going wrong
> somehow.
> 
> http://logs.test-lab.xenproject.org/osstest/logs/108068/test-amd64-i386-xl-qemut-winxpsp3-vcpus1/16.ts-guest-stop.log
> 
> shows this:
> 
> 2017-05-01 13:18:27 Z executing ssh ... root@172.16.144.40 xl shutdown -wF 
> win.guest.osstest 
> Shutting down domain 17
> PV control interface not available: sending ACPI power button event.
> Waiting for 1 domains
> Domain 17 has been shut down, reason code 1
> 2017-05-01 13:18:36 Z executing ssh ... root@172.16.144.40 xl list 
> 2017-05-01 13:18:36 Z guest win.guest.osstest state is psr 
> 
> So the guest has been shut down in the sense that xl shutdown -w
> has exited (-w means to wait for the shutdown), but not in the sense
> that the domain has been destroyed.
> 
> osstest spends 14 seconds checking that the guest doesn't respond to
> ping (this is probably a bit pointless, TBH):
> 
> 2017-05-01 13:18:50 Z ping 172.16.146.243 down 
> 
> Then the next step tries to start the guest.  But it finds that the
> backing block device is in use.  The command that fails is there so
> that this test script can be re-run in certain ad-hoc by-hand tests:
> it is trying to unmount the block device, on the theory that if it is
> shown as open in LVM, that is probably because it's mounted.  The
> unmount fails.
> 
> The underlying problem is that the block backend still has the guest
> block device open.  Indeed, during the logs capture we see
> 
> http://logs.test-lab.xenproject.org/osstest/logs/108068/test-amd64-i386-xl-qemut-winxpsp3-vcpus1/italia0-output-xl_list
> 
> the guest is still there:
> 
> Name                                        ID   Mem VCPUs    State   Time(s)
> Domain-0                                     0   511     4     r-----     
> 913.9
> win.guest.osstest                           18  1536     1     r-----      
> 16.0
> 
> (that's at 2017-05-01 13:18:56)
> 
> I think the guest that was shut down was domid 17 and this new one is
> domid 18.  This logfile
> 
> http://logs.test-lab.xenproject.org/osstest/logs/108068/test-amd64-i386-xl-qemut-winxpsp3-vcpus1/italia0---var-log-xen-xl-win.guest.osstest--incoming.log
> 
> shows domid 17 shutting down and then this message
> 
>  Done. Rebooting now
> 
> and then it seems to start the domain again.
> 
> Is it possible that something has changed which means that Windows
> (sometimes?) doesn't respond to an ACPI power button event by shutting
> down, but by rebooting ?
> 

We applied a patch to add ACPI device for Windows laptop/slate mode. I
don't see how that can cause problem though. It has passed the pushgate
long ago and the option is off by default.

Wei.

> Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
https://lists.xen.org/xen-devel