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