* [xen-unstable test] 6532: regressions - trouble: broken/fail/pass
@ 2011-03-16 21:58 xen.org
2011-03-17 10:32 ` Jan Beulich
0 siblings, 1 reply; 4+ messages in thread
From: xen.org @ 2011-03-16 21:58 UTC (permalink / raw)
To: xen-devel; +Cc: ian.jackson
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
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)
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [xen-unstable test] 6532: regressions - trouble: broken/fail/pass
2011-03-16 21:58 [xen-unstable test] 6532: regressions - trouble: broken/fail/pass xen.org
@ 2011-03-17 10:32 ` Jan Beulich
2011-03-17 10:43 ` Jan Beulich
2011-03-17 19:47 ` Ian Jackson
0 siblings, 2 replies; 4+ messages in thread
From: Jan Beulich @ 2011-03-17 10:32 UTC (permalink / raw)
To: ian.jackson; +Cc: xen-devel
>>> 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
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [xen-unstable test] 6532: regressions - trouble: broken/fail/pass
2011-03-17 10:32 ` Jan Beulich
@ 2011-03-17 10:43 ` Jan Beulich
2011-03-17 19:47 ` Ian Jackson
1 sibling, 0 replies; 4+ messages in thread
From: Jan Beulich @ 2011-03-17 10:43 UTC (permalink / raw)
To: xen-devel; +Cc: ian.jackson
>>> On 17.03.11 at 11:32, "Jan Beulich" <JBeulich@novell.com> wrote:
>>>> 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?
Oh, no, I see what's wrong: That c/s only adjusts a variable local
to hpet_fsb_cap_lookup(), but num_hpets_used gets set to
non-zero only once hpet_fsb_cap_lookup() returns. I think the
local variable should go away altogether, as it being non-zero
(no matter how large) will in any case mean the legacy code path
won't be used.
I'll send another fixup patch shortly.
Jan
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [xen-unstable test] 6532: regressions - trouble: broken/fail/pass
2011-03-17 10:32 ` Jan Beulich
2011-03-17 10:43 ` Jan Beulich
@ 2011-03-17 19:47 ` Ian Jackson
1 sibling, 0 replies; 4+ messages in thread
From: Ian Jackson @ 2011-03-17 19:47 UTC (permalink / raw)
To: Jan Beulich; +Cc: xen-devel
Jan Beulich writes ("Re: [Xen-devel] [xen-unstable test] 6532: regressions - trouble: broken/fail/pass"):
> > 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?
In general you can find them by starting at this URL:
> > http://www.chiark.greenend.org.uk/~xensrcts/logs/6532/
You'll see a number of "build-" and "test-" columns. Click on the
column heading for the failed test, in this case:
http://www.chiark.greenend.org.uk/~xensrcts/logs/6532/test-amd64-amd64-pv/info.html
and look for the table of "Test control variables". There are entries
there for "xenbuildjob" (the hypervisor), "buildjob" (tools),
"kernbuildjob" (dom0 kernel).
Since you're asking for the Xen symbols file, you want the
"xenbuildjob" ie "build-amd64". In fact, as it happens, all the tests
"test-amd64-*" use the same 64-bit hypervisor build from
"build-amd64".
So then you go back to the table and click on the "build-amd64" column
heading:
http://www.chiark.greenend.org.uk/~xensrcts/logs/6532/build-amd64/info.html
In the "Logfiles etc." click on "build/ (outputs from build)" and
download "xendist.tar.gz". In the boot/ directory of that tarball are
the symbols.
Ian.
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2011-03-17 19:47 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2011-03-16 21:58 [xen-unstable test] 6532: regressions - trouble: broken/fail/pass xen.org
2011-03-17 10:32 ` Jan Beulich
2011-03-17 10:43 ` Jan Beulich
2011-03-17 19:47 ` Ian Jackson
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).