| |
|
 |
|
 |
|
|
|
| |
|
|
xen-devel
Re: [Xen-devel] [xen-unstable test] 6970: trouble: blocked/broken/pass
>>> On 02.05.11 at 17:36, xen.org <ian.jackson@xxxxxxxxxxxxx> wrote:
> flight 6970 xen-unstable real [real]
> http://www.chiark.greenend.org.uk/~xensrcts/logs/6970/
>
> Failures and problems with tests :-(
>
> Tests which did not succeed and are blocking:
> build-i386-oldkern 2 host-install(2) broken
> build-i386-pvops 2 host-install(2) broken
> build-i386-xcpkern 2 host-install(2) broken
> build-i386 2 host-install(2) broken
> test-amd64-amd64-win 3 host-install(3) broken
Looking at the logs of just this test, I see
(XEN) Latest ChangeSet: Sun May 01 13:17:44 2011 +0100 23296:24346f749826
despite ...
> test-amd64-amd64-xl-win 3 host-install(3) broken
> test-amd64-amd64-xl 3 host-install(3) broken
>
> Tests which did not succeed, but are not blocking,
> including regressions (tests previously passed) regarded as allowable:
> test-amd64-i386-pair 1 xen-build-check(1) blocked n/a
> test-amd64-i386-pv 1 xen-build-check(1) blocked n/a
> test-amd64-i386-rhel6hvm-amd 1 xen-build-check(1) blocked n/a
> test-amd64-i386-rhel6hvm-intel 1 xen-build-check(1) blocked n/a
> test-amd64-i386-win-vcpus1 1 xen-build-check(1) blocked n/a
> test-amd64-i386-win 1 xen-build-check(1) blocked n/a
> test-amd64-i386-xl-credit2 1 xen-build-check(1) blocked n/a
> test-amd64-i386-xl-multivcpu 1 xen-build-check(1) blocked n/a
> test-amd64-i386-xl-win-vcpus1 1 xen-build-check(1) blocked n/a
> test-amd64-i386-xl 1 xen-build-check(1) blocked n/a
> test-amd64-xcpkern-i386-pair 1 xen-build-check(1) blocked n/a
> test-amd64-xcpkern-i386-pv 1 xen-build-check(1) blocked n/a
> test-amd64-xcpkern-i386-rhel6hvm-amd 1 xen-build-check(1) blocked
> n/a
> test-amd64-xcpkern-i386-rhel6hvm-intel 1 xen-build-check(1) blocked
> n/a
> test-amd64-xcpkern-i386-win 1 xen-build-check(1) blocked n/a
> test-amd64-xcpkern-i386-xl-credit2 1 xen-build-check(1) blocked
> n/a
> test-amd64-xcpkern-i386-xl-multivcpu 1 xen-build-check(1) blocked
> n/a
> test-amd64-xcpkern-i386-xl-win 1 xen-build-check(1) blocked n/a
> test-amd64-xcpkern-i386-xl 1 xen-build-check(1) blocked n/a
> test-i386-i386-pair 1 xen-build-check(1) blocked n/a
> test-i386-i386-pv 1 xen-build-check(1) blocked n/a
> test-i386-i386-win 1 xen-build-check(1) blocked n/a
> test-i386-i386-xl-win 1 xen-build-check(1) blocked n/a
> test-i386-i386-xl 1 xen-build-check(1) blocked n/a
> test-i386-xcpkern-i386-pair 1 xen-build-check(1) blocked n/a
> test-i386-xcpkern-i386-pv 1 xen-build-check(1) blocked n/a
> test-i386-xcpkern-i386-win 1 xen-build-check(1) blocked n/a
> test-i386-xcpkern-i386-xl 1 xen-build-check(1) blocked n/a
>
> version targeted for testing:
> xen 10f27b8b3d63
... this saying it ought to be 23297:10f27b8b3d63. Am I missing
something, or is this some sort glitch of the test framework?
Jan
> baseline version:
> xen 476b0d68e7d5
>
> ------------------------------------------------------------
> People who touched revisions under test:
> Jan Beulich <jbeulich@xxxxxxxxxx>
> Keir Fraser <keir@xxxxxxx>
> Samuel Thibault <samuel.thibault@xxxxxxxxxxxx>
> ------------------------------------------------------------
>
> jobs:
> build-i386-xcpkern broken
> build-amd64 pass
> build-i386 broken
> build-amd64-oldkern pass
> build-i386-oldkern broken
> build-amd64-pvops pass
> build-i386-pvops broken
> test-amd64-amd64-xl broken
> test-amd64-i386-xl blocked
> test-i386-i386-xl blocked
> test-amd64-xcpkern-i386-xl blocked
> test-i386-xcpkern-i386-xl blocked
> test-amd64-i386-rhel6hvm-amd blocked
> test-amd64-xcpkern-i386-rhel6hvm-amd blocked
> test-amd64-i386-xl-credit2 blocked
> test-amd64-xcpkern-i386-xl-credit2 blocked
> test-amd64-i386-rhel6hvm-intel blocked
> test-amd64-xcpkern-i386-rhel6hvm-intel blocked
> test-amd64-i386-xl-multivcpu blocked
> test-amd64-xcpkern-i386-xl-multivcpu blocked
> test-amd64-amd64-pair pass
> test-amd64-i386-pair blocked
> test-i386-i386-pair blocked
> test-amd64-xcpkern-i386-pair blocked
> test-i386-xcpkern-i386-pair blocked
> test-amd64-amd64-pv pass
> test-amd64-i386-pv blocked
> test-i386-i386-pv blocked
> test-amd64-xcpkern-i386-pv blocked
> test-i386-xcpkern-i386-pv blocked
> test-amd64-i386-win-vcpus1 blocked
> test-amd64-i386-xl-win-vcpus1 blocked
> test-amd64-amd64-win broken
> test-amd64-i386-win blocked
> test-i386-i386-win blocked
> test-amd64-xcpkern-i386-win blocked
> test-i386-xcpkern-i386-win blocked
> test-amd64-amd64-xl-win broken
> test-i386-i386-xl-win blocked
> test-amd64-xcpkern-i386-xl-win blocked
>
>
> ------------------------------------------------------------
> 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: 23297:10f27b8b3d63
> tag: tip
> user: Keir Fraser <keir@xxxxxxx>
> date: Mon May 02 12:00:40 2011 +0100
>
> Revert 23295:4891f1f41ba5 and 23296:24346f749826
>
> Fails current lock checking mechanism in spinlock.c in debug=y builds.
>
> Signed-off-by: Keir Fraser <keir@xxxxxxx>
>
>
> changeset: 23296:24346f749826
> user: Jan Beulich <jbeulich@xxxxxxxxxx>
> date: Sun May 01 13:17:44 2011 +0100
>
> replace d->nr_pirqs sized arrays with radix tree
>
> With this it is questionable whether retaining struct domain's
> nr_pirqs is actually necessary - the value now only serves for bounds
> checking, and this boundary could easily be nr_irqs.
>
> Another thing to consider is whether it's worth storing the pirq
> number in struct pirq, to avoid passing the number and a pointer to
> quite a number of functions.
>
> Note that ia64, the build of which is broken currently anyway, is only
> partially fixed up.
>
> Signed-off-by: Jan Beulich <jbeulich@xxxxxxxxxx>
>
>
> changeset: 23295:4891f1f41ba5
> user: Jan Beulich <jbeulich@xxxxxxxxxx>
> date: Sun May 01 13:16:30 2011 +0100
>
> x86: replace nr_irqs sized per-domain arrays with radix trees
>
> It would seem possible to fold the two trees into one (making e.g. the
> emuirq bits stored in the upper half of the pointer), but I'm not
> certain that's worth it as it would make deletion of entries more
> cumbersome. Unless pirq-s and emuirq-s were mutually exclusive...
>
> Signed-off-by: Jan Beulich <jbeulich@xxxxxxxxxx>
>
>
> changeset: 23294:c0a8f889ca9e
> user: Keir Fraser <keir@xxxxxxx>
> date: Sun May 01 13:03:37 2011 +0100
>
> public/arch-ia64/debug_op.h: Reinsert copyright that I accidentally
> deleted.
>
> Signed-off-by: Keir Fraser <keir@xxxxxxx>
>
>
> changeset: 23293:f48c72de4208
> user: Jan Beulich <jbeulich@xxxxxxxxxx>
> date: Sun May 01 10:20:44 2011 +0100
>
> x86: a little bit of cleanup to time.c
>
> Signed-off-by: Jan Beulich <jbeulich@xxxxxxxxxx>
>
>
> changeset: 23292:e2fb962d13ff
> user: Jan Beulich <jbeulich@xxxxxxxxxx>
> date: Sun May 01 10:16:54 2011 +0100
>
> x86: clean up building in mm/hap/
>
> Building 4-level guest walks is unnecessary for x86-32, and with this
> no longer being built the fallback code used here isn't necessary
> anymore either.
>
> Additonally the mechanism to determine the value of
> GUEST_PAGING_LEVELS to be passed to the compiler can be much
> simplified given that we're using a pattern rule here.
>
> Signed-off-by: Jan Beulich <jbeulich@xxxxxxxxxx>
>
>
> changeset: 23291:485b7c5e6f17
> user: Jan Beulich <jbeulich@xxxxxxxxxx>
> date: Sun May 01 10:15:11 2011 +0100
>
> A little bit of SMP boot code cleanup
>
> Signed-off-by: Jan Beulich <jbeulich@xxxxxxxxxx>
>
>
> changeset: 23290:1ac7336b6298
> user: Jan Beulich <jbeulich@xxxxxxxxxx>
> date: Sun May 01 10:14:15 2011 +0100
>
> x86: set ARAT feature flag for non-buggy AMD CPUs
>
> This is the equivalent of a recent Linux change.
>
> Signed-off-by: Jan Beulich <jbeulich@xxxxxxxxxx>
>
>
> changeset: 23289:e4fc9494b940
> user: Samuel Thibault <samuel.thibault@xxxxxxxxxxxx>
> date: Sun May 01 10:11:58 2011 +0100
>
> mini-os: fix lib.h licence
>
> Update the Linux stdio functions prototypes, and move them to a
> separate header, licenced under GPL2+. Import FreeBSD8 string
> functions prototypes, update licence. Drop kvec, of unsure source and
> useless anyway.
>
> Signed-off-by: Samuel Thibault <samuel.thibault@xxxxxxxxxxxx>
>
>
> changeset: 23288:60dfb5aca706
> user: Samuel Thibault <samuel.thibault@xxxxxxxxxxxx>
> date: Sun May 01 10:10:12 2011 +0100
>
> mini-os: lib/math.c: import FreeBSD 8 functions
>
> Import lib/math.c functions (and thus licence) from FreeBSD 8,
> and re-apply a few of our changes. Whitespaces left aside, this
> leads to almost no source change except s/int64_t/quad_t/ and
> s/uint64_t/u_quad_t/.
>
> Signed-off-by: Samuel Thibault <samuel.thibault@xxxxxxxxxxxx>
>
>
> changeset: 23287:bf11f502684a
> user: Samuel Thibault <samuel.thibault@xxxxxxxxxxxx>
> date: Sun May 01 10:09:47 2011 +0100
>
> mini-os: Fix printf.c licence
>
> Changeset df1348e72390 actually completely replaced the freebsd printf
> implementation with the Linux printf implementation. Further changes
> are extremely minor and thus don't pose IP issue. Fix the licence
> accordingly.
>
> Signed-off-by: Samuel Thibault <samuel.thibault@xxxxxxxxxxxx>
>
>
> changeset: 23286:6f48f5f843f0
> user: Keir Fraser <keir@xxxxxxx>
> date: Sun May 01 10:08:40 2011 +0100
>
> Clean up licensing in the public header directory.
>
> The COPYING file at xen/include/public/COPYING clearly states that all
> public header files are distributed under a permissive MIT
> license. Therefore make sure the same permissive license is included
> at the top of every header file (i.e., not GPL).
>
> Signed-off-by: Keir Fraser <keir@xxxxxxx>
>
>
> changeset: 23285:a7ac0a0170b0
> user: Keir Fraser <keir@xxxxxxx>
> date: Sun May 01 09:32:48 2011 +0100
>
> x86: Clean up smp_call_function handling.
>
> We don't need so many communication fields between caller and
> handler.
>
> Signed-off-by: Keir Fraser <keir@xxxxxxx>
>
>
> changeset: 23284:476b0d68e7d5
> user: Keir Fraser <keir@xxxxxxx>
> date: Sat Apr 30 09:48:16 2011 +0100
>
> x86: Remove TRAP_INSTR from the public headers.
>
> Direct hypercall traps (rather than using the hypercall transfer page)
> was long obsolete even when TRAP_INSTR was deprecated in the API
> headers. No current guest will be, or should be, using TRAP_INSTR.
>
> Signed-off-by: Keir Fraser <keir@xxxxxxx>
>
>
> (qemu changes not included)
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@xxxxxxxxxxxxxxxxxxx
> http://lists.xensource.com/xen-devel
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
|
|
| |
|
Home