[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [qemu-upstream-unstable test] 21375: regressions - FAIL



Friday, November 1, 2013, 11:52:51 AM, you wrote:

> On Fri, 2013-11-01 at 11:47 +0100, Sander Eikelenboom wrote:
>> Friday, November 1, 2013, 11:38:20 AM, you wrote:
>> 
>> > flight 21375 qemu-upstream-unstable real [real]
>> > http://www.chiark.greenend.org.uk/~xensrcts/logs/21375/
>> 
>> > Regressions :-(
>> 
>> > Tests which did not succeed and are blocking,
>> > including tests which could not be run:
>> >  test-amd64-i386-qemuu-rhel6hvm-intel  7 redhat-install    fail REGR. vs. 
>> > 20054
>> 
>> > Tests which are failing intermittently (not blocking):
>> >  test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 9 guest-localmigrate fail pass 
>> > in 21372
>> >  test-amd64-i386-xl-qemuu-win7-amd64 10 guest-saverestore.2  fail pass in 
>> > 21372
>> >  test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 12 guest-localmigrate/x10 fail 
>> > in 21372 pass in 21365
>> 
>> > Tests which did not succeed, but are not blocking:
>> >  test-amd64-amd64-xl-qemuu-win7-amd64 13 guest-stop             fail never 
>> > pass
>> >  test-amd64-amd64-xl-qemuu-winxpsp3 13 guest-stop               fail never 
>> > pass
>> >  test-amd64-i386-xend-qemuu-winxpsp3 16 leak-check/check        fail never 
>> > pass
>> >  test-amd64-i386-xl-qemuu-win7-amd64 13 guest-stop     fail in 21372 never 
>> > pass
>> >  test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 13 guest-stop fail in 21365 
>> > never pass
>> 
>> > version targeted for testing:
>> >  qemuu                b97307ecaad98360f41ea36cd9674ef810c4f8cf
>> > baseline version:
>> >  qemuu                8a4bd762aa01b21c43aa24c5b743f4bd7c9db3e3
>> 
>> 
>> 
>>  Ian,
>> 
>>  Why does the script try to reboot the guest within 2 seconds after creating 
>> it ?
>>  Also strange it doesn't report back that the -F should be used since
>> the guest is probably not booted yet so PV drivers can't be loaded
>> yet.

> Where do you see this? It isn't in the logs you quoted, which only show
> the harness waiting for a reboot, not initiating one. This is sensible
> -- it is waiting for the reboot initiated by the installer from within
> the guest when it is finished installing.

Ah ok, seems i misread sorry.
So the guest should request a reboot itself, and thus seems to stall somewhere 
(given the assumption that it should be able to reach the point to reboot in 
2000s)
Isn't the installing part one in part part above this in the log ?
(http://www.chiark.greenend.org.uk/~xensrcts/logs/21375/test-amd64-i386-qemuu-rhel6hvm-intel/7.ts-redhat-install.log)

Also in:
http://www.chiark.greenend.org.uk/~xensrcts/logs/21375/test-amd64-i386-qemuu-rhel6hvm-intel/info.html

There doesn't seem to be any helpful logging of what the *guest* is actually 
doing (or not)



>>  This seems to block the push for quite some time now ...
>>  --
>>  Sander
>> 
>> 
>>  2013-11-01 06:30:56 Z execution took 72 seconds[<=2x600]: 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_21375.test-amd64-i386-qemuu-rhel6hvm-intel
>>  root@xxxxxxxxxxxxx             genisoimage -o 
>> /root/21375.test-amd64-i386-qemuu-rhel6hvm-intel.rhel-server-6.1-i386-dvd.iso
>>  -R -J -T -b isolinux/isolinux.bin -c isolinux/boot.cat -no-emul-boot 
>> -boot-load-size 4 -boot-info-table /root/newiso/.
>> 
>> 2013-11-01 06:30:56 Z runvar store: 
>> redhat_cfgpath=/etc/xen/redhat.guest.osstest.cfg
>> 2013-11-01 06:30:56 Z executing scp ... 
>> /home/xc_osstest/logs/21375/test-amd64-i386-qemuu-rhel6hvm-intel/gall-mite--redhat.guest.osstest.cfg
>>  root@xxxxxxxxxxxxx:/etc/xen/redhat.guest.osstest.cfg
>> 2013-11-01 06:30:57 Z executing ssh ... root@xxxxxxxxxxxxx         (echo 
>> xenvnc; echo xenvnc) | vncpasswd redhat.vncpw
>> 
>> Password:Verify:2013-11-01 06:30:57 Z executing ssh ... root@xxxxxxxxxxxxx 
>> xl create /etc/xen/redhat.guest.osstest.cfg
>> WARNING: ignoring "kernel" directive for HVM guest. Use "firmware_override" 
>> instead if you really want a non-default firmware
>> Parsing config from /etc/xen/redhat.guest.osstest.cfg
>> 2013-11-01 06:30:59 Z await reboot request from redhat: waiting 2000s...
>> 2013-11-01 06:30:59 Z executing ssh ... root@xxxxxxxxxxxxx xl list
>> 2013-11-01 06:30:59 Z guest redhat.guest.osstest state is -
>> 2013-11-01 06:30:59 Z await reboot request from redhat: guest state is - 
>> (waiting) ...
>> 2013-11-01 06:31:29 Z executing ssh ... root@xxxxxxxxxxxxx xl list
>> 2013-11-01 06:31:30 Z guest redhat.guest.osstest state is r
>> 2013-11-01 06:31:30 Z await reboot request from redhat: guest state is r 
>> (waiting) ...
>> 2013-11-01 06:31:59 Z executing ssh ... root@xxxxxxxxxxxxx xl list
>> 2013-11-01 06:31:59 Z guest redhat.guest.osstest state is r
>> 2013-11-01 06:32:29 Z executing ssh ... root@xxxxxxxxxxxxx xl list
>> 2013-11-01 06:32:29 Z guest redhat.guest.osstest state is r
>> 2013-11-01 06:32:59 Z executing ssh ... root@xxxxxxxxxxxxx xl list
>> 
>> 
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@xxxxxxxxxxxxx
>> http://lists.xen.org/xen-devel





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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.