From: xen.org <ian.jackson@eu.citrix.com>
To: xen-devel@lists.xensource.com
Cc: ian.jackson@eu.citrix.com
Subject: [xen-4.1-testing test] 8285: trouble: broken/fail/pass
Date: Tue, 26 Jul 2011 18:23:14 +0100 [thread overview]
Message-ID: <osstest-8285-mainreport@xen.org> (raw)
flight 8285 xen-4.1-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/8285/
Failures and problems with tests :-(
Tests which did not succeed and are blocking:
test-amd64-i386-rhel6hvm-intel 3 host-install(3) broken
build-i386-oldkern 2 host-install(2) broken
test-amd64-i386-win-vcpus1 3 host-install(3) broken
test-i386-i386-xl-win 3 host-install(3) broken
test-i386-i386-win 3 host-install(3) broken
test-amd64-i386-xl-win-vcpus1 8 capture-logs(8) running
test-amd64-i386-xl-credit2 3 host-install(3) broken in 8281
test-amd64-amd64-pv 3 host-install(3) broken in 8281
test-amd64-amd64-xl-win 3 host-install(3) broken in 8281
Tests which are failing intermittently (not blocking):
test-amd64-i386-xl-win-vcpus1 7 windows-install fail pass in 8281
Tests which did not succeed, but are not blocking,
including regressions (tests previously passed) regarded as allowable:
test-amd64-amd64-xl-pcipt-intel 9 guest-start fail never pass
test-amd64-i386-rhel6hvm-amd 9 guest-start.2 fail never pass
test-amd64-i386-win 16 leak-check/check fail never pass
test-amd64-amd64-xl-win 13 guest-stop fail never pass
test-amd64-amd64-win 16 leak-check/check fail never pass
test-amd64-i386-rhel6hvm-intel 9 guest-start.2 fail in 8281 never pass
test-amd64-i386-win-vcpus1 16 leak-check/check fail in 8281 never pass
test-amd64-i386-xl-win-vcpus1 13 guest-stop fail in 8281 never pass
version targeted for testing:
xen cb22fa57ff25
baseline version:
xen 4d5c76248de3
------------------------------------------------------------
People who touched revisions under test:
Roger Pau Monne <roger.pau@entel.upc.edu>
Tim Deegan <Tim.Deegan@citrix.com>
------------------------------------------------------------
jobs:
build-amd64 pass
build-i386 pass
build-amd64-oldkern pass
build-i386-oldkern broken
build-amd64-pvops pass
build-i386-pvops pass
test-amd64-amd64-xl pass
test-amd64-i386-xl pass
test-i386-i386-xl pass
test-amd64-i386-rhel6hvm-amd fail
test-amd64-i386-xl-credit2 pass
test-amd64-amd64-xl-pcipt-intel fail
test-amd64-i386-rhel6hvm-intel broken
test-amd64-i386-xl-multivcpu pass
test-amd64-amd64-pair pass
test-amd64-i386-pair pass
test-i386-i386-pair pass
test-amd64-amd64-pv pass
test-amd64-i386-pv pass
test-i386-i386-pv pass
test-amd64-i386-win-vcpus1 broken
test-amd64-i386-xl-win-vcpus1 fail
test-amd64-amd64-win fail
test-amd64-i386-win fail
test-i386-i386-win broken
test-amd64-amd64-xl-win fail
test-i386-i386-xl-win broken
------------------------------------------------------------
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
Not pushing.
------------------------------------------------------------
changeset: 23111:cb22fa57ff25
tag: tip
user: Tim Deegan <Tim.Deegan@citrix.com>
date: Mon Jul 25 16:48:39 2011 +0100
VT-d: always clean up dpci timers.
If a VM has all its PCI devices deassigned, need_iommu(d) becomes
false but it might still have DPCI EOI timers that were init_timer()d
but not yet kill_timer()d. That causes xen to crash later because the
linked list of inactive timers gets corrupted, e.g.:
(XEN) Xen call trace:
(XEN) [<ffff82c480126256>] set_timer+0x1c2/0x24f
(XEN) [<ffff82c48011fbf8>] schedule+0x129/0x5dd
(XEN) [<ffff82c480122c1e>] __do_softirq+0x7e/0x89
(XEN) [<ffff82c480122c9d>] do_softirq+0x26/0x28
(XEN) [<ffff82c480153c85>] idle_loop+0x5a/0x5c
(XEN)
(XEN)
(XEN) ****************************************
(XEN) Panic on CPU 0:
(XEN) Assertion 'entry->next->prev == entry' failed at
/local/scratch/tdeegan/xen-unstable.hg/xen/include:172
(XEN) ****************************************
The following patch makes sure that the domain destruction path always
clears up the DPCI state even if !needs_iommu(d).
Signed-off-by: Tim Deegan <Tim.Deegan@citrix.com>
xen-unstable changeset: 23746:aa54b8175954
xen-unstable date: Mon Jul 25 16:41:33 2011 +0100
changeset: 23110:4d5c76248de3
user: Roger Pau Monne <roger.pau@entel.upc.edu>
date: Sat Jul 23 09:01:25 2011 +0100
xend: remove PCI device listing from NetBSD, since it's Linux
specific code.
Signed-off-by: Roger Pau Monne <roger.pau@entel.upc.edu>
xen-unstable changeset: 23738:88847c424eec
xen-unstable date: Sat Jul 23 08:58:37 2011 +0100
(qemu changes not included)
reply other threads:[~2011-07-26 17:23 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=osstest-8285-mainreport@xen.org \
--to=ian.jackson@eu.citrix.com \
--cc=xen-devel@lists.xensource.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.