|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] 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
|
 |
Lists.xenproject.org is hosted with RackSpace, monitoring our |