|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [xen-unstable test] 6532: regressions - trouble: broken/fail/pass
>>> 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
|
 |
Lists.xenproject.org is hosted with RackSpace, monitoring our |