flight 18426 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/18426/
Failures :-/ but no regressions.
Regressions which are regarded as allowable (not blocking):
test-amd64-i386-rhel6hvm-intel 9 guest-start.2 fail like 18423
test-amd64-i386-qemut-rhel6hvm-intel 7 redhat-install fail like 18424
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-xend-qemut-winxpsp3 16 leak-check/check fail never pass
test-amd64-i386-xl-qemut-winxpsp3-vcpus1 13 guest-stop fail never pass
version targeted for testing:
xen d7f913b8de206464f2a18e4c6d20886d32483de3
baseline version:
xen 395f777ae0eed67b03596fe38d6d90f307ddd036
------------------------------------------------------------
People who touched revisions under test:
Jan Beulich <jbeulich@suse.com>
Keir Fraser <keir@xen.org>
Suravee Suthikulpanit <suravee.suthikulpanit@amd.com>
------------------------------------------------------------
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 fail
test-amd64-i386-qemut-rhel6hvm-intel fail
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 pass
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=d7f913b8de206464f2a18e4c6d20886d32483de3
+ . 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
d7f913b8de206464f2a18e4c6d20886d32483de3
+ branch=xen-unstable
+ revision=d7f913b8de206464f2a18e4c6d20886d32483de3
+ . 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
d7f913b8de206464f2a18e4c6d20886d32483de3:master
Total 0 (delta 0), reused 0 (delta 0)
To osstest@xenbits.xensource.com:/home/xen/git/xen.git
395f777..d7f913b d7f913b8de206464f2a18e4c6d20886d32483de3 -> master
>>> On 15.07.13 at 23:33, xen.org <ian.jackson@eu.citrix.com> wrote: > flight 18426 xen-unstable real [real] > http://www.chiark.greenend.org.uk/~xensrcts/logs/18426/ > > Failures :-/ but no regressions. > > Regressions which are regarded as allowable (not blocking): > test-amd64-i386-rhel6hvm-intel 9 guest-start.2 fail like 18423 > test-amd64-i386-qemut-rhel6hvm-intel 7 redhat-install fail like 18424So 8bfaa2c2 ("x86: add locking to map_pages_to_xen()") didn''t really help, but it''s not yet clear to me what else is wrong here. I''m in particular puzzled by the faulting address always being ffff82c00020bxxx, never anything closer to the critical 2Mb boundary. And of course it doesn''t help that I don''t see this in any of my own tests. So if anyone else has an idea, please share. If nothing else, we may need to throw in a debugging patch to track L2 page table population in the VMAP address range... Or wait - I overlooked yesterday that vunmap() is also using destroy_xen_mappings(), i.e. one of the races explicitly not being dealt with by above change is still possible here. This then needs to be switched to map_pages_to_xen(..., 0) too. But then I wonder whether we shouldn''t stop the attempt of freeing intermediate page tables altogether, and short circuit destroy_xen_mappings() into map_pages_to_xen(..., 0). But before I propose a patch to do either of these, I''d really like to understand which other (un)mapping it is that we race with here (resulting - as pointed out above - in the fault being at always the same virtual page frame). Jan
>>> On 16.07.13 at 09:42, "Jan Beulich" <JBeulich@suse.com> wrote: > But before I propose a patch to do either of these, I''d really > like to understand which other (un)mapping it is that we race > with here (resulting - as pointed out above - in the fault being > at always the same virtual page frame).So one race is with domain destruction calling vunmap(), but that still can''t explain all of the crashes the logs hold: There is at least one case where it''s the very first guest that causes the crash. Hence I''m still unclear about what else is going wrong (and I''m not seeing runtime vunmap()-s other than during domain destruction). Hence I guess I''ll propose a patch that switches vunmap() to use map_pages_to_xen(..., 0) on x86 and at the same time adds temporary logging to vmap() and vunmap(). Unless anyone has any better idea of course. Jan