From: "Jan Beulich" <JBeulich@novell.com>
To: ian.jackson@eu.citrix.com
Cc: xen-devel@lists.xensource.com
Subject: Re: [xen-unstable test] 6532: regressions - trouble: broken/fail/pass
Date: Thu, 17 Mar 2011 10:32:11 +0000 [thread overview]
Message-ID: <4D81F13B020000780003708F@vpn.id2.novell.com> (raw)
In-Reply-To: <osstest-6532-mainreport@xen.org>
>>> On 16.03.11 at 22:58, xen.org <ian.jackson@eu.citrix.com> 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@citrix.com>
> Ian Campbell <ian.campbell@citrix.com>
> Ian Jackson <ian.jackson@eu.citrix.com>
> Jan Beulich <jbeulich@novell.com>
> Juergen Gross <juergen.gross@ts.fujitsu.com>
> Keir Fraser <keir@xen.org>
> Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> Tim Deegan <Tim.Deegan@citrix.com>
> Wei Gang <gang.wei@intel.com>
> ------------------------------------------------------------
>
> 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@citrix.com>
> 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@citrix.com>
> Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
>
>
> changeset: 23044:d4ca456c0c25
> user: Ian Campbell <ian.campbell@citrix.com>
> 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@citrix.com>
> Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
> Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
>
>
> changeset: 23043:3caed2112c65
> user: Juergen Gross <juergen.gross@ts.fujitsu.com>
> 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@ts.fujitsu.com>
> Signed-off-by: Keir Fraser <keir@xen.org>
>
>
> changeset: 23042:599ceb5b0a9b
> user: Jan Beulich <jbeulich@novell.com>
> 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@novell.com>
>
>
> changeset: 23041:9f6dec0d25cd
> user: Jan Beulich <jbeulich@novell.com>
> 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@novell.com>
>
>
> changeset: 23040:77bb4be5c954
> user: Jan Beulich <jbeulich@novell.com>
> 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@novell.com>
>
>
> changeset: 23039:c40da47621d8
> user: Jan Beulich <jbeulich@novell.com>
> 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@novell.com>
>
>
> changeset: 23038:39f5947b1576
> user: Gianni Tedesco <gianni.tedesco@citrix.com>
> 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@eu.citrix.com>
> Signed-off-by: Gianni Tedesco <gianni.tedesco@citrix.com>
>
>
> changeset: 23037:a29b35408950
> user: Jan Beulich <jbeulich@novell.com>
> 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@novell.com>
>
>
> changeset: 23036:9a15ff175e00
> user: Wei Gang <gang.wei@intel.com>
> 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@intel.com>
>
>
> changeset: 23035:56dc6032b45f
> user: Jan Beulich <jbeulich@novell.com>
> 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@novell.com>
>
>
> changeset: 23034:c79aae866ad8
> user: Tim Deegan <Tim.Deegan@citrix.com>
> 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@citrix.com>
> Acked-by: Keir Fraser <keir@xen.org>
>
>
> changeset: 23033:84bacd800bf8
> user: Jan Beulich <jbeulich@novell.com>
> 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@novell.com>
> Acked-by: Wei Gang <gang.wei@intel.com>
>
>
> changeset: 23032:ac572e1df261
> user: Jan Beulich <jbeulich@novell.com>
> 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@novell.com>
> Acked-by: Wei Gang <gang.wei@intel.com>
>
>
> changeset: 23031:5263151fba9b
> user: Jan Beulich <jbeulich@novell.com>
> 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@novell.com>
> Acked-by: Wei Gang <gang.wei@intel.com>
>
>
> changeset: 23030:87aa1277eae0
> user: Jan Beulich <jbeulich@novell.com>
> 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@novell.com>
>
>
> changeset: 23029:a8fee4ad3ad0
> user: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> 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@eu.citrix.com>
> Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
> Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
>
>
> (qemu changes not included)
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel
next prev parent reply other threads:[~2011-03-17 10:32 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-03-16 21:58 [xen-unstable test] 6532: regressions - trouble: broken/fail/pass xen.org
2011-03-17 10:32 ` Jan Beulich [this message]
2011-03-17 10:43 ` Jan Beulich
2011-03-17 19:47 ` Ian Jackson
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4D81F13B020000780003708F@vpn.id2.novell.com \
--to=jbeulich@novell.com \
--cc=ian.jackson@eu.citrix.com \
--cc=xen-devel@lists.xensource.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).