flight 16231 xen-unstable real [real] http://www.chiark.greenend.org.uk/~xensrcts/logs/16231/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-i386 4 xen-build fail REGR. vs. 16226 build-i386-oldkern 4 xen-build fail REGR. vs. 16226 Regressions which are regarded as allowable (not blocking): test-amd64-amd64-xl-sedf 5 xen-boot fail like 16226 test-amd64-amd64-xl-sedf-pin 7 debian-install fail blocked in 16226 test-amd64-amd64-xl-qemut-win 7 windows-install fail like 16226 Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-pcipt-intel 9 guest-start fail never pass test-amd64-i386-rhel6hvm-intel 1 xen-build-check(1) blocked n/a test-amd64-i386-xl-multivcpu 1 xen-build-check(1) blocked n/a test-amd64-i386-pv 1 xen-build-check(1) blocked n/a test-amd64-i386-xl-credit2 1 xen-build-check(1) blocked n/a test-amd64-i386-xl 1 xen-build-check(1) blocked n/a test-amd64-i386-qemut-rhel6hvm-amd 1 xen-build-check(1) blocked n/a test-amd64-i386-qemuu-rhel6hvm-amd 1 xen-build-check(1) blocked n/a test-amd64-i386-rhel6hvm-amd 1 xen-build-check(1) blocked n/a test-amd64-amd64-xl-win7-amd64 13 guest-stop fail never pass test-amd64-amd64-xl-qemuu-win7-amd64 13 guest-stop fail never pass test-amd64-i386-win 1 xen-build-check(1) blocked n/a test-amd64-i386-xend-winxpsp3 1 xen-build-check(1) blocked n/a test-amd64-amd64-xl-qemuu-winxpsp3 13 guest-stop fail never pass test-amd64-i386-qemuu-rhel6hvm-intel 1 xen-build-check(1) blocked n/a test-amd64-i386-qemut-rhel6hvm-intel 1 xen-build-check(1) blocked n/a test-amd64-i386-xl-win7-amd64 1 xen-build-check(1) blocked n/a test-amd64-i386-xl-qemut-win7-amd64 1 xen-build-check(1) blocked n/a test-amd64-i386-xl-win-vcpus1 1 xen-build-check(1) blocked n/a test-amd64-amd64-xl-qemut-winxpsp3 13 guest-stop fail never pass test-amd64-amd64-xl-winxpsp3 13 guest-stop fail never pass test-amd64-i386-xl-qemut-win-vcpus1 1 xen-build-check(1) blocked n/a test-amd64-i386-xend-qemut-winxpsp3 1 xen-build-check(1) blocked n/a test-amd64-i386-xl-qemut-winxpsp3-vcpus1 1 xen-build-check(1) blocked n/a test-amd64-i386-xl-winxpsp3-vcpus1 1 xen-build-check(1) blocked n/a test-amd64-i386-pair 1 xen-build-check(1) blocked n/a test-amd64-amd64-xl-qemut-win7-amd64 13 guest-stop fail never pass test-amd64-amd64-win 16 leak-check/check fail never pass test-amd64-i386-qemut-win-vcpus1 1 xen-build-check(1) blocked n/a test-amd64-i386-qemut-win 1 xen-build-check(1) blocked n/a test-amd64-i386-win-vcpus1 1 xen-build-check(1) blocked n/a test-amd64-amd64-qemut-win 16 leak-check/check fail never pass test-amd64-amd64-xl-win 13 guest-stop fail never pass version targeted for testing: xen 4291b626cee8aff5d976c5829a79fceca9cff420 baseline version: xen fb034f42648ecac835a1666def468f673edd2725 ------------------------------------------------------------ People who touched revisions under test: ------------------------------------------------------------ jobs: build-amd64 pass build-armhf 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 blocked test-amd64-i386-rhel6hvm-amd blocked test-amd64-i386-qemut-rhel6hvm-amd blocked test-amd64-i386-qemuu-rhel6hvm-amd blocked test-amd64-amd64-xl-qemut-win7-amd64 fail test-amd64-i386-xl-qemut-win7-amd64 blocked test-amd64-amd64-xl-qemuu-win7-amd64 fail test-amd64-amd64-xl-win7-amd64 fail test-amd64-i386-xl-win7-amd64 blocked test-amd64-i386-xl-credit2 blocked test-amd64-amd64-xl-pcipt-intel fail test-amd64-i386-rhel6hvm-intel blocked test-amd64-i386-qemut-rhel6hvm-intel blocked test-amd64-i386-qemuu-rhel6hvm-intel blocked test-amd64-i386-xl-multivcpu blocked test-amd64-amd64-pair pass test-amd64-i386-pair blocked test-amd64-amd64-xl-sedf-pin fail test-amd64-amd64-pv pass test-amd64-i386-pv blocked test-amd64-amd64-xl-sedf fail test-amd64-i386-win-vcpus1 blocked test-amd64-i386-qemut-win-vcpus1 blocked test-amd64-i386-xl-qemut-win-vcpus1 blocked test-amd64-i386-xl-win-vcpus1 blocked test-amd64-i386-xl-qemut-winxpsp3-vcpus1 blocked test-amd64-i386-xl-winxpsp3-vcpus1 blocked test-amd64-amd64-win fail test-amd64-i386-win blocked test-amd64-amd64-qemut-win fail test-amd64-i386-qemut-win blocked test-amd64-amd64-xl-qemut-win fail test-amd64-amd64-xl-win fail test-amd64-i386-xend-qemut-winxpsp3 blocked test-amd64-amd64-xl-qemut-winxpsp3 fail test-amd64-amd64-xl-qemuu-winxpsp3 fail test-amd64-i386-xend-winxpsp3 blocked test-amd64-amd64-xl-winxpsp3 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. ------------------------------------------------------------ commit 4291b626cee8aff5d976c5829a79fceca9cff420 Author: Ian Jackson <ian.jackson@eu.citrix.com> Date: Fri Feb 22 18:16:54 2013 +0000 QEMU_TAG update (qemu changes not included)
xen.org writes ("[xen-unstable test] 16231: regressions - FAIL"):> flight 16231 xen-unstable real [real] > http://www.chiark.greenend.org.uk/~xensrcts/logs/16231/ > > Regressions :-( > > Tests which did not succeed and are blocking, > including tests which could not be run: > build-i386 4 xen-build fail REGR. vs. 16226gcc -Wall -Werror -Wstrict-prototypes -O2 -fomit-frame-pointer -fno-strict-aliasing -Wdeclaration-after-statement -o checker checker.c ./checker > tmp.size diff -u reference.size tmp.size --- reference.size 2013-02-22 22:53:31.000000000 +0000 +++ tmp.size 2013-02-22 23:12:05.000000000 +0000 @@ -5,7 +5,7 @@ trap_info | - - 8 16 cpu_user_regs | - - 68 200 vcpu_guest_core_regs | 304 304 - - -vcpu_guest_context | 336 336 2800 5168 +vcpu_guest_context | 332 332 2800 5168 arch_vcpu_info | - - 24 16 vcpu_time_info | - - 32 32 vcpu_info | - - 64 64 make[4]: *** [check-headers] Error 1 make[4]: Leaving directory `/home/osstest/build.16231.build-i386/xen-unstable/tools/include/xen-foreign'' make[3]: Leaving directory `/home/osstest/build.16231.build-i386/xen-unstable/tools/include'' make[3]: *** [xen-foreign] Error 2 Are we supposed to still be doing this for i386 ? Ian.
On 23/02/2013 16:09, "Ian Jackson" <Ian.Jackson@eu.citrix.com> wrote:> xen.org writes ("[xen-unstable test] 16231: regressions - FAIL"): >> flight 16231 xen-unstable real [real] >> http://www.chiark.greenend.org.uk/~xensrcts/logs/16231/ >> >> Regressions :-( >> >> Tests which did not succeed and are blocking, >> including tests which could not be run: >> build-i386 4 xen-build fail REGR. vs. 16226 > > gcc -Wall -Werror -Wstrict-prototypes -O2 -fomit-frame-pointer > -fno-strict-aliasing -Wdeclaration-after-statement -o checker checker.c > ./checker > tmp.size > diff -u reference.size tmp.size > --- reference.size 2013-02-22 22:53:31.000000000 +0000 > +++ tmp.size 2013-02-22 23:12:05.000000000 +0000 > @@ -5,7 +5,7 @@ > trap_info | - - 8 16 > cpu_user_regs | - - 68 200 > vcpu_guest_core_regs | 304 304 - - > -vcpu_guest_context | 336 336 2800 5168 > +vcpu_guest_context | 332 332 2800 5168 > arch_vcpu_info | - - 24 16 > vcpu_time_info | - - 32 32 > vcpu_info | - - 64 64 > make[4]: *** [check-headers] Error 1 > make[4]: Leaving directory > `/home/osstest/build.16231.build-i386/xen-unstable/tools/include/xen-foreign'' > make[3]: Leaving directory > `/home/osstest/build.16231.build-i386/xen-unstable/tools/include'' > make[3]: *** [xen-foreign] Error 2 > > Are we supposed to still be doing this for i386 ?Yes we are, as we still support our i386 guest ABI. However, the problem in this case appears to be that the ARM structure size has changed. If so, that needs to be fixed, or reference.size needs to be updated. -- Keir> Ian. > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xen.org > http://lists.xen.org/xen-devel
On Sat, 2013-02-23 at 16:26 +0000, Keir Fraser wrote:> On 23/02/2013 16:09, "Ian Jackson" <Ian.Jackson@eu.citrix.com> wrote: > > > xen.org writes ("[xen-unstable test] 16231: regressions - FAIL"): > >> flight 16231 xen-unstable real [real] > >> http://www.chiark.greenend.org.uk/~xensrcts/logs/16231/ > >> > >> Regressions :-( > >> > >> Tests which did not succeed and are blocking, > >> including tests which could not be run: > >> build-i386 4 xen-build fail REGR. vs. 16226 > > > > gcc -Wall -Werror -Wstrict-prototypes -O2 -fomit-frame-pointer > > -fno-strict-aliasing -Wdeclaration-after-statement -o checker checker.c > > ./checker > tmp.size > > diff -u reference.size tmp.size > > --- reference.size 2013-02-22 22:53:31.000000000 +0000 > > +++ tmp.size 2013-02-22 23:12:05.000000000 +0000 > > @@ -5,7 +5,7 @@ > > trap_info | - - 8 16 > > cpu_user_regs | - - 68 200 > > vcpu_guest_core_regs | 304 304 - - > > -vcpu_guest_context | 336 336 2800 5168 > > +vcpu_guest_context | 332 332 2800 5168 > > arch_vcpu_info | - - 24 16 > > vcpu_time_info | - - 32 32 > > vcpu_info | - - 64 64 > > make[4]: *** [check-headers] Error 1 > > make[4]: Leaving directory > > `/home/osstest/build.16231.build-i386/xen-unstable/tools/include/xen-foreign'' > > make[3]: Leaving directory > > `/home/osstest/build.16231.build-i386/xen-unstable/tools/include'' > > make[3]: *** [xen-foreign] Error 2 > > > > Are we supposed to still be doing this for i386 ? > > Yes we are, as we still support our i386 guest ABI. > > However, the problem in this case appears to be that the ARM structure size > has changed. If so, that needs to be fixed, or reference.size needs to be > updated.The problem is the use of ''#pragma pack(4)'' when building the foreign headers on x86_32. I think it is useful to keep checking all arches on every build, rather than splitting into x86 and arm checks, since that will help catch inadvertent cross-arch breakage. 8<------------------- From a20962085ef8d4c3d55f830647cdcb496bc5ee4a Mon Sep 17 00:00:00 2001 From: Ian Campbell <ian.campbell@citrix.com> Date: Mon, 25 Feb 2013 09:11:04 +0000 Subject: [PATCH] tools: foreign: ensure 64 bit values are properly aligned for arm When building the foreign headers on x86_32 we use ''#pragma pack(4)'' and therefore need to explicitly align types which should be aligned to 8-byte boundaries. Signed-off-by: Ian Campbell <ian.campbell@citrix.com> --- tools/include/xen-foreign/mkheader.py | 14 ++++++++++---- 1 files changed, 10 insertions(+), 4 deletions(-) diff --git a/tools/include/xen-foreign/mkheader.py b/tools/include/xen-foreign/mkheader.py index 8a784d3..5bd6eec 100644 --- a/tools/include/xen-foreign/mkheader.py +++ b/tools/include/xen-foreign/mkheader.py @@ -20,15 +20,18 @@ footer = {}; inttypes["arm32"] = { "unsigned long" : "uint32_t", "long" : "uint32_t", - "xen_pfn_t" : "uint64_t", - "xen_ulong_t" : "uint64_t", + "xen_pfn_t" : "__align8__ uint64_t", + "xen_ulong_t" : "__align8__ uint64_t", + "uint64_t" : "__align8__ uint64_t", }; header["arm32"] = """ #define __arm___ARM32 1 #if defined(__GNUC__) && !defined(__STRICT_ANSI__) # define __DECL_REG(n64, n32) union { uint64_t n64; uint32_t n32; } +# define __align8__ __attribute__((aligned (8))) #else # define __DECL_REG(n64, n32) uint64_t n64 +# define FIXME #endif """; footer["arm32"] = """ @@ -38,15 +41,18 @@ footer["arm32"] = """ inttypes["arm64"] = { "unsigned long" : "__danger_unsigned_long_on_arm64", "long" : "__danger_long_on_arm64", - "xen_pfn_t" : "uint64_t", - "xen_ulong_t" : "uint64_t", + "xen_pfn_t" : "__align8__ uint64_t", + "xen_ulong_t" : "__align8__ uint64_t", + "uint64_t" : "__align8__ uint64_t", }; header["arm64"] = """ #define __aarch64___ARM64 1 #if defined(__GNUC__) && !defined(__STRICT_ANSI__) # define __DECL_REG(n64, n32) union { uint64_t n64; uint32_t n32; } +# define __align8__ __attribute__((aligned (8))) #else # define __DECL_REG(n64, n32) uint64_t n64 +# define FIXME #endif """; footer["arm64"] = """ -- 1.7.2.5
On Mon, 2013-02-25 at 09:19 +0000, Ian Campbell wrote:> The problem is the use of ''#pragma pack(4)'' when building the foreign > headers on x86_32.IIRC this is to deal with the fact that on x86_32 8-byte types are 4-byte aligned when they are within a struct. This is not the case on 32-bit ARM. The following skanky test on armv7 returns: align of uint32_t 4 align of uint64_t 8 align of struct foo.t32 4 align of struct foo.t64 8 Compared with x86_32: align of uint32_t 4 align of uint64_t 8 align of struct foo.t32 4 align of struct foo.t64 4 Ian #include <stdio.h> #include <stdint.h> #include <inttypes.h> struct foo { uint32_t t32; uint64_t t64; }; int main (void) { struct foo f; printf("align of uint32_t %d\n", __alignof__(uint32_t)); printf("align of uint64_t %d\n", __alignof__(uint64_t)); printf("align of struct foo.t32 %d\n", __alignof__(f.t32)); printf("align of struct foo.t64 %d\n", __alignof__(f.t64)); return 0; }
This patch fixes the current build breakage, anyone want to ack or nack? I''m about to cycle into the office, hopefully I can apply when I arrive. Ian.> > However, the problem in this case appears to be that the ARM structure size > > has changed. If so, that needs to be fixed, or reference.size needs to be > > updated. > > The problem is the use of ''#pragma pack(4)'' when building the foreign > headers on x86_32. > > I think it is useful to keep checking all arches on every build, rather > than splitting into x86 and arm checks, since that will help catch > inadvertent cross-arch breakage. > > 8<------------------- > > > From a20962085ef8d4c3d55f830647cdcb496bc5ee4a Mon Sep 17 00:00:00 2001 > From: Ian Campbell <ian.campbell@citrix.com> > Date: Mon, 25 Feb 2013 09:11:04 +0000 > Subject: [PATCH] tools: foreign: ensure 64 bit values are properly aligned for arm > > When building the foreign headers on x86_32 we use ''#pragma pack(4)'' and > therefore need to explicitly align types which should be aligned to 8-byte > boundaries. > > Signed-off-by: Ian Campbell <ian.campbell@citrix.com> > --- > tools/include/xen-foreign/mkheader.py | 14 ++++++++++---- > 1 files changed, 10 insertions(+), 4 deletions(-) > > diff --git a/tools/include/xen-foreign/mkheader.py b/tools/include/xen-foreign/mkheader.py > index 8a784d3..5bd6eec 100644 > --- a/tools/include/xen-foreign/mkheader.py > +++ b/tools/include/xen-foreign/mkheader.py > @@ -20,15 +20,18 @@ footer = {}; > inttypes["arm32"] = { > "unsigned long" : "uint32_t", > "long" : "uint32_t", > - "xen_pfn_t" : "uint64_t", > - "xen_ulong_t" : "uint64_t", > + "xen_pfn_t" : "__align8__ uint64_t", > + "xen_ulong_t" : "__align8__ uint64_t", > + "uint64_t" : "__align8__ uint64_t", > }; > header["arm32"] = """ > #define __arm___ARM32 1 > #if defined(__GNUC__) && !defined(__STRICT_ANSI__) > # define __DECL_REG(n64, n32) union { uint64_t n64; uint32_t n32; } > +# define __align8__ __attribute__((aligned (8))) > #else > # define __DECL_REG(n64, n32) uint64_t n64 > +# define FIXME > #endif > """; > footer["arm32"] = """ > @@ -38,15 +41,18 @@ footer["arm32"] = """ > inttypes["arm64"] = { > "unsigned long" : "__danger_unsigned_long_on_arm64", > "long" : "__danger_long_on_arm64", > - "xen_pfn_t" : "uint64_t", > - "xen_ulong_t" : "uint64_t", > + "xen_pfn_t" : "__align8__ uint64_t", > + "xen_ulong_t" : "__align8__ uint64_t", > + "uint64_t" : "__align8__ uint64_t", > }; > header["arm64"] = """ > #define __aarch64___ARM64 1 > #if defined(__GNUC__) && !defined(__STRICT_ANSI__) > # define __DECL_REG(n64, n32) union { uint64_t n64; uint32_t n32; } > +# define __align8__ __attribute__((aligned (8))) > #else > # define __DECL_REG(n64, n32) uint64_t n64 > +# define FIXME > #endif > """; > footer["arm64"] = """
>>> On 26.02.13 at 10:06, Ian Campbell <Ian.Campbell@citrix.com> wrote: > This patch fixes the current build breakage, anyone want to ack or nack?Looks almost fine to me, but probably one of the other ARM guys would want to ack this anyway.>> --- a/tools/include/xen-foreign/mkheader.py >> +++ b/tools/include/xen-foreign/mkheader.py >> @@ -20,15 +20,18 @@ footer = {}; >> inttypes["arm32"] = { >> "unsigned long" : "uint32_t", >> "long" : "uint32_t", >> - "xen_pfn_t" : "uint64_t", >> - "xen_ulong_t" : "uint64_t", >> + "xen_pfn_t" : "__align8__ uint64_t", >> + "xen_ulong_t" : "__align8__ uint64_t", >> + "uint64_t" : "__align8__ uint64_t", >> }; >> header["arm32"] = """ >> #define __arm___ARM32 1 >> #if defined(__GNUC__) && !defined(__STRICT_ANSI__) >> # define __DECL_REG(n64, n32) union { uint64_t n64; uint32_t n32; } >> +# define __align8__ __attribute__((aligned (8)))Using __aligned__ here would probably be a tiny bit more safe (I do realize that x86-64 already uses the same construct you use).>> #else >> # define __DECL_REG(n64, n32) uint64_t n64 >> +# define FIXMEDid you mean # define __align8__ FIXME (also further down)? Jan
On Tue, 2013-02-26 at 09:54 +0000, Jan Beulich wrote:> >>> On 26.02.13 at 10:06, Ian Campbell <Ian.Campbell@citrix.com> wrote: > > This patch fixes the current build breakage, anyone want to ack or nack? > > Looks almost fine to me, but probably one of the other ARM guys > would want to ack this anyway.Actually at this point I would rather just get the build fixed, since it is blocking quite a large staging push. I''ll commit in about half an hour unless someone objects.> >> --- a/tools/include/xen-foreign/mkheader.py > >> +++ b/tools/include/xen-foreign/mkheader.py > >> @@ -20,15 +20,18 @@ footer = {}; > >> inttypes["arm32"] = { > >> "unsigned long" : "uint32_t", > >> "long" : "uint32_t", > >> - "xen_pfn_t" : "uint64_t", > >> - "xen_ulong_t" : "uint64_t", > >> + "xen_pfn_t" : "__align8__ uint64_t", > >> + "xen_ulong_t" : "__align8__ uint64_t", > >> + "uint64_t" : "__align8__ uint64_t", > >> }; > >> header["arm32"] = """ > >> #define __arm___ARM32 1 > >> #if defined(__GNUC__) && !defined(__STRICT_ANSI__) > >> # define __DECL_REG(n64, n32) union { uint64_t n64; uint32_t n32; } > >> +# define __align8__ __attribute__((aligned (8))) > > Using __aligned__ here would probably be a tiny bit more safe (I > do realize that x86-64 already uses the same construct you use).Yes I copied x86-64 here deliberately.> >> #else > >> # define __DECL_REG(n64, n32) uint64_t n64 > >> +# define FIXME > > Did you mean > > # define __align8__ FIXME > > (also further down)?Oh yes, silly me. Ian. 8<-------------------------------- From 8a2ab328c96bd71855595633b14fb7adc5cc0cc9 Mon Sep 17 00:00:00 2001 From: Ian Campbell <ian.campbell@citrix.com> Date: Mon, 25 Feb 2013 09:11:04 +0000 Subject: [PATCH] tools: foreign: ensure 64 bit values are properly aligned for arm When building the foreign headers on x86_32 we use ''#pragma pack(4)'' and therefore need to explicitly align types which should be aligned to 8-byte boundaries. Signed-off-by: Ian Campbell <ian.campbell@citrix.com> --- v2: Fix #define FIXME -> #define __align8__ FIXME --- tools/include/xen-foreign/mkheader.py | 14 ++++++++++---- 1 files changed, 10 insertions(+), 4 deletions(-) diff --git a/tools/include/xen-foreign/mkheader.py b/tools/include/xen-foreign/mkheader.py index 8a784d3..b19292f 100644 --- a/tools/include/xen-foreign/mkheader.py +++ b/tools/include/xen-foreign/mkheader.py @@ -20,15 +20,18 @@ footer = {}; inttypes["arm32"] = { "unsigned long" : "uint32_t", "long" : "uint32_t", - "xen_pfn_t" : "uint64_t", - "xen_ulong_t" : "uint64_t", + "xen_pfn_t" : "__align8__ uint64_t", + "xen_ulong_t" : "__align8__ uint64_t", + "uint64_t" : "__align8__ uint64_t", }; header["arm32"] = """ #define __arm___ARM32 1 #if defined(__GNUC__) && !defined(__STRICT_ANSI__) # define __DECL_REG(n64, n32) union { uint64_t n64; uint32_t n32; } +# define __align8__ __attribute__((aligned (8))) #else # define __DECL_REG(n64, n32) uint64_t n64 +# define __align8__ FIXME #endif """; footer["arm32"] = """ @@ -38,15 +41,18 @@ footer["arm32"] = """ inttypes["arm64"] = { "unsigned long" : "__danger_unsigned_long_on_arm64", "long" : "__danger_long_on_arm64", - "xen_pfn_t" : "uint64_t", - "xen_ulong_t" : "uint64_t", + "xen_pfn_t" : "__align8__ uint64_t", + "xen_ulong_t" : "__align8__ uint64_t", + "uint64_t" : "__align8__ uint64_t", }; header["arm64"] = """ #define __aarch64___ARM64 1 #if defined(__GNUC__) && !defined(__STRICT_ANSI__) # define __DECL_REG(n64, n32) union { uint64_t n64; uint32_t n32; } +# define __align8__ __attribute__((aligned (8))) #else # define __DECL_REG(n64, n32) uint64_t n64 +# define __align8__ FIXME #endif """; footer["arm64"] = """ -- 1.7.2.5
Ian Campbell writes ("Re: [Xen-devel] [xen-unstable test] 16231: regressions - FAIL"):> I''ll commit in about half an hour unless someone objects.I''ve done this. Ian.
On Tue, 2013-02-26 at 12:22 +0000, Ian Jackson wrote:> Ian Campbell writes ("Re: [Xen-devel] [xen-unstable test] 16231: regressions - FAIL"): > > I''ll commit in about half an hour unless someone objects. > > I''ve done this.Thanks I got tied up in a meeting. Ian.