flight 17780 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/17780/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-amd64-amd64-xl-sedf 7 debian-install fail REGR. vs. 17778
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-pcipt-intel 9 guest-start fail never pass
test-amd64-i386-xend-winxpsp3 16 leak-check/check fail never pass
test-amd64-amd64-xl-qemut-win7-amd64 13 guest-stop fail never pass
test-amd64-amd64-xl-qemuu-winxpsp3 13 guest-stop fail never pass
test-amd64-amd64-xl-qemuu-win7-amd64 13 guest-stop fail never pass
test-amd64-amd64-xl-win7-amd64 13 guest-stop fail never pass
test-amd64-i386-xl-win7-amd64 13 guest-stop fail never pass
test-amd64-i386-xl-qemut-win7-amd64 13 guest-stop fail never pass
test-amd64-amd64-xl-winxpsp3 13 guest-stop fail never pass
test-amd64-amd64-xl-qemut-winxpsp3 13 guest-stop fail never pass
test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop fail never pass
test-amd64-i386-xl-qemut-winxpsp3-vcpus1 13 guest-stop fail never pass
test-amd64-i386-xend-qemut-winxpsp3 16 leak-check/check fail never pass
version targeted for testing:
xen 96ef6e88359910738905ac2e1969dc05d7d7e7dc
baseline version:
xen e4e1e0ecc023caf4cf3b87a4aa4d5e210760f4e8
------------------------------------------------------------
People who touched revisions under test:
Bastian Blank <waldi@debian.org>
George Dunlap <george.dunlap@eu.citrix.com>
Ian Campbell <ian.campbell@citrix.com>
Jan Beulich <jbeulich@suse.com>
Keir Fraser <keir@xen.org>
Len Brown <len.brown@intel.com>
Samuel Thibault <samuel.thibault@ens-lyon.org>
Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Xu Zhang <xzhang@cs.uic.edu>
------------------------------------------------------------
jobs:
build-amd64 pass
build-armhf pass
build-i386 pass
build-amd64-oldkern pass
build-i386-oldkern pass
build-amd64-pvops pass
build-i386-pvops pass
test-amd64-amd64-xl pass
test-amd64-i386-xl pass
test-amd64-i386-rhel6hvm-amd pass
test-amd64-i386-qemut-rhel6hvm-amd pass
test-amd64-i386-qemuu-rhel6hvm-amd pass
test-amd64-amd64-xl-qemut-win7-amd64 fail
test-amd64-i386-xl-qemut-win7-amd64 fail
test-amd64-amd64-xl-qemuu-win7-amd64 fail
test-amd64-amd64-xl-win7-amd64 fail
test-amd64-i386-xl-win7-amd64 fail
test-amd64-i386-xl-credit2 pass
test-amd64-amd64-xl-pcipt-intel fail
test-amd64-i386-rhel6hvm-intel pass
test-amd64-i386-qemut-rhel6hvm-intel pass
test-amd64-i386-qemuu-rhel6hvm-intel pass
test-amd64-i386-xl-multivcpu pass
test-amd64-amd64-pair pass
test-amd64-i386-pair pass
test-amd64-amd64-xl-sedf-pin pass
test-amd64-amd64-pv pass
test-amd64-i386-pv pass
test-amd64-amd64-xl-sedf fail
test-amd64-i386-xl-qemut-winxpsp3-vcpus1 fail
test-amd64-i386-xl-winxpsp3-vcpus1 fail
test-amd64-i386-xend-qemut-winxpsp3 fail
test-amd64-amd64-xl-qemut-winxpsp3 fail
test-amd64-amd64-xl-qemuu-winxpsp3 fail
test-amd64-i386-xend-winxpsp3 fail
test-amd64-amd64-xl-winxpsp3 fail
------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images
Logs, config files, etc. are available at
http://www.chiark.greenend.org.uk/~xensrcts/logs
Test harness code can be found at
http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary
Pushing revision :
+ branch=xen-unstable
+ revision=96ef6e88359910738905ac2e1969dc05d7d7e7dc
+ . cri-lock-repos
++ . cri-common
+++ . cri-getconfig
+++ umask 002
+++ getconfig Repos
+++ perl -e ''
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
''
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ ''['' x ''!=''
x/export/home/osstest/repos/lock '']''
++ OSSTEST_REPOS_LOCK_LOCKED=/export/home/osstest/repos/lock
++ exec with-lock-ex -w /export/home/osstest/repos/lock ./ap-push xen-unstable
96ef6e88359910738905ac2e1969dc05d7d7e7dc
+ branch=xen-unstable
+ revision=96ef6e88359910738905ac2e1969dc05d7d7e7dc
+ . cri-lock-repos
++ . cri-common
+++ . cri-getconfig
+++ umask 002
+++ getconfig Repos
+++ perl -e ''
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
''
++ repos=/export/home/osstest/repos
++ repos_lock=/export/home/osstest/repos/lock
++ ''['' x/export/home/osstest/repos/lock ''!=''
x/export/home/osstest/repos/lock '']''
+ . cri-common
++ . cri-getconfig
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=xen
+ xenbranch=xen-unstable
+ ''['' xxen = xlinux '']''
+ linuxbranch=linux
+ : master
+ : tested/2.6.39.x
+ . ap-common
++ : osstest@xenbits.xensource.com
++ : git://xenbits.xen.org/xen.git
++ : osstest@xenbits.xensource.com:/home/xen/git/xen.git
++ : git://xenbits.xen.org/staging/qemu-xen-unstable.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/linux-pvops.git
++ : master
++ : git://xenbits.xen.org/osstest/linux-firmware.git
++ : osstest@xenbits.xensource.com:/home/osstest/ext/linux-firmware.git
++ : git://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git
++ : osstest@xenbits.xensource.com:/home/xen/git/linux-pvops.git
++ : git://xenbits.xen.org/linux-pvops.git
++ : master
++ : git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git
++ : tested/2.6.39.x
++ : daily-cron.xen-unstable
++ : daily-cron.xen-unstable
++ : http://hg.uk.xensource.com/carbon/trunk/linux-2.6.27
++ : git://xenbits.xen.org/staging/qemu-upstream-unstable.git
++ : daily-cron.xen-unstable
+ TREE_LINUX=osstest@xenbits.xensource.com:/home/xen/git/linux-pvops.git
+
TREE_QEMU_UPSTREAM=osstest@xenbits.xensource.com:/home/xen/git/qemu-upstream-unstable.git
+ TREE_XEN=osstest@xenbits.xensource.com:/home/xen/git/xen.git
+ info_linux_tree xen-unstable
+ case $1 in
+ return 1
+ case "$branch" in
+ cd /export/home/osstest/repos/xen
+ git push osstest@xenbits.xensource.com:/home/xen/git/xen.git
96ef6e88359910738905ac2e1969dc05d7d7e7dc:master
Total 0 (delta 0), reused 0 (delta 0)
To osstest@xenbits.xensource.com:/home/xen/git/xen.git
e4e1e0e..96ef6e8 96ef6e88359910738905ac2e1969dc05d7d7e7dc -> master
>>> On 22.04.13 at 21:41, xen.org <ian.jackson@eu.citrix.com> wrote: > flight 17780 xen-unstable real [real] > http://www.chiark.greenend.org.uk/~xensrcts/logs/17780/ > > Failures :-/ but no regressions. > > Regressions which are regarded as allowable (not blocking): > test-amd64-amd64-xl-sedf 7 debian-install fail REGR. vs. 17778Ian, how do the timestamps in the serial log get generated? Particularly, are these in any way dependent on the time of the host that the logs originate from? I''m asking because this sequence Apr 22 15:30:59.512179 (XEN) UPD03: t=0030ad29f3b4 l=000c5e44bd4d m=000c5e45242a Apr 22 15:30:59.524107 (XEN) UPD07: t=0030ad29f385 l=000c5e44bcf2 m=000c5e45242a Apr 22 15:30:59.524165 (XEN) UPD06: t=0030ad29f391 l=000c5e44bcf2 m=000c5e45242a Apr 22 15:30:59.532103 (XEN) UPD04: t=0030ad29f3cc l=000c5e44bd3c m=000c5e45242a Apr 22 15:30:59.532157 (XEN) UPD00: t=0030ad29f32e l=000c5e44bd2c m=000c5e45242a Apr 22 15:30:59.544108 (XEN) UPD02: t=0030ad29f3bc l=000c5e44bd50 m=000c5e45242a Apr 22 15:30:59.544164 (XEN) UPD01: t=0030ad29f3d2 l=000c5e44bd22 m=000c5e45242a Apr 22 15:30:59.547711 (XEN) PLT: s=000c5e467b19 c=00008e48a66e Apr 22 15:30:59.547759 (XEN) UPD02: t=00a0375364b2 l=00698c938de5 m=0023b5d300d8 Apr 22 15:37:39.736264 (XEN) UPD01: t=00a0375364de l=00698c938dfb m=0023b5d300d8 Apr 22 15:37:39.748665 (XEN) UPD04: t=00a03753648a l=00698c938dba m=0023b5d300d8 Apr 22 15:37:39.748749 (XEN) UPD06: t=00a0375364be l=00698c938e13 m=0023b5d300d8 Apr 22 15:37:39.756571 (XEN) Platform timer appears to have unexpectedly wrapped 1 times. Apr 22 15:37:39.756631 (XEN) UPD07: t=00a0375364c6 l=00698c938e2b m=0023b5d300d8 Apr 22 15:37:39.768560 (XEN) UPD03: t=00a0375364ba l=00698c938df6 m=0023b5d300d8 Apr 22 15:37:39.768615 (XEN) UPD05: t=00a037536482 l=00698c938dba m=0023b5d300d8 Apr 22 15:37:39.776557 (XEN) PLT: n=00698c93df6f pn=00698d31b1b1 pm=0000ffffffff pw=00af64900db1 Apr 22 15:37:39.776618 (XEN) PLT: c=0000e3d7c0e5 d=823444f2 s=0001e3d7c0e5 Apr 22 15:37:39.788591 (XEN) UPD00: t=00a037536426 l=00698c938de7 m=0023b5d300d8 Apr 22 15:37:39.788647 (XEN) PLT: s=00698d33fccb c=0001e3d7c94d appears to be inconsistent, in that the second UPD02 instance has a log time stamp that is almost 7 minutes too early, while the immediately preceding PLT: line still looks consistent. If this can''t be explained by how the logs get time stamped, this could be a hint at the problem we''re having with the timer code (yet I can''t seem to make sense of that "hint"). All, the almost 7 minute gap hints at C-state management being broken on these machines, yet it already assumes the LAPIC timer to be reliable only in C1, so theoretically the HPET broadcast mechanism ought to keep the CPUs waking up from deeper C states. What''s puzzling too is that these issues only ever occur on SEDF, and with SEDF having been broken entirely until relatively recently, this information can''t really be used to point at some specific time range during which an eventual regression slipped in. Of course, with the issue (as far as I''m aware) never having occurred on 4.2, the new MWAIT idle driver might be part of the problem (despite it leveraging the same HPET/PIT broadcast mechanism as the ACPI one). And wrt SEDF, I don''t think the scheduler itself is at fault here - it seems more likely to me that it merely uses timers in ways sufficiently different from the credit one to (once in a while) have an effect on wakeup behavior. If anyone has any other ideas on how to explain the observed behavior, please let me know! Jan