* [xen-unstable test] 59040: regressions - FAIL
@ 2015-07-03 21:59 osstest service owner
2015-07-06 12:33 ` Ian Campbell
0 siblings, 1 reply; 8+ messages in thread
From: osstest service owner @ 2015-07-03 21:59 UTC (permalink / raw)
To: xen-devel; +Cc: ian.jackson
flight 59040 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/59040/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 14 guest-localmigrate.2 fail REGR. vs. 58958
test-armhf-armhf-xl-credit2 15 guest-start/debian.repeat fail REGR. vs. 58965
test-amd64-amd64-xl-qemuu-debianhvm-amd64 17 guest-start.2 fail REGR. vs. 58965
test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 9 debian-hvm-install fail REGR. vs. 58965
Regressions which are regarded as allowable (not blocking):
test-amd64-i386-rumpuserxen-i386 15 rumpuserxen-demo-xenstorels/xenstorels.repeat fail like 58948
test-amd64-i386-libvirt-xsm 11 guest-start fail like 58965
test-amd64-i386-libvirt 11 guest-start fail like 58965
test-amd64-amd64-libvirt 11 guest-start fail like 58965
test-amd64-amd64-libvirt-xsm 11 guest-start fail like 58965
test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stop fail like 58965
test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail like 58965
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-pvh-intel 11 guest-start fail never pass
test-amd64-amd64-xl-pvh-amd 11 guest-start fail never pass
test-armhf-armhf-xl-rtds 14 guest-start.2 fail never pass
test-armhf-armhf-xl-rtds 12 migrate-support-check fail never pass
test-armhf-armhf-xl-arndale 12 migrate-support-check fail never pass
test-armhf-armhf-xl-credit2 12 migrate-support-check fail never pass
test-armhf-armhf-libvirt 12 migrate-support-check fail never pass
test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop fail never pass
test-armhf-armhf-libvirt-xsm 12 migrate-support-check fail never pass
test-armhf-armhf-xl-cubietruck 12 migrate-support-check fail never pass
test-armhf-armhf-xl 12 migrate-support-check fail never pass
test-armhf-armhf-xl-multivcpu 12 migrate-support-check fail never pass
test-armhf-armhf-xl-xsm 12 migrate-support-check fail never pass
test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail never pass
version targeted for testing:
xen 1123da20d30b696269484aa037e2ee5d5d7d9e06
baseline version:
xen c40317f11b3f05e7c06a2213560c8471081f2662
Last test of basis 58965 2015-06-29 02:08:30 Z 4 days
Failing since 58974 2015-06-29 15:11:59 Z 4 days 6 attempts
Testing same since 59040 2015-07-03 06:15:34 Z 0 days 1 attempts
------------------------------------------------------------
People who touched revisions under test:
Andrew Cooper <andrew.cooper3@citrix.com>
Ard Biesheuvel <ard@linaro.org>
Dario Faggioli <dario.faggioli@citrix.com>
Euan Harris <euan.harris@citrix.com>
George Dunlap <george.dunlap@eu.citrix.com>
Ian Campbell <ian.campbell@citrix.com>
Ian Jackson <Ian.Jackson@eu.citrix.com>
Jan Beulich <jbeulich@suse.com>
Julien Grall <julien.grall@citrix.com>
Liang Li <liang.z.li@intel.com>
Tiejun Chen <tiejun.chen@intel.com>
Wei Liu <wei.liu2@citrix.com>
Wen Congyang <wency@cn.fujitsu.com>
Yang Zhang <yang.z.zhang@intel.com>
jobs:
build-amd64-xsm pass
build-armhf-xsm pass
build-i386-xsm pass
build-amd64 pass
build-armhf pass
build-i386 pass
build-amd64-libvirt pass
build-armhf-libvirt pass
build-i386-libvirt pass
build-amd64-oldkern pass
build-i386-oldkern pass
build-amd64-pvops pass
build-armhf-pvops pass
build-i386-pvops pass
build-amd64-rumpuserxen pass
build-i386-rumpuserxen pass
test-amd64-amd64-xl pass
test-armhf-armhf-xl pass
test-amd64-i386-xl pass
test-amd64-amd64-xl-qemut-debianhvm-amd64-xsm pass
test-amd64-i386-xl-qemut-debianhvm-amd64-xsm pass
test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsm pass
test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm pass
test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm fail
test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm fail
test-amd64-amd64-libvirt-xsm fail
test-armhf-armhf-libvirt-xsm pass
test-amd64-i386-libvirt-xsm fail
test-amd64-amd64-xl-xsm pass
test-armhf-armhf-xl-xsm pass
test-amd64-i386-xl-xsm pass
test-amd64-amd64-xl-pvh-amd fail
test-amd64-i386-qemut-rhel6hvm-amd pass
test-amd64-i386-qemuu-rhel6hvm-amd pass
test-amd64-amd64-xl-qemut-debianhvm-amd64 pass
test-amd64-i386-xl-qemut-debianhvm-amd64 pass
test-amd64-amd64-xl-qemuu-debianhvm-amd64 fail
test-amd64-i386-xl-qemuu-debianhvm-amd64 pass
test-amd64-i386-freebsd10-amd64 pass
test-amd64-amd64-xl-qemuu-ovmf-amd64 pass
test-amd64-i386-xl-qemuu-ovmf-amd64 pass
test-amd64-amd64-rumpuserxen-amd64 pass
test-amd64-amd64-xl-qemut-win7-amd64 fail
test-amd64-i386-xl-qemut-win7-amd64 fail
test-amd64-amd64-xl-qemuu-win7-amd64 fail
test-amd64-i386-xl-qemuu-win7-amd64 fail
test-armhf-armhf-xl-arndale pass
test-amd64-amd64-xl-credit2 pass
test-armhf-armhf-xl-credit2 fail
test-armhf-armhf-xl-cubietruck pass
test-amd64-i386-freebsd10-i386 pass
test-amd64-i386-rumpuserxen-i386 fail
test-amd64-amd64-xl-pvh-intel fail
test-amd64-i386-qemut-rhel6hvm-intel pass
test-amd64-i386-qemuu-rhel6hvm-intel pass
test-amd64-amd64-libvirt fail
test-armhf-armhf-libvirt pass
test-amd64-i386-libvirt fail
test-amd64-amd64-xl-multivcpu pass
test-armhf-armhf-xl-multivcpu pass
test-amd64-amd64-pair pass
test-amd64-i386-pair pass
test-amd64-amd64-xl-rtds pass
test-armhf-armhf-xl-rtds fail
test-amd64-i386-xl-qemut-winxpsp3-vcpus1 pass
test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 pass
test-amd64-amd64-xl-qemut-winxpsp3 pass
test-amd64-i386-xl-qemut-winxpsp3 pass
test-amd64-amd64-xl-qemuu-winxpsp3 pass
test-amd64-i386-xl-qemuu-winxpsp3 pass
------------------------------------------------------------
sg-report-flight on osstest.test-lab.xenproject.org
logs: /home/logs/logs
images: /home/logs/images
Logs, config files, etc. are available at
http://logs.test-lab.xenproject.org/osstest/logs
Explanation of these reports, and of osstest in general, is at
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master
Test harness code can be found at
http://xenbits.xen.org/gitweb?p=osstest.git;a=summary
Not pushing.
------------------------------------------------------------
commit 1123da20d30b696269484aa037e2ee5d5d7d9e06
Author: Euan Harris <euan.harris@citrix.com>
Date: Thu Jul 2 11:30:05 2015 +0100
libxl: doc: Fix nonexistent error code in libxl_event_check example
Fix example code in comment. libxl_event_check() can return
ERROR_NOT_READY; LIBXL_NOT_READY does not exist.
Signed-off-by: Euan Harris <euan.harris@citrix.com>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
commit 3d55a179fac1f4463142386122eff7d254e1788d
Author: Ian Jackson <ian.jackson@eu.citrix.com>
Date: Wed Jul 1 15:20:03 2015 +0100
libxl: Do not try to destroy domain -1 on failed create
Perhaps since f0c4c53f "libxl: domain create: Do not destroy on ao
abort", we have destroyed guest_domid==-1 if domain creation fails
without actually creating a domid.
Reported-by: Julien Grall <julien.grall@citrix.com>
CC: Julien Grall <julien.grall@citrix.com>
Signed-off-by: Ian Jackson <Ian.Jackson@eu.citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
commit 28e5d9a9ad8e7e1a50503ec97ce9d20cd451a5d1
Author: Wei Liu <wei.liu2@citrix.com>
Date: Tue Jun 30 15:06:14 2015 +0100
Config.mk: update in-tree OVMF changeset
Signed-off-by: Wei Liu <wei.liu2@citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
commit 2804137167ca3f9c0d4feb173a46a90ebe747cda
Author: Dario Faggioli <dario.faggioli@citrix.com>
Date: Thu Jun 25 14:44:09 2015 +0200
xen: new maintainer for the RTDS scheduler
Signed-off-by: Dario Faggioli <dario.faggioli@citrix.com>
Reviewed-and-Acked-by: Meng Xu <mengxu@cis.upenn.edu>
Acked-by: George Dunlap <george.dunlap@eu.citrix.com>
commit 3b949cb13179585e730a4a92f0433634a9bd2b96
Author: Ian Campbell <ian.campbell@citrix.com>
Date: Fri Jun 26 12:35:09 2015 +0100
xen: arm: Fixup stray hard tabs
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Reviewed-by: Julien Grall <julien.grall@citrix.com>
commit 71bb7304e7a7a35ea6df4b0cedebc35028e4c159
Author: Liang Li <liang.z.li@intel.com>
Date: Tue Jun 30 05:27:16 2015 +0800
nested EPT: fix the handling of nested EPT
If the host EPT entry is changed, the nested EPT should be updated.
the current code does not do this, and it's wrong.
I have tested this patch, the L2 guest can boot and run as normal.
Signed-off-by: Liang Li <liang.z.li@intel.com>
Signed-off-by: Yang Zhang <yang.z.zhang@intel.com>
Reported-by: Tim Deegan <tim@xen.org>
Reviewed-by: Tim Deegan <tim@xen.org>
commit a9d44224ed3970eab86b41c20bee7a804edc5129
Author: Tiejun Chen <tiejun.chen@intel.com>
Date: Mon Jun 29 14:51:36 2015 +0800
tools/libxc: check to set args.mmio_size before call xc_hvm_build
After commit 5dff8e9eedc7, "libxc/libxl: fill xc_hvm_build_args in
libxl" is introduced, we won't check to set args.mmio_size inside
xc_hvm_build as before. So instead, we need to do this before call
that.
CC: Ian Jackson <ian.jackson@eu.citrix.com>
CC: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
CC: Ian Campbell <ian.campbell@citrix.com>
CC: Wei Liu <wei.liu2@citrix.com>
Acked-by: Wei Liu <wei.liu2@citrix.com>
Signed-off-by: Tiejun Chen <tiejun.chen@intel.com>
commit 1f627301e66ac62053ee246367a1b576cbded052
Author: Ian Campbell <ian.campbell@citrix.com>
Date: Fri Jun 26 10:41:28 2015 +0100
xen: Install unstripped version -syms version into /usr/lib/debug
xen-*-syms cannot actually be booted, so putting it in /boot is a bit
misleading. It also happens to cause a warning from update-grub (so at
least it doesn't end up in grub.cfg)
/usr/lib/debug seems to be a pretty common path for installing such
debug info.
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
[ ijc -- fixed typos ]
commit fff2304e471e6db2136bad9237f2ed18580615f1
Author: Ian Campbell <ian.campbell@citrix.com>
Date: Fri Jun 26 12:39:54 2015 +0100
xen: arm: Log a warning message when a deprecated hypercall is used
A few folks have been caught out by OSes which call e.g.
HYPERVISOR_event_channel_op_compat which has been deprecated since
3.2.2 (i.e. long before Xen on ARM). Existing x86 code can still
safely and quietly using those calls, waiting for an unsuspecting ARM
porter to turn up and trip over it. This turns out to be rather
perplexing when it happens, since it can be obscured e.g. by various
conditionals like __XEN_INTERFACE_VERSION__ what is actually being
called.
Note that I'm making a distinction here between hypercalls which are
simply not used/implemented on arm (yet) and those which were
deprecated and replaced by a newer variant prior to Xen on ARM even
being invented. The latter will never be implemented on ARM and have
non-deprecated aliases leading to confusion so those are the ones for
which a warning is useful.
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Tested-by: Ard Biesheuvel <ard@linaro.org>
Cc: Jan Beulich <JBeulich@suse.com>
Cc: Keir Fraser <keir@xen.org>
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Anthony PERARD <anthony.perard@citrix.com>
Reviewed-by: Julien Grall <julien.grall@citrix.com>
commit 044dfa8d7fcaa757a00add755ba195082f646a6a
Author: Julien Grall <julien.grall@citrix.com>
Date: Tue Jun 30 13:22:17 2015 +0100
docs: Fix docs output after commit 6592bf6
A find option was forgotten in commit 6592bf60beaf1fa0b4fd36fb73800eb001c739af
"docs: Look for documentation in sub-directories" resulting to get some
docs duplicated and other missing.
Signed-off-by: Julien Grall <julien.grall@citrix.com>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
commit c7f3416663bdffaa6b962c916740a56b216b740f
Author: Wen Congyang <wency@cn.fujitsu.com>
Date: Tue Jun 30 16:55:32 2015 +0800
libxl: remove now unnecessary gc from libxl__async_exec_start calls
These were removed in commit f5f8400f.
Signed-off-by: Wen Congyang <wency@cn.fujitsu.com>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
commit e00ab5e0770ccd458211d6fe5b679e15f8d66bcf
Author: Ian Jackson <ian.jackson@eu.citrix.com>
Date: Mon Jun 29 15:29:33 2015 +0100
libxl: Fix uninitialised rc in libxl__domain_save_device_model
c3c8da9 "libxl: ao: datacopier callback gets an rc" caused
libxl__domain_save_device_model() to pass its rc directly into the
callback.
However in the preexisting code, there were 3 "goto out;" paths which
left rc uninitialised. This causes a build failure with GCC 4.8's
-Wmaybe-uninitialized.
Set the rc explicitly on each goto out path.
Reported-by: Andrew Cooper <andrew.cooper3@citrix.com>
Signed-off-by: Ian Jackson <Ian.Jackson@eu.citrix.com>
Tested-by: Andrew Cooper <andrew.cooper3@citrix.com>
(qemu changes not included)
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [xen-unstable test] 59040: regressions - FAIL
2015-07-03 21:59 [xen-unstable test] 59040: regressions - FAIL osstest service owner
@ 2015-07-06 12:33 ` Ian Campbell
2015-07-06 12:47 ` Ian Jackson
2015-07-06 14:05 ` Dario Faggioli
0 siblings, 2 replies; 8+ messages in thread
From: Ian Campbell @ 2015-07-06 12:33 UTC (permalink / raw)
To: xen-devel, ian.jackson; +Cc: Wei Liu
On Fri, 2015-07-03 at 21:59 +0000, osstest service owner wrote:
> flight 59040 xen-unstable real [real]
> http://logs.test-lab.xenproject.org/osstest/logs/59040/
>
> Regressions :-(
>
> Tests which did not succeed and are blocking,
> including tests which could not be run:
> test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 14 guest-localmigrate.2 fail REGR. vs. 58958
http://logs.test-lab.xenproject.org/osstest/results/history/test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm/xen-unstable.html
This one seems to have fallen into the merlot trap.
> test-armhf-armhf-xl-credit2 15 guest-start/debian.repeat fail REGR. vs. 58965
From
http://logs.test-lab.xenproject.org/osstest/results/history/test-armhf-armhf-xl-credit2/xen-unstable.html it appears this one is sporadically unreliable on cubietruck, but works just fine on arndale.
Comparing to
http://logs.test-lab.xenproject.org/osstest/results/history/test-armhf-armhf-xl/xen-unstable.html
it looks to be credit2 specific.
d8v0 has a PC at 0xffff000c, which will be the entry point for the
prefetch abort handler. ABT_LR shows it came from 0xffff0010 which is
the data abt handler, which uses the same banked LR as prefetch abt so
we don't know where it came from.
SVR_LR shows that the last function call done in kernel mode was a call
to fdt_check_header from early_init_dt_verify, but that might have been
ages ago.
Guest logs ends with it shutting down, but I think that is the previous
test step completing.
> test-amd64-amd64-xl-qemuu-debianhvm-amd64 17 guest-start.2 fail REGR. vs. 58965
http://logs.test-lab.xenproject.org/osstest/results/history/test-amd64-amd64-xl-qemuu-debianhvm-amd64/xen-unstable.html
2015-07-03 15:40:16 Z guest debianhvm.guest.osstest 5a:36:0e:a0:00:1e 22 link/ip/tcp: ping gave (256): PING 172.16.146.71 (172.16.146.71) 56(84) bytes of data. | From 172.16.144.3 icmp_seq=1 Destination Host Unreachable | From 172.16.144.3 icmp_seq=2 Destination Host Unreachable | From 172.16.144.3 icmp_seq=3 Destination Host Unreachable | From 172.16.144.3 icmp_seq=4 Destination Host Unreachable | From 172.16.144.3 icmp_seq=5 Destination Host Unreachable | | --- 172.16.146.71 ping statistics --- | 5 packets transmitted, 0 received, +5 errors, 100% packet loss, time XXXms | pipe 3 | (waiting) ...
2015-07-03 15:40:27 Z guest debianhvm.guest.osstest 5a:36:0e:a0:00:1e 22 link/ip/tcp: ok. (31s)
2015-07-03 15:40:27 Z executing ssh ... root@172.16.146.71 echo guest debianhvm.guest.osstest: ok
ssh: connect to host 172.16.146.71 port 22: Connection refused
Ian, I believe you observed some other instances of this in triaging
another failure last week.
http://logs.test-lab.xenproject.org/osstest/logs/59040/test-amd64-amd64-xl-qemuu-debianhvm-amd64/fiano0---var-log-xen-qemu-dm-debianhvm.guest.osstest.log
is pretty uninteresting, we should perhaps arrange to remove some
"quiet"'s from guest commands lines somewhere, or to frob the guest
console to include ttyS0, which it isn't clear it does.
vnc snapshot just shows the login prompt.
The bisector looks to be working on this one
http://logs.test-lab.xenproject.org/osstest/results/bisect/xen-unstable/test-amd64-amd64-xl-qemuu-debianhvm-amd64.guest-start.2.html
but I don't think it is going to conclude anything, since it looks intermittent.
> test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 9 debian-hvm-install fail REGR. vs. 58965
http://logs.test-lab.xenproject.org/osstest/results/history/test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm/xen-unstable.html
2015-07-03 15:39:29 Z executing ssh ... root@172.16.144.41 xl list
2015-07-03 15:39:30 Z guest debianhvm.guest.osstest not present on this host
2015-07-03 15:39:30 Z FAILURE: guest unexpectedly shutdown; state is ''
failure: guest unexpectedly shutdown; state is ''
The xl log just says:
Waiting for domain debianhvm.guest.osstest (domid 1) to die [pid 4412]
Domain 1 has shut down, reason code 0 0x0
Action for shutdown reason code 0 is destroy
Domain 1 needs to be cleaned up: destroying the domain
Done. Exiting now
Ian.
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [xen-unstable test] 59040: regressions - FAIL
2015-07-06 12:33 ` Ian Campbell
@ 2015-07-06 12:47 ` Ian Jackson
2015-07-06 12:57 ` Ian Campbell
2015-07-06 14:05 ` Dario Faggioli
1 sibling, 1 reply; 8+ messages in thread
From: Ian Jackson @ 2015-07-06 12:47 UTC (permalink / raw)
To: Ian Campbell; +Cc: xen-devel, Wei Liu
Ian Campbell writes ("Re: [Xen-devel] [xen-unstable test] 59040: regressions - FAIL"):
> From
> http://logs.test-lab.xenproject.org/osstest/results/history/test-armhf-armhf-xl-credit2/xen-unstable.html it appears this one is sporadically unreliable on cubietruck, but works just fine on arndale.
...
> it looks to be credit2 specific.
..
> Ian, I believe you observed some other instances of this in triaging
> another failure last week.
Yes, but I'm afraid I don't remember exactly which failure.
> The bisector looks to be working on this one
> http://logs.test-lab.xenproject.org/osstest/results/bisect/xen-unstable/test-amd64-amd64-xl-qemuu-debianhvm-amd64.guest-start.2.html
> but I don't think it is going to conclude anything, since it looks intermittent.
>
> > test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 9 debian-hvm-install fail REGR. vs. 58965
>
> http://logs.test-lab.xenproject.org/osstest/results/history/test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm/xen-unstable.html
>
> 2015-07-03 15:39:29 Z executing ssh ... root@172.16.144.41 xl list
> 2015-07-03 15:39:30 Z guest debianhvm.guest.osstest not present on this host
> 2015-07-03 15:39:30 Z FAILURE: guest unexpectedly shutdown; state is ''
> failure: guest unexpectedly shutdown; state is ''
>
> The xl log just says:
>
> Waiting for domain debianhvm.guest.osstest (domid 1) to die [pid 4412]
> Domain 1 has shut down, reason code 0 0x0
> Action for shutdown reason code 0 is destroy
> Domain 1 needs to be cleaned up: destroying the domain
> Done. Exiting now
This is quite weird.
Ian.
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [xen-unstable test] 59040: regressions - FAIL
2015-07-06 12:47 ` Ian Jackson
@ 2015-07-06 12:57 ` Ian Campbell
2015-07-06 13:23 ` Wei Liu
0 siblings, 1 reply; 8+ messages in thread
From: Ian Campbell @ 2015-07-06 12:57 UTC (permalink / raw)
To: Ian Jackson; +Cc: xen-devel, Wei Liu
On Mon, 2015-07-06 at 13:47 +0100, Ian Jackson wrote:
> > > test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 9 debian-hvm-install fail REGR. vs. 58965
> >
> > http://logs.test-lab.xenproject.org/osstest/results/history/test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm/xen-unstable.html
> >
> > 2015-07-03 15:39:29 Z executing ssh ... root@172.16.144.41 xl list
> > 2015-07-03 15:39:30 Z guest debianhvm.guest.osstest not present on this host
> > 2015-07-03 15:39:30 Z FAILURE: guest unexpectedly shutdown; state is ''
> > failure: guest unexpectedly shutdown; state is ''
> >
> > The xl log just says:
> >
> > Waiting for domain debianhvm.guest.osstest (domid 1) to die [pid 4412]
> > Domain 1 has shut down, reason code 0 0x0
> > Action for shutdown reason code 0 is destroy
> > Domain 1 needs to be cleaned up: destroying the domain
> > Done. Exiting now
>
> This is quite weird.
I just spotted near the end of
http://logs.test-lab.xenproject.org/osstest/logs/59040/test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm/serial-italia1.log
that the BIOS failed to find a device to boot from, for some reason
(which is still weird)...
Jul 3 15:38:29.941066 (d1) HVM Loader
Jul 3 15:38:29.941085 (d1) Detected Xen v4.6-unstable
Jul 3 15:38:29.949058 (d1) Xenbus rings @0xfeffc000, event channel 1
Jul 3 15:38:29.949105 (d1) System requested ROMBIOS
Jul 3 15:38:29.949145 (d1) CPU speed is 3093 MHz
Jul 3 15:38:29.957103 (d1) Relocating guest memory for lowmem MMIO space enabled
Jul 3 15:38:29.957138 (XEN) irq.c:276: Dom1 PCI link 0 changed 0 -> 5
Jul 3 15:38:29.965066 (d1) PCI-ISA link 0 routed to IRQ5
Jul 3 15:38:29.965085 (XEN) irq.c:276: Dom1 PCI link 1 changed 0 -> 10
Jul 3 15:38:29.973094 (d1) PCI-ISA link 1 routed to IRQ10
Jul 3 15:38:29.973113 (XEN) irq.c:276: Dom1 PCI link 2 changed 0 -> 11
Jul 3 15:38:29.981088 (d1) PCI-ISA link 2 routed to IRQ11
Jul 3 15:38:29.981132 (XEN) irq.c:276: Dom1 PCI link 3 changed 0 -> 5
Jul 3 15:38:29.989050 (d1) PCI-ISA link 3 routed to IRQ5
Jul 3 15:38:29.989087 (d1) pci dev 01:2 INTD->IRQ5
Jul 3 15:38:29.989102 (d1) pci dev 01:3 INTA->IRQ10
Jul 3 15:38:29.997056 (d1) pci dev 03:0 INTA->IRQ5
Jul 3 15:38:29.997072 (d1) pci dev 04:0 INTA->IRQ5
Jul 3 15:38:29.997086 (d1) No RAM in high memory; setting high_mem resource base to 100000000
Jul 3 15:38:30.005050 (d1) pci dev 02:0 bar 10 size 002000000: 0f0000008
Jul 3 15:38:30.013064 (d1) pci dev 03:0 bar 14 size 001000000: 0f2000008
Jul 3 15:38:30.013088 (d1) pci dev 02:0 bar 14 size 000001000: 0f3000000
Jul 3 15:38:30.021068 (d1) pci dev 03:0 bar 10 size 000000100: 00000c001
Jul 3 15:38:30.029048 (d1) pci dev 04:0 bar 10 size 000000100: 00000c101
Jul 3 15:38:30.029068 (d1) pci dev 04:0 bar 14 size 000000100: 0f3001000
Jul 3 15:38:30.037043 (d1) pci dev 01:2 bar 20 size 000000020: 00000c201
Jul 3 15:38:30.037076 (d1) pci dev 01:1 bar 20 size 000000010: 00000c221
Jul 3 15:38:30.045054 (d1) Multiprocessor initialisation:
Jul 3 15:38:30.045093 (d1) - CPU0 ... 36-bit phys ... fixed MTRRs ... var MTRRs [1/8] ... done.
Jul 3 15:38:30.053063 (d1) - CPU1 ... 36-bit phys ... fixed MTRRs ... var MTRRs [1/8] ... done.
Jul 3 15:38:30.061060 (d1) Testing HVM environment:
Jul 3 15:38:30.061098 (d1) - REP INSB across page boundaries ... passed
Jul 3 15:38:30.069053 (d1) - GS base MSRs and SWAPGS ... passed
Jul 3 15:38:30.069087 (d1) Passed 2 of 2 tests
Jul 3 15:38:30.069122 (d1) Writing SMBIOS tables ...
Jul 3 15:38:30.077038 (d1) Loading ROMBIOS ...
Jul 3 15:38:30.077071 (d1) 16892 bytes of ROMBIOS high-memory extensions:
Jul 3 15:38:30.085038 (d1) Relocating to 0xfc001000-0xfc0051fc ... done
Jul 3 15:38:30.085077 (d1) Creating MP tables ...
Jul 3 15:38:30.093048 (d1) Loading Cirrus VGABIOS ...
Jul 3 15:38:30.093079 (d1) Loading PCI Option ROM ...
Jul 3 15:38:30.093106 (d1) - Manufacturer: http://ipxe.org
Jul 3 15:38:30.101089 (d1) - Product name: iPXE
Jul 3 15:38:30.101118 (d1) Option ROMs:
Jul 3 15:38:30.101157 (d1) c0000-c8fff: VGA BIOS
Jul 3 15:38:30.109054 (d1) c9000-d8fff: Etherboot ROM
Jul 3 15:38:30.109070 (d1) Loading ACPI ...
Jul 3 15:38:30.109084 (d1) vm86 TSS at fc011480
Jul 3 15:38:30.109121 (d1) BIOS map:
Jul 3 15:38:30.117085 (d1) f0000-fffff: Main BIOS
Jul 3 15:38:30.117114 (d1) E820 table:
Jul 3 15:38:30.117138 (d1) [00]: 00000000:00000000 - 00000000:0009e000: RAM
Jul 3 15:38:30.125089 (d1) [01]: 00000000:0009e000 - 00000000:000a0000: RESERVED
Jul 3 15:38:30.125113 (d1) HOLE: 00000000:000a0000 - 00000000:000e0000
Jul 3 15:38:30.133060 (d1) [02]: 00000000:000e0000 - 00000000:00100000: RESERVED
Jul 3 15:38:30.141086 (d1) [03]: 00000000:00100000 - 00000000:2fc00000: RAM
Jul 3 15:38:30.141104 (d1) HOLE: 00000000:2fc00000 - 00000000:fc000000
Jul 3 15:38:30.149034 (d1) [04]: 00000000:fc000000 - 00000001:00000000: RESERVED
Jul 3 15:38:30.149079 (d1) Invoking ROMBIOS ...
Jul 3 15:38:30.157028 (XEN) stdvga.c:147:d1v0 entering stdvga and caching modes
Jul 3 15:38:30.157075 (d1) VGABios $Id: vgabios.c,v 1.67 2008/01/27 09:44:12 vruppert Exp $
Jul 3 15:38:30.165046 (d1) Bochs BIOS - build: 06/23/99
Jul 3 15:38:30.165085 (d1) $Revision: 1.221 $ $Date: 2008/12/07 17:32:29 $
Jul 3 15:38:30.173034 (d1) Options: apmbios pcibios eltorito PMM
Jul 3 15:38:30.181025 (d1)
Jul 3 15:38:30.181038 (d1) ata0 master: QEMU HARDDISK ATA-7 Hard-Disk (10000 MBytes)
Jul 3 15:38:30.181065 (d1) ata1 master: QEMU DVD-ROM ATAPI-4 CD-Rom/DVD-Rom
Jul 3 15:38:30.189055 (d1)
Jul 3 15:38:30.189088 (d1)
Jul 3 15:38:30.189100 (d1)
Jul 3 15:38:30.189111 (d1) Press F12 for boot menu.
Jul 3 15:38:30.189127 (d1)
Jul 3 15:38:30.197055 (d1) Booting from CD-Rom...
Jul 3 15:38:30.197083 (d1) 626MB medium detected
Jul 3 15:38:30.197113 (d1) CDROM boot failure code : 0005
Jul 3 15:38:30.205047 (d1) Boot from CD-Rom failed: could not read the boot disk
Jul 3 15:38:30.205088 (d1)
Jul 3 15:38:30.205106 (d1) Booting from Hard Disk...
Jul 3 15:38:30.213051 (d1) Boot from Hard Disk failed: not a bootable disk
Jul 3 15:38:30.213093 (d1)
Jul 3 15:38:30.213106 (d1)
Jul 3 15:38:30.213121 (d1) No bootable device.
Jul 3 15:38:30.221017 (d1) Powering off in 30 seconds.
Jul 3 15:38:30.221033 (XEN) hvm.c:2408:d1v0 All CPUs offline -- powering off.
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [xen-unstable test] 59040: regressions - FAIL
2015-07-06 12:57 ` Ian Campbell
@ 2015-07-06 13:23 ` Wei Liu
2015-07-06 13:37 ` Ian Campbell
0 siblings, 1 reply; 8+ messages in thread
From: Wei Liu @ 2015-07-06 13:23 UTC (permalink / raw)
To: Ian Campbell; +Cc: Wei Liu, xen-devel, Ian Jackson
On Mon, Jul 06, 2015 at 01:57:28PM +0100, Ian Campbell wrote:
> On Mon, 2015-07-06 at 13:47 +0100, Ian Jackson wrote:
> > > > test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 9 debian-hvm-install fail REGR. vs. 58965
> > >
> > > http://logs.test-lab.xenproject.org/osstest/results/history/test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm/xen-unstable.html
> > >
> > > 2015-07-03 15:39:29 Z executing ssh ... root@172.16.144.41 xl list
> > > 2015-07-03 15:39:30 Z guest debianhvm.guest.osstest not present on this host
> > > 2015-07-03 15:39:30 Z FAILURE: guest unexpectedly shutdown; state is ''
> > > failure: guest unexpectedly shutdown; state is ''
> > >
> > > The xl log just says:
> > >
> > > Waiting for domain debianhvm.guest.osstest (domid 1) to die [pid 4412]
> > > Domain 1 has shut down, reason code 0 0x0
> > > Action for shutdown reason code 0 is destroy
> > > Domain 1 needs to be cleaned up: destroying the domain
> > > Done. Exiting now
> >
> > This is quite weird.
>
> I just spotted near the end of
> http://logs.test-lab.xenproject.org/osstest/logs/59040/test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm/serial-italia1.log
> that the BIOS failed to find a device to boot from, for some reason
> (which is still weird)...
>
> Jul 3 15:38:29.941066 (d1) HVM Loader
> Jul 3 15:38:29.941085 (d1) Detected Xen v4.6-unstable
> Jul 3 15:38:29.949058 (d1) Xenbus rings @0xfeffc000, event channel 1
> Jul 3 15:38:29.949105 (d1) System requested ROMBIOS
> Jul 3 15:38:29.949145 (d1) CPU speed is 3093 MHz
> Jul 3 15:38:29.957103 (d1) Relocating guest memory for lowmem MMIO space enabled
> Jul 3 15:38:29.957138 (XEN) irq.c:276: Dom1 PCI link 0 changed 0 -> 5
> Jul 3 15:38:29.965066 (d1) PCI-ISA link 0 routed to IRQ5
> Jul 3 15:38:29.965085 (XEN) irq.c:276: Dom1 PCI link 1 changed 0 -> 10
> Jul 3 15:38:29.973094 (d1) PCI-ISA link 1 routed to IRQ10
> Jul 3 15:38:29.973113 (XEN) irq.c:276: Dom1 PCI link 2 changed 0 -> 11
> Jul 3 15:38:29.981088 (d1) PCI-ISA link 2 routed to IRQ11
> Jul 3 15:38:29.981132 (XEN) irq.c:276: Dom1 PCI link 3 changed 0 -> 5
> Jul 3 15:38:29.989050 (d1) PCI-ISA link 3 routed to IRQ5
> Jul 3 15:38:29.989087 (d1) pci dev 01:2 INTD->IRQ5
> Jul 3 15:38:29.989102 (d1) pci dev 01:3 INTA->IRQ10
> Jul 3 15:38:29.997056 (d1) pci dev 03:0 INTA->IRQ5
> Jul 3 15:38:29.997072 (d1) pci dev 04:0 INTA->IRQ5
> Jul 3 15:38:29.997086 (d1) No RAM in high memory; setting high_mem resource base to 100000000
> Jul 3 15:38:30.005050 (d1) pci dev 02:0 bar 10 size 002000000: 0f0000008
> Jul 3 15:38:30.013064 (d1) pci dev 03:0 bar 14 size 001000000: 0f2000008
> Jul 3 15:38:30.013088 (d1) pci dev 02:0 bar 14 size 000001000: 0f3000000
> Jul 3 15:38:30.021068 (d1) pci dev 03:0 bar 10 size 000000100: 00000c001
> Jul 3 15:38:30.029048 (d1) pci dev 04:0 bar 10 size 000000100: 00000c101
> Jul 3 15:38:30.029068 (d1) pci dev 04:0 bar 14 size 000000100: 0f3001000
> Jul 3 15:38:30.037043 (d1) pci dev 01:2 bar 20 size 000000020: 00000c201
> Jul 3 15:38:30.037076 (d1) pci dev 01:1 bar 20 size 000000010: 00000c221
> Jul 3 15:38:30.045054 (d1) Multiprocessor initialisation:
> Jul 3 15:38:30.045093 (d1) - CPU0 ... 36-bit phys ... fixed MTRRs ... var MTRRs [1/8] ... done.
> Jul 3 15:38:30.053063 (d1) - CPU1 ... 36-bit phys ... fixed MTRRs ... var MTRRs [1/8] ... done.
> Jul 3 15:38:30.061060 (d1) Testing HVM environment:
> Jul 3 15:38:30.061098 (d1) - REP INSB across page boundaries ... passed
> Jul 3 15:38:30.069053 (d1) - GS base MSRs and SWAPGS ... passed
> Jul 3 15:38:30.069087 (d1) Passed 2 of 2 tests
> Jul 3 15:38:30.069122 (d1) Writing SMBIOS tables ...
> Jul 3 15:38:30.077038 (d1) Loading ROMBIOS ...
> Jul 3 15:38:30.077071 (d1) 16892 bytes of ROMBIOS high-memory extensions:
> Jul 3 15:38:30.085038 (d1) Relocating to 0xfc001000-0xfc0051fc ... done
> Jul 3 15:38:30.085077 (d1) Creating MP tables ...
> Jul 3 15:38:30.093048 (d1) Loading Cirrus VGABIOS ...
> Jul 3 15:38:30.093079 (d1) Loading PCI Option ROM ...
> Jul 3 15:38:30.093106 (d1) - Manufacturer: http://ipxe.org
> Jul 3 15:38:30.101089 (d1) - Product name: iPXE
> Jul 3 15:38:30.101118 (d1) Option ROMs:
> Jul 3 15:38:30.101157 (d1) c0000-c8fff: VGA BIOS
> Jul 3 15:38:30.109054 (d1) c9000-d8fff: Etherboot ROM
> Jul 3 15:38:30.109070 (d1) Loading ACPI ...
> Jul 3 15:38:30.109084 (d1) vm86 TSS at fc011480
> Jul 3 15:38:30.109121 (d1) BIOS map:
> Jul 3 15:38:30.117085 (d1) f0000-fffff: Main BIOS
> Jul 3 15:38:30.117114 (d1) E820 table:
> Jul 3 15:38:30.117138 (d1) [00]: 00000000:00000000 - 00000000:0009e000: RAM
> Jul 3 15:38:30.125089 (d1) [01]: 00000000:0009e000 - 00000000:000a0000: RESERVED
> Jul 3 15:38:30.125113 (d1) HOLE: 00000000:000a0000 - 00000000:000e0000
> Jul 3 15:38:30.133060 (d1) [02]: 00000000:000e0000 - 00000000:00100000: RESERVED
> Jul 3 15:38:30.141086 (d1) [03]: 00000000:00100000 - 00000000:2fc00000: RAM
> Jul 3 15:38:30.141104 (d1) HOLE: 00000000:2fc00000 - 00000000:fc000000
> Jul 3 15:38:30.149034 (d1) [04]: 00000000:fc000000 - 00000001:00000000: RESERVED
> Jul 3 15:38:30.149079 (d1) Invoking ROMBIOS ...
> Jul 3 15:38:30.157028 (XEN) stdvga.c:147:d1v0 entering stdvga and caching modes
> Jul 3 15:38:30.157075 (d1) VGABios $Id: vgabios.c,v 1.67 2008/01/27 09:44:12 vruppert Exp $
> Jul 3 15:38:30.165046 (d1) Bochs BIOS - build: 06/23/99
> Jul 3 15:38:30.165085 (d1) $Revision: 1.221 $ $Date: 2008/12/07 17:32:29 $
> Jul 3 15:38:30.173034 (d1) Options: apmbios pcibios eltorito PMM
> Jul 3 15:38:30.181025 (d1)
> Jul 3 15:38:30.181038 (d1) ata0 master: QEMU HARDDISK ATA-7 Hard-Disk (10000 MBytes)
> Jul 3 15:38:30.181065 (d1) ata1 master: QEMU DVD-ROM ATAPI-4 CD-Rom/DVD-Rom
> Jul 3 15:38:30.189055 (d1)
> Jul 3 15:38:30.189088 (d1)
> Jul 3 15:38:30.189100 (d1)
> Jul 3 15:38:30.189111 (d1) Press F12 for boot menu.
> Jul 3 15:38:30.189127 (d1)
> Jul 3 15:38:30.197055 (d1) Booting from CD-Rom...
> Jul 3 15:38:30.197083 (d1) 626MB medium detected
> Jul 3 15:38:30.197113 (d1) CDROM boot failure code : 0005
> Jul 3 15:38:30.205047 (d1) Boot from CD-Rom failed: could not read the boot disk
> Jul 3 15:38:30.205088 (d1)
> Jul 3 15:38:30.205106 (d1) Booting from Hard Disk...
> Jul 3 15:38:30.213051 (d1) Boot from Hard Disk failed: not a bootable disk
> Jul 3 15:38:30.213093 (d1)
> Jul 3 15:38:30.213106 (d1)
> Jul 3 15:38:30.213121 (d1) No bootable device.
> Jul 3 15:38:30.221017 (d1) Powering off in 30 seconds.
> Jul 3 15:38:30.221033 (XEN) hvm.c:2408:d1v0 All CPUs offline -- powering off.
I saw this bug since the introduction of amd64-i386 stubdom test case.
Now it looks like intermittent, i.e. we failed at the beginning, passed
at some point, now it failed again.
Wei.
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [xen-unstable test] 59040: regressions - FAIL
2015-07-06 13:23 ` Wei Liu
@ 2015-07-06 13:37 ` Ian Campbell
2015-07-06 13:52 ` Wei Liu
0 siblings, 1 reply; 8+ messages in thread
From: Ian Campbell @ 2015-07-06 13:37 UTC (permalink / raw)
To: Wei Liu; +Cc: xen-devel, Ian Jackson
On Mon, 2015-07-06 at 14:23 +0100, Wei Liu wrote:
> I saw this bug since the introduction of amd64-i386 stubdom test case.
> Now it looks like intermittent, i.e. we failed at the beginning, passed
> at some point, now it failed again.
http://logs.test-lab.xenproject.org/osstest/results/history/test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm/xen-unstable.html
gives the history of it.
It looks as if italia* and chardonnay* might be susceptible but really I
don't think there is sufficient information to draw any particular
conclusion wrt the frequency of this bug or whether it might be host
specific or not, since the passes on other hosts are general singletons.
The 64-bit dom0 case is at
http://logs.test-lab.xenproject.org/osstest/results/history/test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm/xen-unstable.html
I'm not sure what, if anything, it tells us though. It does look to be
more less prone to errors (it having now hit merlot notwithstanding,
although it seems to reliably pass the install phase there).
One potentially interesting case is that in the 32-bit dom0 case the
stubdom is also 32-bit, while in the other case the stubdom is 64-bit.
I'm not convinced using a 32-bit stubdom is the right choice, but I
suppose it ought to work.
Ian.
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [xen-unstable test] 59040: regressions - FAIL
2015-07-06 13:37 ` Ian Campbell
@ 2015-07-06 13:52 ` Wei Liu
0 siblings, 0 replies; 8+ messages in thread
From: Wei Liu @ 2015-07-06 13:52 UTC (permalink / raw)
To: Ian Campbell; +Cc: Ian Jackson, xen-devel, Wei Liu
On Mon, Jul 06, 2015 at 02:37:31PM +0100, Ian Campbell wrote:
> On Mon, 2015-07-06 at 14:23 +0100, Wei Liu wrote:
>
> > I saw this bug since the introduction of amd64-i386 stubdom test case.
> > Now it looks like intermittent, i.e. we failed at the beginning, passed
> > at some point, now it failed again.
>
> http://logs.test-lab.xenproject.org/osstest/results/history/test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm/xen-unstable.html
> gives the history of it.
>
> It looks as if italia* and chardonnay* might be susceptible but really I
> don't think there is sufficient information to draw any particular
> conclusion wrt the frequency of this bug or whether it might be host
> specific or not, since the passes on other hosts are general singletons.
>
Note that we do have one pass vs five fails on italia0. The same goes
for chardonay0 (one pass vs four fails). It's really weird.
> The 64-bit dom0 case is at
> http://logs.test-lab.xenproject.org/osstest/results/history/test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm/xen-unstable.html
> I'm not sure what, if anything, it tells us though. It does look to be
> more less prone to errors (it having now hit merlot notwithstanding,
> although it seems to reliably pass the install phase there).
>
> One potentially interesting case is that in the 32-bit dom0 case the
> stubdom is also 32-bit, while in the other case the stubdom is 64-bit.
>
> I'm not convinced using a 32-bit stubdom is the right choice, but I
> suppose it ought to work.
>
Yeah, it ought to work. But making it actually work requires much
effort. I would say let's mark that failure none blocking for the
moment.
Wei.
> Ian.
>
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [xen-unstable test] 59040: regressions - FAIL
2015-07-06 12:33 ` Ian Campbell
2015-07-06 12:47 ` Ian Jackson
@ 2015-07-06 14:05 ` Dario Faggioli
1 sibling, 0 replies; 8+ messages in thread
From: Dario Faggioli @ 2015-07-06 14:05 UTC (permalink / raw)
To: Ian Campbell; +Cc: Wei Liu, xen-devel, ian.jackson
[-- Attachment #1.1: Type: text/plain, Size: 1946 bytes --]
On Mon, 2015-07-06 at 13:33 +0100, Ian Campbell wrote:
> On Fri, 2015-07-03 at 21:59 +0000, osstest service owner wrote:
> > test-armhf-armhf-xl-credit2 15 guest-start/debian.repeat fail REGR. vs. 58965
>
> From
> http://logs.test-lab.xenproject.org/osstest/results/history/test-armhf-armhf-xl-credit2/xen-unstable.html it appears this one is sporadically unreliable on cubietruck, but works just fine on arndale.
>
> Comparing to
> http://logs.test-lab.xenproject.org/osstest/results/history/test-armhf-armhf-xl/xen-unstable.html
> it looks to be credit2 specific.
>
Yes, noted... I shall have a look.
From what I recall, failures varies a bit, in terms of what the state of
the system (vcpus active/idle, etc.) when the fail itself happens.
If I'm not confusing this with something else, I've seen instances where
everything was completely idle and instances, like this one, where there
is something going on... As I said, I'll have a look.
> d8v0 has a PC at 0xffff000c, which will be the entry point for the
> prefetch abort handler. ABT_LR shows it came from 0xffff0010 which is
> the data abt handler, which uses the same banked LR as prefetch abt so
> we don't know where it came from.
>
> SVR_LR shows that the last function call done in kernel mode was a call
> to fdt_check_header from early_init_dt_verify, but that might have been
> ages ago.
>
Thanks for this. My nonexistent knowledge of ARM internals limits by
quite a bit the amount of information that I can extract from this
trace... but this is already something.
I'll ask if there is anything that is ARM specific that I need but can't
figure out.
Regards,
Dario
--
<<This happens because I choose it to happen!>> (Raistlin Majere)
-----------------------------------------------------------------
Dario Faggioli, Ph.D, http://about.me/dario.faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)
[-- Attachment #1.2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 181 bytes --]
[-- Attachment #2: Type: text/plain, Size: 126 bytes --]
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2015-07-06 14:05 UTC | newest]
Thread overview: 8+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2015-07-03 21:59 [xen-unstable test] 59040: regressions - FAIL osstest service owner
2015-07-06 12:33 ` Ian Campbell
2015-07-06 12:47 ` Ian Jackson
2015-07-06 12:57 ` Ian Campbell
2015-07-06 13:23 ` Wei Liu
2015-07-06 13:37 ` Ian Campbell
2015-07-06 13:52 ` Wei Liu
2015-07-06 14:05 ` Dario Faggioli
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.