| |
|
 |
|
 |
|
|
|
| |
|
|
xen-devel
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
|
|
|
| |
|
Home