* [xen-unstable test] 8803: regressions - FAIL
@ 2011-09-01 15:59 xen.org
2011-09-01 16:23 ` Ian Jackson
0 siblings, 1 reply; 5+ messages in thread
From: xen.org @ 2011-09-01 15:59 UTC (permalink / raw)
To: xen-devel; +Cc: ian.jackson
flight 8803 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/8803/
Regressions :-(
Tests which did not succeed and are blocking:
test-amd64-i386-rhel6hvm-intel 4 xen-install fail REGR. vs. 8769
test-amd64-i386-xl 4 xen-install fail REGR. vs. 8769
test-amd64-i386-pair 6 xen-install/dst_host fail REGR. vs. 8769
test-amd64-i386-pair 5 xen-install/src_host fail REGR. vs. 8769
test-amd64-i386-xl-credit2 4 xen-install fail REGR. vs. 8769
build-i386 4 xen-build fail REGR. vs. 8769
test-amd64-i386-pv 4 xen-install fail REGR. vs. 8769
build-i386-oldkern 4 xen-build fail REGR. vs. 8769
test-amd64-i386-xl-multivcpu 4 xen-install fail REGR. vs. 8769
test-amd64-i386-win-vcpus1 4 xen-install fail REGR. vs. 8769
test-amd64-i386-rhel6hvm-amd 4 xen-install fail REGR. vs. 8769
test-amd64-i386-win 4 xen-install fail REGR. vs. 8769
test-amd64-i386-xl-win-vcpus1 4 xen-install fail REGR. vs. 8769
Tests which did not succeed, but are not blocking,
including regressions (tests previously passed) regarded as allowable:
test-amd64-amd64-xl-pcipt-intel 9 guest-start fail never pass
test-i386-i386-pv 1 xen-build-check(1) blocked n/a
test-i386-i386-xl 1 xen-build-check(1) blocked n/a
test-amd64-amd64-xl-sedf 11 guest-localmigrate fail like 8769
test-i386-i386-pair 1 xen-build-check(1) blocked n/a
test-amd64-amd64-xl-win 13 guest-stop fail never pass
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-amd64-amd64-win 16 leak-check/check fail never pass
version targeted for testing:
xen 85b29185c911
baseline version:
xen ac9aa65050e9
------------------------------------------------------------
People who touched revisions under test:
Andrew Cooper <andrew.cooper3@citrix.com>
Christoph Egger <Christoph.Egger@amd.com>
Dietmar Hahn <dietmar.hahn@ts.fujitsu.com>
Ian Jackson <ian.jackson@eu.citrix.com>
Keir Fraser <keir@xen.org>
Kevin Tian <kevin.tian@intel.com>
Laszlo Ersek <lersek@redhat.com>
Olaf Hering <olaf@aepfle.de>
Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Tim Deegan <tim@xen.org>
------------------------------------------------------------
jobs:
build-amd64 pass
build-i386 fail
build-amd64-oldkern pass
build-i386-oldkern fail
build-amd64-pvops pass
build-i386-pvops pass
test-amd64-amd64-xl pass
test-amd64-i386-xl fail
test-i386-i386-xl blocked
test-amd64-i386-rhel6hvm-amd fail
test-amd64-i386-xl-credit2 fail
test-amd64-amd64-xl-pcipt-intel fail
test-amd64-i386-rhel6hvm-intel fail
test-amd64-i386-xl-multivcpu fail
test-amd64-amd64-pair pass
test-amd64-i386-pair fail
test-i386-i386-pair blocked
test-amd64-amd64-pv pass
test-amd64-i386-pv fail
test-i386-i386-pv blocked
test-amd64-amd64-xl-sedf fail
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 blocked
test-amd64-amd64-xl-win fail
test-i386-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: 23809:85b29185c911
tag: tip
user: Tim Deegan <tim@xen.org>
date: Thu Sep 01 09:39:25 2011 +0100
x86/mm: use defines for page sizes rather hardcoding them.
Signed-off-by: Christoph Egger <Christoph.Egger@amd.com>
Acked-by: Tim Deegan <tim@xen.org>
Committed-by: Tim Deegan <tim@xen.org>
changeset: 23808:4a4882df5649
user: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
date: Wed Aug 31 15:23:49 2011 +0100
xen: get_free_pirq: make sure that the returned pirq is allocated
Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
changeset: 23807:2297b90a6a7b
user: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
date: Wed Aug 31 15:23:34 2011 +0100
xen: __hvm_pci_intx_assert should check for gsis remapped onto pirqs
If the isa irq corresponding to a particular gsi is disabled while the
gsi is enabled, __hvm_pci_intx_assert will always inject the gsi
through the violapic, even if the gsi has been remapped onto a pirq.
This patch makes sure that even in this case we inject the
notification appropriately.
Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
changeset: 23806:4226ea1785b5
user: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
date: Wed Aug 31 15:23:12 2011 +0100
xen: fix hvm_domain_use_pirq's behavior
hvm_domain_use_pirq should return true when the guest is using a
certain pirq, no matter if the corresponding event channel is
currently enabled or disabled. As an additional complication, qemu is
going to request pirqs for passthrough devices even for Xen unaware
HVM guests, so we need to wait for an event channel to be connected
before considering the pirq of a passthrough device as "in use".
Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
changeset: 23805:7048810180de
user: Andrew Cooper <andrew.cooper3@citrix.com>
date: Wed Aug 31 15:19:24 2011 +0100
IRQ: manually EOI migrating line interrupts
When migrating IO-APIC line level interrupts between PCPUs, the
migration code rewrites the IO-APIC entry to point to the new
CPU/Vector before EOI'ing it.
The EOI process says that EOI'ing the Local APIC will cause a
broadcast with the vector number, which the IO-APIC must listen to to
clear the IRR and Status bits.
In the case of migrating, the IO-APIC has already been
reprogrammed so the EOI broadcast with the old vector fails to match
the new vector, leaving the IO-APIC with an outstanding vector,
preventing any more use of that line interrupt. This causes a lockup
especially when your root device is using PCI INTA (megaraid_sas
driver *ehem*)
However, the problem is mostly hidden because send_cleanup_vector()
causes a cleanup of all moving vectors on the current PCPU in such a
way which does not cause the problem, and if the problem has occured,
the writes it makes to the IO-APIC clears the IRR and Status bits
which unlocks the problem.
This fix is distinctly a temporary hack, waiting on a cleanup of the
irq code. It checks for the edge case where we have moved the irq,
and manually EOI's the old vector with the IO-APIC which correctly
clears the IRR and Status bits. Also, it protects the code which
updates irq_cfg by disabling interrupts.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
changeset: 23804:42d76c68b2bf
user: Kevin Tian <kevin.tian@intel.com>
date: Wed Aug 31 15:18:23 2011 +0100
x86: add irq count for IPIs
such count is useful to assist decision make in cpuidle governor,
while w/o this patch only device interrupts through do_IRQ is
currently counted.
Signed-off-by: Kevin Tian <kevin.tian@intel.com>
changeset: 23803:51983821efa4
user: Dietmar Hahn <dietmar.hahn@ts.fujitsu.com>
date: Wed Aug 31 15:17:45 2011 +0100
vpmu: Add processors Westmere E7-8837 and SandyBridge i5-2500 to the vpmu list
Signed-off-by: Dietmar Hahn <dietmar.hahn@ts.fujitsu.com>
changeset: 23802:bb9b81008733
user: Laszlo Ersek <lersek@redhat.com>
date: Wed Aug 31 15:16:14 2011 +0100
x86: Increase the default NR_CPUS to 256
Changeset 21012:ef845a385014 bumped the default to 128 about one and a
half years ago. Increase it now to 256, as systems with eg. 160
logical CPUs are becoming (have become) common.
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
changeset: 23801:d54cfae72cd1
user: Christoph Egger <Christoph.Egger@amd.com>
date: Wed Aug 31 15:15:41 2011 +0100
nestedsvm: VMRUN doesn't use nextrip
VMRUN does not use nextrip. So remove pointless assignment.
Signed-off-by: Christoph Egger <Christoph.Egger@amd.com>
changeset: 23800:72edc40e2942
user: Keir Fraser <keir@xen.org>
date: Wed Aug 31 15:14:49 2011 +0100
x86-64: Fix off-by-one error in __addr_ok() macro
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Signed-off-by: Keir Fraser <keir@xen.org>
changeset: 23799:ac9aa65050e9
parent: 23798:469aa1fbd843
parent: 23797:2c687e70a343
user: Ian Jackson <Ian.Jackson@eu.citrix.com>
date: Tue Aug 30 11:46:58 2011 +0100
Merge
========================================
commit cd776ee9408ff127f934a707c1a339ee600bc127
Author: Ian Jackson <ian.jackson@eu.citrix.com>
Date: Tue Jun 28 13:50:53 2011 +0100
qemu-char.c: fix incorrect CONFIG_STUBDOM handling
qemu-char.c:1123:7: warning: "CONFIG_STUBDOM" is not defined [-Wundef]
Signed-off-by: Olaf Hering <olaf@aepfle.de>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [xen-unstable test] 8803: regressions - FAIL
2011-09-01 15:59 [xen-unstable test] 8803: regressions - FAIL xen.org
@ 2011-09-01 16:23 ` Ian Jackson
2011-09-01 16:35 ` Ian Campbell
0 siblings, 1 reply; 5+ messages in thread
From: Ian Jackson @ 2011-09-01 16:23 UTC (permalink / raw)
To: xen-devel
~xen.org writes ("[xen-unstable test] 8803: regressions - FAIL"):
> flight 8803 xen-unstable real [real]
> http://www.chiark.greenend.org.uk/~xensrcts/logs/8803/
> build-i386 4 xen-build fail REGR. vs. 8769
gcc -O1 -fno-omit-frame-pointer -m32 -march=i686 -g -fno-strict-aliasing -std=gnu99 -Wall -Wstrict-prototypes -Wno-unused-value -Wdeclaration-after-
statement -fno-builtin -fno-common -Wredundant-decls -iwithprefix include -Werror -Wno-pointer-arith -pipe -I/home/osstest/build.8803.build-i386/xe
n-unstable/xen/include -I/home/osstest/build.8803.build-i386/xen-unstable/xen/include/asm-x86/mach-generic -I/home/osstest/build.8803.build-i386/xe
n-unstable/xen/include/asm-x86/mach-default -msoft-float -fno-stack-protector -fno-exceptions -Wnested-externs -fno-optimize-sibling-calls -nostdinc
-g -D__XEN__ -DVERBOSE -fno-omit-frame-pointer -DCONFIG_FRAME_POINTER -MMD -MF .domain_page.o.d -c domain_page.c -o domain_page.o
domain_page.c: In function 'map_domain_page_global':
domain_page.c:211: error: negative width in bit-field '<anonymous>'
make[5]: *** [domain_page.o] Error 1
make[5]: Leaving directory `/home/osstest/build.8803.build-i386/xen-unstable/xen/arch/x86/x86_32'
make[4]: *** [x86_32/built_in.o] Error 2
Ian.
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Re: [xen-unstable test] 8803: regressions - FAIL
2011-09-01 16:23 ` Ian Jackson
@ 2011-09-01 16:35 ` Ian Campbell
2011-09-01 16:54 ` Ian Jackson
2011-09-01 18:55 ` Laszlo Ersek
0 siblings, 2 replies; 5+ messages in thread
From: Ian Campbell @ 2011-09-01 16:35 UTC (permalink / raw)
To: Ian Jackson; +Cc: xen-devel
On Thu, 2011-09-01 at 17:23 +0100, Ian Jackson wrote:
> ~xen.org writes ("[xen-unstable test] 8803: regressions - FAIL"):
> > flight 8803 xen-unstable real [real]
> > http://www.chiark.greenend.org.uk/~xensrcts/logs/8803/
> > build-i386 4 xen-build fail REGR. vs. 8769
>
> gcc -O1 -fno-omit-frame-pointer -m32 -march=i686 -g -fno-strict-aliasing -std=gnu99 -Wall -Wstrict-prototypes -Wno-unused-value -Wdeclaration-after-
> statement -fno-builtin -fno-common -Wredundant-decls -iwithprefix include -Werror -Wno-pointer-arith -pipe -I/home/osstest/build.8803.build-i386/xe
> n-unstable/xen/include -I/home/osstest/build.8803.build-i386/xen-unstable/xen/include/asm-x86/mach-generic -I/home/osstest/build.8803.build-i386/xe
> n-unstable/xen/include/asm-x86/mach-default -msoft-float -fno-stack-protector -fno-exceptions -Wnested-externs -fno-optimize-sibling-calls -nostdinc
> -g -D__XEN__ -DVERBOSE -fno-omit-frame-pointer -DCONFIG_FRAME_POINTER -MMD -MF .domain_page.o.d -c domain_page.c -o domain_page.o
> domain_page.c: In function 'map_domain_page_global':
> domain_page.c:211: error: negative width in bit-field '<anonymous>'
Which is:
/* At least half the ioremap space should be available to us. */
BUILD_BUG_ON(IOREMAP_VIRT_START + (IOREMAP_MBYTES << 19) >= FIXADDR_START);
Looking at 8769 vs this revision my bet is:
changeset: 23802:bb9b81008733
user: Laszlo Ersek <lersek@redhat.com>
date: Wed Aug 31 15:16:14 2011 +0100
files: xen/include/asm-x86/config.h
description:
x86: Increase the default NR_CPUS to 256
Changeset 21012:ef845a385014 bumped the default to 128 about one and a
half years ago. Increase it now to 256, as systems with eg. 160
logical CPUs are becoming (have become) common.
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
diff -r d54cfae72cd1 -r bb9b81008733 xen/include/asm-x86/config.h
--- a/xen/include/asm-x86/config.h Wed Aug 31 15:15:41 2011 +0100
+++ b/xen/include/asm-x86/config.h Wed Aug 31 15:16:14 2011 +0100
@@ -50,7 +50,7 @@
#ifdef MAX_PHYS_CPUS
#define NR_CPUS MAX_PHYS_CPUS
#else
-#define NR_CPUS 128
+#define NR_CPUS 256
#endif
#ifdef __i386__
I think we need (untested):
# HG changeset patch
# User Ian Campbell <ian.campbell@citrix.com>
# Date 1314894881 -3600
# Node ID 4309ff9535001bdca8db93a439edd86bb4c447cd
# Parent bb97bd46df6c6d8562759a964ebf6c31b6361a7a
xen/x86: only support >128 CPUs on x86_64
32 bit cannot cope with 256 cpus and hits:
/* At least half the ioremap space should be available to us. */
BUILD_BUG_ON(IOREMAP_VIRT_START + (IOREMAP_MBYTES << 19) >= FIXADDR_START);
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
diff -r bb97bd46df6c -r 4309ff953500 xen/include/asm-x86/config.h
--- a/xen/include/asm-x86/config.h Thu Sep 01 16:03:21 2011 +0100
+++ b/xen/include/asm-x86/config.h Thu Sep 01 17:34:41 2011 +0100
@@ -49,6 +49,8 @@
#ifdef MAX_PHYS_CPUS
#define NR_CPUS MAX_PHYS_CPUS
+#elif defined __i386__
+#define NR_CPUS 128
#else
#define NR_CPUS 256
#endif
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Re: [xen-unstable test] 8803: regressions - FAIL
2011-09-01 16:35 ` Ian Campbell
@ 2011-09-01 16:54 ` Ian Jackson
2011-09-01 18:55 ` Laszlo Ersek
1 sibling, 0 replies; 5+ messages in thread
From: Ian Jackson @ 2011-09-01 16:54 UTC (permalink / raw)
To: Ian Campbell; +Cc: xen-devel, Ersek, Laszlo
Ian Campbell writes ("Re: [Xen-devel] Re: [xen-unstable test] 8803: regressions - FAIL"):
> I think we need (untested):
Thanks. This is indeed the cause of the "RHEL6" test failure, which
if I actually read it properly fails at the stage of "install xen",
because Xen didn't build properly.
Ian.
> On Thu, 2011-09-01 at 17:23 +0100, Ian Jackson wrote:
> > ~xen.org writes ("[xen-unstable test] 8803: regressions - FAIL"):
> > > flight 8803 xen-unstable real [real]
> > > http://www.chiark.greenend.org.uk/~xensrcts/logs/8803/
> > > build-i386 4 xen-build fail REGR. vs. 8769
> >
> > gcc -O1 -fno-omit-frame-pointer -m32 -march=i686 -g -fno-strict-aliasing -std=gnu99 -Wall -Wstrict-prototypes -Wno-unused-value -Wdeclaration-after-
> > statement -fno-builtin -fno-common -Wredundant-decls -iwithprefix include -Werror -Wno-pointer-arith -pipe -I/home/osstest/build.8803.build-i386/xe
> > n-unstable/xen/include -I/home/osstest/build.8803.build-i386/xen-unstable/xen/include/asm-x86/mach-generic -I/home/osstest/build.8803.build-i386/xe
> > n-unstable/xen/include/asm-x86/mach-default -msoft-float -fno-stack-protector -fno-exceptions -Wnested-externs -fno-optimize-sibling-calls -nostdinc
> > -g -D__XEN__ -DVERBOSE -fno-omit-frame-pointer -DCONFIG_FRAME_POINTER -MMD -MF .domain_page.o.d -c domain_page.c -o domain_page.o
> > domain_page.c: In function 'map_domain_page_global':
> > domain_page.c:211: error: negative width in bit-field '<anonymous>'
>
> Which is:
> /* At least half the ioremap space should be available to us. */
> BUILD_BUG_ON(IOREMAP_VIRT_START + (IOREMAP_MBYTES << 19) >= FIXADDR_START);
>
> Looking at 8769 vs this revision my bet is:
>
> changeset: 23802:bb9b81008733
> user: Laszlo Ersek <lersek@redhat.com>
> date: Wed Aug 31 15:16:14 2011 +0100
> files: xen/include/asm-x86/config.h
> description:
> x86: Increase the default NR_CPUS to 256
>
> Changeset 21012:ef845a385014 bumped the default to 128 about one and a
> half years ago. Increase it now to 256, as systems with eg. 160
> logical CPUs are becoming (have become) common.
>
> Signed-off-by: Laszlo Ersek <lersek@redhat.com>
>
>
> diff -r d54cfae72cd1 -r bb9b81008733 xen/include/asm-x86/config.h
> --- a/xen/include/asm-x86/config.h Wed Aug 31 15:15:41 2011 +0100
> +++ b/xen/include/asm-x86/config.h Wed Aug 31 15:16:14 2011 +0100
> @@ -50,7 +50,7 @@
> #ifdef MAX_PHYS_CPUS
> #define NR_CPUS MAX_PHYS_CPUS
> #else
> -#define NR_CPUS 128
> +#define NR_CPUS 256
> #endif
>
> #ifdef __i386__
>
> I think we need (untested):
>
> # HG changeset patch
> # User Ian Campbell <ian.campbell@citrix.com>
> # Date 1314894881 -3600
> # Node ID 4309ff9535001bdca8db93a439edd86bb4c447cd
> # Parent bb97bd46df6c6d8562759a964ebf6c31b6361a7a
> xen/x86: only support >128 CPUs on x86_64
>
> 32 bit cannot cope with 256 cpus and hits:
>
> /* At least half the ioremap space should be available to us. */
> BUILD_BUG_ON(IOREMAP_VIRT_START + (IOREMAP_MBYTES << 19) >= FIXADDR_START);
>
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
>
> diff -r bb97bd46df6c -r 4309ff953500 xen/include/asm-x86/config.h
> --- a/xen/include/asm-x86/config.h Thu Sep 01 16:03:21 2011 +0100
> +++ b/xen/include/asm-x86/config.h Thu Sep 01 17:34:41 2011 +0100
> @@ -49,6 +49,8 @@
>
> #ifdef MAX_PHYS_CPUS
> #define NR_CPUS MAX_PHYS_CPUS
> +#elif defined __i386__
> +#define NR_CPUS 128
> #else
> #define NR_CPUS 256
> #endif
>
>
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Re: [xen-unstable test] 8803: regressions - FAIL
2011-09-01 16:35 ` Ian Campbell
2011-09-01 16:54 ` Ian Jackson
@ 2011-09-01 18:55 ` Laszlo Ersek
1 sibling, 0 replies; 5+ messages in thread
From: Laszlo Ersek @ 2011-09-01 18:55 UTC (permalink / raw)
To: Ian Campbell; +Cc: xen-devel, Ian Jackson
On 09/01/11 18:35, Ian Campbell wrote:
> diff -r bb97bd46df6c -r 4309ff953500 xen/include/asm-x86/config.h
> --- a/xen/include/asm-x86/config.h Thu Sep 01 16:03:21 2011 +0100
> +++ b/xen/include/asm-x86/config.h Thu Sep 01 17:34:41 2011 +0100
> @@ -49,6 +49,8 @@
>
> #ifdef MAX_PHYS_CPUS
> #define NR_CPUS MAX_PHYS_CPUS
> +#elif defined __i386__
> +#define NR_CPUS 128
> #else
> #define NR_CPUS 256
> #endif
Ah, sorry. This special-casing / after-the-fact #error for 32-bit is
actually there in the RHEL-5 fork, and there I bumped only the x86_64
default (the 32-bit one is set to 32). When I looked at the upstream
source, I noticed only a single case (set to 128), and I figured
upstream either makes the 32/64 distinction by different means, or they
support 128 PCPUs on 32-bit too, and 128 being >> than 32, I thought 256
should be fine as well.
I was wrong, sorry for wasting your time.
lacos
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2011-09-01 18:55 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2011-09-01 15:59 [xen-unstable test] 8803: regressions - FAIL xen.org
2011-09-01 16:23 ` Ian Jackson
2011-09-01 16:35 ` Ian Campbell
2011-09-01 16:54 ` Ian Jackson
2011-09-01 18:55 ` Laszlo Ersek
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.