>>> On 16.03.11 at 22:58, xen.org <ian.jackson@xxxxxxxxxxxxx> wrote:
> flight 6532 xen-unstable real [real]
> http://www.chiark.greenend.org.uk/~xensrcts/logs/6532/
>
> Regressions :-(
>
> Tests which did not succeed and are blocking:
> test-amd64-amd64-pv 5 xen-boot fail REGR. vs.
> 6396
Seems like this is still failing at the same place in hpet.c, despite
23042:599ceb5b0a9b. Is the corresponding xen-syms available
somewhere so I can sort out the condition to (hopefully) get a
hint at what's still wrong?
Thanks, Jan
> test-amd64-amd64-xl-win 3 host-install(3) broken
> test-amd64-i386-rhel6hvm-intel 5 xen-boot fail REGR. vs.
> 6396
> test-amd64-xcpkern-i386-rhel6hvm-intel 5 xen-boot fail REGR. vs.
> 6396
> test-amd64-xcpkern-i386-win 5 xen-boot fail REGR. vs.
> 6396
> test-i386-i386-pair 3 host-install/src_host(3) broken
> test-i386-xcpkern-i386-win 5 xen-boot fail REGR. vs.
> 6396
>
> Tests which did not succeed, but are not blocking,
> including regressions (tests previously passed) regarded as allowable:
> test-amd64-amd64-win 16 leak-check/check fail never
> pass
> test-amd64-i386-rhel6hvm-amd 8 guest-saverestore fail never
> pass
> test-amd64-i386-win-vcpus1 16 leak-check/check fail never
> pass
> test-amd64-i386-win 16 leak-check/check fail never
> pass
> test-amd64-i386-xl-win-vcpus1 13 guest-stop fail never
> pass
> test-amd64-xcpkern-i386-rhel6hvm-amd 8 guest-saverestore fail never
> pass
> test-amd64-xcpkern-i386-xl-win 13 guest-stop fail never
> pass
> test-i386-i386-win 16 leak-check/check fail never
> pass
> test-i386-i386-xl-win 13 guest-stop fail never
> pass
>
> version targeted for testing:
> xen c426a7140c99
> baseline version:
> xen a8fee4ad3ad0
>
> ------------------------------------------------------------
> People who touched revisions under test:
> Gianni Tedesco <gianni.tedesco@xxxxxxxxxx>
> Ian Campbell <ian.campbell@xxxxxxxxxx>
> Ian Jackson <ian.jackson@xxxxxxxxxxxxx>
> Jan Beulich <jbeulich@xxxxxxxxxx>
> Juergen Gross <juergen.gross@xxxxxxxxxxxxxx>
> Keir Fraser <keir@xxxxxxx>
> Stefano Stabellini <stefano.stabellini@xxxxxxxxxxxxx>
> Tim Deegan <Tim.Deegan@xxxxxxxxxx>
> Wei Gang <gang.wei@xxxxxxxxx>
> ------------------------------------------------------------
>
> jobs:
> build-i386-xcpkern pass
> build-amd64 pass
> build-i386 pass
> build-amd64-oldkern pass
> build-i386-oldkern pass
> 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-xcpkern-i386-xl pass
> test-i386-xcpkern-i386-xl pass
> test-amd64-i386-rhel6hvm-amd fail
> test-amd64-xcpkern-i386-rhel6hvm-amd fail
> test-amd64-i386-xl-credit2 pass
> test-amd64-xcpkern-i386-xl-credit2 pass
> test-amd64-i386-rhel6hvm-intel fail
> test-amd64-xcpkern-i386-rhel6hvm-intel fail
> test-amd64-i386-xl-multivcpu pass
> test-amd64-xcpkern-i386-xl-multivcpu pass
> test-amd64-amd64-pair pass
> test-amd64-i386-pair pass
> test-i386-i386-pair broken
> test-amd64-xcpkern-i386-pair pass
> test-i386-xcpkern-i386-pair pass
> test-amd64-amd64-pv fail
> test-amd64-i386-pv pass
> test-i386-i386-pv pass
> test-amd64-xcpkern-i386-pv pass
> test-i386-xcpkern-i386-pv pass
> test-amd64-i386-win-vcpus1 fail
> test-amd64-i386-xl-win-vcpus1 fail
> test-amd64-amd64-win fail
> test-amd64-i386-win fail
> test-i386-i386-win fail
> test-amd64-xcpkern-i386-win fail
> test-i386-xcpkern-i386-win fail
> test-amd64-amd64-xl-win broken
> test-i386-i386-xl-win fail
> test-amd64-xcpkern-i386-xl-win fail
>
>
> ------------------------------------------------------------
> 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: 23045:c426a7140c99
> tag: tip
> user: Ian Campbell <ian.campbell@xxxxxxxxxx>
> date: Tue Mar 15 18:20:46 2011 +0000
>
> libxl: Make all hidden/static functions take a gc not a ctx
>
> Also ensure that static and hidden functions use the libxl__ prefix
> not just libxl_ (in the case of static functions only when they use a
> libxl prefix to start with).
>
> This follows the policy described in libxl.h "libxl memory
> management".
>
> Based on a manual audit of:
> grep ^static tools/libxl/libxl*.[ch]| grep libxl_ctx
> grep libxl__ tools/libxl/*.h| grep libxl_ctx
>
> Signed-off-by: Ian Campbell <ian.campbell@xxxxxxxxxx>
> Committed-by: Ian Jackson <ian.jackson@xxxxxxxxxxxxx>
>
>
> changeset: 23044:d4ca456c0c25
> user: Ian Campbell <ian.campbell@xxxxxxxxxx>
> date: Tue Mar 15 18:19:47 2011 +0000
>
> libxl: do not start a xenpv qemu solely for tap devices if blktap is
> available
>
> qemu is used as a fallback for DISK_BACKEND_TAP if no blktap is
> available but if blktap is available, or for DISK_BACKEND_PHY, we
> don't need a qemu process.
>
> Signed-off-by: Ian Campbell <ian.campbell@xxxxxxxxxx>
> Acked-by: Ian Jackson <ian.jackson@xxxxxxxxxxxxx>
> Committed-by: Ian Jackson <ian.jackson@xxxxxxxxxxxxx>
>
>
> changeset: 23043:3caed2112c65
> user: Juergen Gross <juergen.gross@xxxxxxxxxxxxxx>
> date: Tue Mar 15 10:14:27 2011 +0000
>
> Avoid endless loop for vcpu migration.
>
> Only call SCHED_OP(pick_cpu) if a previously picked cpu is not
> suitable on the current iteration of the retry loop.
>
> Signed-off-by: Juergen Gross <juergen.gross@xxxxxxxxxxxxxx>
> Signed-off-by: Keir Fraser <keir@xxxxxxx>
>
>
> changeset: 23042:599ceb5b0a9b
> user: Jan Beulich <jbeulich@xxxxxxxxxx>
> date: Tue Mar 15 10:02:36 2011 +0000
>
> x86/HPET: fix oversight in 23033:84bacd800bf8
>
> Clearly for the adjusted BUG_ON()s to not yield false positives
> num_chs_used must be incremented before setting up an IRQ (and
> decremented back when the setup failed).
>
> Signed-off-by: Jan Beulich <jbeulich@xxxxxxxxxx>
>
>
> changeset: 23041:9f6dec0d25cd
> user: Jan Beulich <jbeulich@xxxxxxxxxx>
> date: Mon Mar 14 17:20:11 2011 +0000
>
> _csched_cpu_pick(): simplify sched_smt_power_savings dependent condition
>
> At least to me, using ?: instead of the (a && ...) || (!a && ...)
> construct is far easier to grok with a single look.
>
> Signed-off-by: Jan Beulich <jbeulich@xxxxxxxxxx>
>
>
> changeset: 23040:77bb4be5c954
> user: Jan Beulich <jbeulich@xxxxxxxxxx>
> date: Mon Mar 14 17:19:47 2011 +0000
>
> _csched_cpu_pick(): don't write idle bias more than once
>
> For the bias to be really meaningful, it should be updated only when
> the CPU selected will indeed be returned (and hence used for placing
> the vCPU in question).
>
> Signed-off-by: Jan Beulich <jbeulich@xxxxxxxxxx>
>
>
> changeset: 23039:c40da47621d8
> user: Jan Beulich <jbeulich@xxxxxxxxxx>
> date: Mon Mar 14 17:19:22 2011 +0000
>
> _csched_cpu_pick(): don't return CPUs outside vCPU's affinity mask
>
> This fixes a fairly blatant bug I introduced in c/s 20377:cff23354d026
> - I wonder how this went unnoticed for so long.
>
> Signed-off-by: Jan Beulich <jbeulich@xxxxxxxxxx>
>
>
> changeset: 23038:39f5947b1576
> user: Gianni Tedesco <gianni.tedesco@xxxxxxxxxx>
> date: Mon Mar 14 17:13:15 2011 +0000
>
> Allow tools to map arbitrarily large machphys_mfn_list on 32bit dom0
>
> This permits suspend/resume to work with 32bit dom0/tools when system
> memory extends beyond 160GB (and up to 1TB).
>
> AFAICT the limit to MACH2PHYS_COMPAT_NR_ENTRIES is redundant since
> that refers to a limit in 32bit guest compat mappings under 64bit
> hypervisors, not userspace where there may be gigabytes of useful
> virtual space available for this.
>
> Suggested-by: Ian Campbell <Ian.Campbell@xxxxxxxxxxxxx>
> Signed-off-by: Gianni Tedesco <gianni.tedesco@xxxxxxxxxx>
>
>
> changeset: 23037:a29b35408950
> user: Jan Beulich <jbeulich@xxxxxxxxxx>
> date: Mon Mar 14 17:05:21 2011 +0000
>
> x86: fix cpu_sibling_map initialization when topology CPUID leaf is
> present
>
> c/s 21811:12f0618400de broke this by not properly initializing struct
> cpuinfo_x86's x86_num_siblings member (other than Linux, where this is
> a global variable, it is being maintained per CPU by Xen).
>
> Hyper-threaded CPUs with CPUID leaf 0xb present had therefore all
> cpu_sibling_map-s with just a single bit set, thus improperly feeding
> the scheduler.
>
> Signed-off-by: Jan Beulich <jbeulich@xxxxxxxxxx>
>
>
> changeset: 23036:9a15ff175e00
> user: Wei Gang <gang.wei@xxxxxxxxx>
> date: Mon Mar 14 17:04:42 2011 +0000
>
> x86: add volatile prefix for cpuid asm clauses
>
> cpuid results are possible to be changed now. For example, changing
> CR4.OSXSAVE bit or setting MSR XCR_XFEATURE_ENABLED_MASK may change
> XSAVE related cpuid leave return values.
>
> The volatile prefix is required to avoid the second cpuid calls
> following some possible changing operations being optimized in
> incorrect way by compiler.
>
> The sample bug is in xsave_init while debug=3Dn. The second call to
> cpuid_count() may be optimized and lead to a BUG_ON case while compare
> xsave_cntxt_size with ebx.
>
> Signed-off-by: Wei Gang <gang.wei@xxxxxxxxx>
>
>
> changeset: 23035:56dc6032b45f
> user: Jan Beulich <jbeulich@xxxxxxxxxx>
> date: Mon Mar 14 17:02:50 2011 +0000
>
> Force out-of-line instances of inline functions into .init.text in
> init-only code
>
> Some compiler versions may choose to not inline certain functions, but
> the check introduced in c/s 23003:768269c43914 wants .text to be
> empty.
>
> Also make sure an eventual error gets properly propagated even on the
> first section of an object (.text typically being the first one), and
> cover a broader set of sections.
>
> Signed-off-by: Jan Beulich <jbeulich@xxxxxxxxxx>
>
>
> changeset: 23034:c79aae866ad8
> user: Tim Deegan <Tim.Deegan@xxxxxxxxxx>
> date: Mon Mar 14 16:59:49 2011 +0000
>
> x86_64: fix error checking in arch_set_info_guest()
>
> Cannot specify user mode execution without specifying user-mode
> pagetables.
>
> Signed-off-by: Tim Deegan <Tim.Deegan@xxxxxxxxxx>
> Acked-by: Keir Fraser <keir@xxxxxxx>
>
>
> changeset: 23033:84bacd800bf8
> user: Jan Beulich <jbeulich@xxxxxxxxxx>
> date: Sat Mar 12 13:20:51 2011 +0000
>
> x86/HPET: adjust types
>
> 'unsigned int' is better suited as an array index on x86-64.
>
> 'u32' produces better code than 'unsigned long' on x86-64, so use the
> former for storing 32-bit values read from the hardware.
>
> this_cpu() uses an implicit smp_processor_id(), and hence using
> per_cpu() when the result of smp_processor_id() is already available
> is more efficient.
>
> Fold one case of cpu_isset()+cpu_clear() into cpu_test_and_clear().
>
> Drop the unused return value of evt_do_broadcast().
>
> Signed-off-by: Jan Beulich <jbeulich@xxxxxxxxxx>
> Acked-by: Wei Gang <gang.wei@xxxxxxxxx>
>
>
> changeset: 23032:ac572e1df261
> user: Jan Beulich <jbeulich@xxxxxxxxxx>
> date: Sat Mar 12 13:20:11 2011 +0000
>
> x86/HPET: use dynamic allocation for hpet_events[]
>
> Typically there are far less than 32 counters available, and hence
> there's no use in wasting the memory on (almost) every system.
>
> Signed-off-by: Jan Beulich <jbeulich@xxxxxxxxxx>
> Acked-by: Wei Gang <gang.wei@xxxxxxxxx>
>
>
> changeset: 23031:5263151fba9b
> user: Jan Beulich <jbeulich@xxxxxxxxxx>
> date: Sat Mar 12 13:19:34 2011 +0000
>
> x86/HPET: cleanup
>
> - separate init and resume code paths (so that the [larger] init parts
> can go init .init.* sections)
> - drop the separate legacy_hpet_event object, as we can easily re-use
> the first slot of hpet_events[] for that purpose (the whole array is
> otherwise unused when the legacy code is being used)
> - use section placement attributes where reasonable
>
> Signed-off-by: Jan Beulich <jbeulich@xxxxxxxxxx>
> Acked-by: Wei Gang <gang.wei@xxxxxxxxx>
>
>
> changeset: 23030:87aa1277eae0
> user: Jan Beulich <jbeulich@xxxxxxxxxx>
> date: Sat Mar 12 13:19:02 2011 +0000
>
> x86/HPET: fix initialization order
>
> At least the legacy path can enter its interrupt handler callout while
> initialization is still in progress - that handler checks whether
> ->event_handler is non-NULL, and hence all other initialization must
> happen before setting this field.
>
> Do the same to the MSI initialization just in case (and to keep the
> code in sync).
>
> Signed-off-by: Jan Beulich <jbeulich@xxxxxxxxxx>
>
>
> changeset: 23029:a8fee4ad3ad0
> user: Stefano Stabellini <stefano.stabellini@xxxxxxxxxxxxx>
> date: Fri Mar 11 18:22:23 2011 +0000
>
> libxl: do not try to use blktap with qdisk
>
> libxl_device_disk_add tries to use blktap when available even for qdisk
> devices, this patch fixes it.
>
> Signed-off-by: Stefano Stabellini <stefano.stabellini@xxxxxxxxxxxxx>
> Acked-by: Ian Jackson <ian.jackson@xxxxxxxxxxxxx>
> Committed-by: Ian Jackson <ian.jackson@xxxxxxxxxxxxx>
>
>
> (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