|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [xen-unstable test] 6712: regressions - FAIL
Test harness failing to clone the qemu git repo. Some test network problem possibly. -- Keir On 28/03/2011 16:21, "Ian Jackson" <Ian.Jackson@xxxxxxxxxxxxx> wrote: > flight 6712 xen-unstable real [real] > http://www.chiark.greenend.org.uk/~xensrcts/logs/6712/ > > Regressions :-( > > Tests which did not succeed and are blocking: > build-amd64-oldkern 4 xen-build fail REGR. vs. > 6658 > build-amd64 4 xen-build fail REGR. vs. > 6658 > build-i386-oldkern 4 xen-build fail REGR. vs. > 6658 > build-i386 4 xen-build fail REGR. vs. > 6658 > > Tests which did not succeed, but are not blocking, > including regressions (tests previously passed) regarded as allowable: > test-amd64-amd64-pair 1 xen-build-check(1) blocked n/a > test-amd64-amd64-pv 1 xen-build-check(1) blocked n/a > test-amd64-amd64-win 1 xen-build-check(1) blocked n/a > test-amd64-amd64-xl-win 1 xen-build-check(1) blocked n/a > test-amd64-amd64-xl 1 xen-build-check(1) blocked n/a > 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 9549c04a8384 > baseline version: > xen a65612bcbb92 > > ------------------------------------------------------------ > People who touched revisions under test: > Gang Wei <gang.wei@xxxxxxxxx> > Ian Campbell <ian.campbell@xxxxxxxxxx> > Jan Beulich <jbeulich@xxxxxxxxxx> > Keir Fraser <keir@xxxxxxx> > ------------------------------------------------------------ > > jobs: > build-i386-xcpkern pass > build-amd64 fail > build-i386 fail > build-amd64-oldkern fail > build-i386-oldkern fail > build-amd64-pvops pass > build-i386-pvops pass > test-amd64-amd64-xl blocked > 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 blocked > 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 blocked > 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 blocked > 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 blocked > 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: 23107:9549c04a8384 > tag: tip > user: Keir Fraser <keir@xxxxxxx> > date: Mon Mar 28 13:44:08 2011 +0100 > > x86: Remove _PAGE_NX defintiion (with implicit use of cpu_has_nx). > > Most users can use _PAGE_NX_BIT directly. > > The few genuine users in mm.c can do the cpu_has_nx check more clearly > in other ways. > > Signed-off-by: Keir Fraser <keir@xxxxxxx> > > > changeset: 23106:bbf4b6dd9c32 > user: Jan Beulich <jbeulich@xxxxxxxxxx> > date: Mon Mar 28 12:07:52 2011 +0100 > > x86: cleanup after tboot fix (c/s 23101:dd386a4b6595) > > When submitting the patch that became 23101:dd386a4b6595 I forgot that > I actually intended to remove the pointless IRQ disabling and > restoring (and the then pointless comment). Pointless because the > code, other than its pre-23013:65d26504e843 original, now runs before > interrupts get enabled for the first time. > > Signed-off-by: Jan Beulich <jbeulich@xxxxxxxxxx> > > > changeset: 23105:c4576aafb21e > user: Keir Fraser <keir@xxxxxxx> > date: Sun Mar 27 17:04:02 2011 +0100 > > xend: Fix startup after removal of ACM support. > > Signed-off-by: Keir Fraser <keir@xxxxxxx> > > > changeset: 23104:0bc1c4746c89 > user: Keir Fraser <keir@xxxxxxx> > date: Sun Mar 27 09:30:35 2011 +0100 > > x86_32: Fix _raw_read_trylock() build on some gcc versions. > > Was broken by 23099:612171ff82ea. > > A bool_t is a single byte, and needs a 'q' register constraint. Avoid > the whole issue by changing the variable to an int, and explicitly > specify the operand suffix as 'l' for good measure. > > Signed-off-by: Keir Fraser <keir@xxxxxxx> > > > changeset: 23103:48dac730a93b > user: Keir Fraser <keir@xxxxxxx> > date: Sat Mar 26 09:42:01 2011 +0000 > > x86: __pirq_guest_eoi() must check it is called for a fully > guest-bound irq before accessing desc->action. > > Signed-off-by: Keir Fraser <keir@xxxxxxx> > > > changeset: 23102:8f001d864fef > user: Jan Beulich <jbeulich@xxxxxxxxxx> > date: Sat Mar 26 09:30:38 2011 +0000 > > x86/ATS: remove unreferenced lock member from struct pci_ats_dev > > Otherwise this may give the false impression that some explicit > locking is done in this code. > > Signed-off-by: Jan Beulich <jbeulich@xxxxxxxxxx> > > > changeset: 23101:dd386a4b6595 > user: Jan Beulich <jbeulich@xxxxxxxxxx> > date: Sat Mar 26 09:30:04 2011 +0000 > > x86: fix tboot after c/s 23013:65d26504e843 (ACPI cleanup) > > TXT code calls acpi_parse_dmar() with a transient copy of the DMAR > table, and hence storing the pointer for later reference was wrong. > Obtain the pointer in acpi_dmar_init() instead. > > Signed-off-by: Jan Beulich <jbeulich@xxxxxxxxxx> > Tested-by: Gang Wei <gang.wei@xxxxxxxxx> > > > changeset: 23100:ef8dd40422c8 > user: Keir Fraser <keir@xxxxxxx> > date: Sat Mar 26 08:27:41 2011 +0000 > > Remove spin_barrier_irq(). It is pointless. > > Add a barrier-appropriate consistency check to spinlock.c, and add > code comments to explain why barrier operations are more relaxed than > lock-acquisition operations. > > Signed-off-by: Keir Fraser <keir@xxxxxxx> > > > changeset: 23099:612171ff82ea > user: Keir Fraser <keir@xxxxxxx> > date: Sat Mar 26 08:03:21 2011 +0000 > > rwlock: Allow to scale to 2^31-1 readers on x86. > > Also rework to match the 'trylock' style of raw function used for > spinlocks. > > Inspired by Jan Beulich's patch to do similar improved scaling. > > Signed-off-by: Keir Fraser <keir@xxxxxxx> > > > changeset: 23098:c9f745c153ec > user: Keir Fraser <keir@xxxxxxx> > date: Fri Mar 25 21:59:20 2011 +0000 > > tools: vnet: Remove > > Build has been broken since at least 18969:d6889b3b6423 (early > 2009) and it has been unhooked from the top level build since forever > AFAICT. The last actual development (as opposed to tree wide > cleanups and build fixes) appears to have been 11594:6d7bba6443ef in > 2006. The functionality of vnet has apparently been superceded by > VLANs, ebtables, Ethernet-over-IP etc all of which are well integrated > with upstream kernels and distros. > > Signed-off-by: Ian Campbell <ian.campbell@xxxxxxxxxx> > Signed-off-by: Keir Fraser <keir@xxxxxxx> > > > changeset: 23097:2aeebd5cbbad > user: Keir Fraser <keir@xxxxxxx> > date: Fri Mar 25 21:47:57 2011 +0000 > > Remove unmaintained Access Control Module (ACM) from hypervisor. > > Signed-off-by: Keir Fraser <keir@xxxxxxx> > > > changeset: 23096:a65612bcbb92 > user: Jan Beulich <jbeulich@xxxxxxxxxx> > date: Fri Mar 25 09:03:17 2011 +0000 > > x86/hpet: eliminate cpumask_lock > > According to the (now getting removed) comment in struct > hpet_event_channel, this was to prevent accessing a CPU's > timer_deadline after it got cleared from cpumask. This can be done > without a lock altogether - hpet_broadcast_exit() can simply clear > the bit, and handle_hpet_broadcast() can read timer_deadline before > looking at the mask a second time (the cpumask bit was already > found set by the surrounding loop). > > Signed-off-by: Jan Beulich <jbeulich@xxxxxxxxxx> > Acked-by: Gang Wei <gang.wei@xxxxxxxxx> > > > (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 |