xen.org
2012-Sep-25 22:57 UTC
[xen-unstable test] 13866: regressions - trouble: broken/fail/pass
flight 13866 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/13866/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-credit2 5 xen-boot fail REGR. vs. 13825
test-amd64-i386-win-vcpus1 5 xen-boot fail REGR. vs. 13825
test-amd64-amd64-pv 10 guest-saverestore fail REGR. vs. 13825
test-amd64-i386-rhel6hvm-intel 5 xen-boot fail REGR. vs. 13825
test-amd64-amd64-win 3 host-install(3) broken REGR. vs. 13825
test-amd64-amd64-xl-winxpsp3 5 xen-boot fail REGR. vs. 13825
test-amd64-i386-pair 8 xen-boot/dst_host fail REGR. vs. 13825
Regressions which are regarded as allowable (not blocking):
test-amd64-amd64-xl-pcipt-intel 5 xen-boot fail REGR. vs. 13825
test-amd64-amd64-xl-sedf-pin 10 guest-saverestore fail like 13825
test-amd64-amd64-xl-qemuu-winxpsp3 9 guest-localmigrate fail like 13823
test-amd64-amd64-xl-qemuu-win7-amd64 9 guest-localmigrate fail like 13825
Tests which did not succeed, but are not blocking:
test-amd64-i386-win 16 leak-check/check fail never pass
test-amd64-i386-xend-winxpsp3 16 leak-check/check fail never pass
test-amd64-i386-xl-win-vcpus1 13 guest-stop fail never pass
test-amd64-amd64-xl-win7-amd64 13 guest-stop fail never pass
test-amd64-i386-xl-win7-amd64 13 guest-stop fail never pass
test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop fail never pass
test-amd64-amd64-xl-win 13 guest-stop fail never pass
version targeted for testing:
xen 16ee1d300cfd
baseline version:
xen d364becfb083
------------------------------------------------------------
People who touched revisions under test:
Bastian Blank <waldi@debian.org>
Ben Guthro <ben@guthro.net>
Ian Campbell <ian.campbell@citrix.com>
Jan Beulich <jbeulich@suse.com>
Keir Fraser <keir@xen.org>
Olaf Hering <olaf@aepfle.de>
------------------------------------------------------------
jobs:
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-amd64-i386-rhel6hvm-amd pass
test-amd64-i386-qemuu-rhel6hvm-amd pass
test-amd64-amd64-xl-qemuu-win7-amd64 fail
test-amd64-amd64-xl-win7-amd64 fail
test-amd64-i386-xl-win7-amd64 fail
test-amd64-i386-xl-credit2 fail
test-amd64-amd64-xl-pcipt-intel fail
test-amd64-i386-rhel6hvm-intel fail
test-amd64-i386-qemuu-rhel6hvm-intel pass
test-amd64-i386-xl-multivcpu pass
test-amd64-amd64-pair pass
test-amd64-i386-pair fail
test-amd64-amd64-xl-sedf-pin fail
test-amd64-amd64-pv fail
test-amd64-i386-pv pass
test-amd64-amd64-xl-sedf pass
test-amd64-i386-win-vcpus1 fail
test-amd64-i386-xl-win-vcpus1 fail
test-amd64-i386-xl-winxpsp3-vcpus1 fail
test-amd64-amd64-win broken
test-amd64-i386-win fail
test-amd64-amd64-xl-win fail
test-amd64-amd64-xl-qemuu-winxpsp3 fail
test-amd64-i386-xend-winxpsp3 fail
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.
------------------------------------------------------------
changeset: 25942:16ee1d300cfd
tag: tip
user: Bastian Blank <waldi@debian.org>
date: Tue Sep 25 11:03:51 2012 +0100
xl: resume the domain on suspend failure
The MUST macro calls exit(3) on failure but we need to cleanup and
resume.
Signed-off-by: Bastian Blank <waldi@debian.org>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
Committed-by: Ian Campbell <ian.campbell@citrix.com>
changeset: 25941:795c493fe561
user: Olaf Hering <olaf@aepfle.de>
date: Tue Sep 25 11:03:51 2012 +0100
pygrub: always append --args
If a bootloader entry in menu.lst has no additional kernel command line
options listed and the domU.cfg has
''bootargs="--args=something"'' the
additional arguments from the config file are not passed to the kernel.
The reason for that incorrect behaviour is that run_grub appends arg
only if the parsed config file has arguments listed.
Fix this by appending args from image section and the config file separatly.
To avoid adding to a NoneType initialize grubcfg[''args'']
to an empty string.
This does not change behaviour but simplifies the code which appends the
string.
Signed-off-by: Olaf Hering <olaf@aepfle.de>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
Committed-by: Ian Campbell <ian.campbell@citrix.com>
changeset: 25940:c8d65d91a6f2
user: Ben Guthro <ben@guthro.net>
date: Tue Sep 25 08:38:14 2012 +0200
x86/S3: add cache flush on secondary CPUs before going to sleep
Secondary CPUs, between doing their final memory writes (particularly
updating cpu_initialized) and getting a subsequent INIT, may not write
back all modified data. The INIT itself then causes those modifications
to be lost, so in the cpu_initialized case the CPU would find itself
already initialized, (intentionally) entering an infinite loop instead
of actually coming online.
Signed-off-by: Ben Guthro <ben@guthro.net>
Make acpi_dead_idle() call default_dead_idle() rather than duplicating
the logic there.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Keir Fraser <keir@xen.org>
Committed-by: Jan Beulich <jbeulich@suse.com>
changeset: 25939:b49f7bf52fa9
user: Jan Beulich <jbeulich@suse.com>
date: Tue Sep 25 08:36:33 2012 +0200
x86: fix MWAIT-based idle driver for CPUs without ARAT
lapic_timer_{on,off} need to get initialized in this case. This in turn
requires getting HPET broadcast setup to be carried out earlier (and
hence preventing double initialization there).
Signed-off-by: Jan Beulich <jbeulich@suse.com>
changeset: 25938:8f658b463b78
user: Jan Beulich <jbeulich@suse.com>
date: Fri Sep 21 17:02:46 2012 +0200
x86: enable VIA CPU support
Newer VIA CPUs have both 64-bit and VMX support. Enable them to be
recognized for these purposes, at once stripping off any 32-bit CPU
only bits from the respective CPU support file, and adding 64-bit ones
found in recent Linux.
This particularly implies untying the VMX == Intel assumption in a few
places.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Keir Fraser <keir@xen.org>
changeset: 25937:32187301ecc5
user: Jan Beulich <jbeulich@suse.com>
date: Fri Sep 21 15:20:21 2012 +0200
x86: eliminate code affecting only 64-bit-incapable CPUs
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Keir Fraser <keir@xen.org>
changeset: 25936:c8873f13cec3
user: Jan Beulich <jbeulich@suse.com>
date: Fri Sep 21 14:25:12 2012 +0200
printk: prefer %#x et at over 0x%x
Performance is not an issue with printk(), so let the function do
minimally more work and instead save a byte per affected format
specifier.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Keir Fraser <keir@xen.org>
changeset: 25935:1e6e6b49b4ac
user: Jan Beulich <jbeulich@suse.com>
date: Fri Sep 21 13:47:18 2012 +0200
x86: introduce MWAIT-based, ACPI-less CPU idle driver
This is a port of Linux''es intel-idle driver serving the same
purpose.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Keir Fraser <keir@xen.org>
changeset: 25934:8eab91903e71
user: Jan Beulich <jbeulich@suse.com>
date: Fri Sep 21 13:45:08 2012 +0200
cpuidle: remove unused latency_ticks member
... and code used only for initializing it.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Keir Fraser <keir@xen.org>
changeset: 25933:d364becfb083
user: Jan Beulich <jbeulich@suse.com>
date: Thu Sep 20 13:31:19 2012 +0200
introduce guest_handle_for_field()
This helper turns a field of a GUEST_HANDLE in a GUEST_HANDLE.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
(qemu changes not included)
Jan Beulich
2012-Sep-26 07:32 UTC
Re: [xen-unstable test] 13866: regressions - trouble: broken/fail/pass
>>> On 26.09.12 at 00:57, xen.org <ian.jackson@eu.citrix.com> wrote: > flight 13866 xen-unstable real [real] > http://www.chiark.greenend.org.uk/~xensrcts/logs/13866/ > > Regressions :-( > > Tests which did not succeed and are blocking, > including tests which could not be run: > test-amd64-i386-xl-credit2 5 xen-boot fail REGR. vs. 13825 > test-amd64-i386-win-vcpus1 5 xen-boot fail REGR. vs. 13825 > test-amd64-amd64-pv 10 guest-saverestore fail REGR. vs. 13825 > test-amd64-i386-rhel6hvm-intel 5 xen-boot fail REGR. vs. 13825Looking (as an example) at this failure''s log, I can''t see what''s wrong at all - the log suggests that boot completed fine. The host, Dom0, and run queue state dumps also don''t hint at anything being stuck (like wakeups from deep C states not happening). Nevertheless, the MWAIT idle driver is to be suspected most. I''m considering defaulting it to off for now (maybe just for the non-ARAT case that I''m not able to test myself), but the issue I see with this is that this may then continue to be that way forever, if no-one gets to actually look at the problem. Jan> test-amd64-amd64-win 3 host-install(3) broken REGR. vs. 13825 > test-amd64-amd64-xl-winxpsp3 5 xen-boot fail REGR. vs. 13825 > test-amd64-i386-pair 8 xen-boot/dst_host fail REGR. vs. 13825
Jan Beulich
2012-Sep-26 13:55 UTC
Re: [xen-unstable test] 13866: regressions - trouble: broken/fail/pass
>>> On 26.09.12 at 09:32, "Jan Beulich" <JBeulich@suse.com> wrote: >>>> On 26.09.12 at 00:57, xen.org <ian.jackson@eu.citrix.com> wrote: >> flight 13866 xen-unstable real [real] >> http://www.chiark.greenend.org.uk/~xensrcts/logs/13866/ >> >> Regressions :-( >> >> Tests which did not succeed and are blocking, >> including tests which could not be run: >> test-amd64-i386-xl-credit2 5 xen-boot fail REGR. vs. 13825 >> test-amd64-i386-win-vcpus1 5 xen-boot fail REGR. vs. 13825 >> test-amd64-amd64-pv 10 guest-saverestore fail REGR. vs. 13825 >> test-amd64-i386-rhel6hvm-intel 5 xen-boot fail REGR. vs. 13825 > > Looking (as an example) at this failure''s log, I can''t see what''s > wrong at all - the log suggests that boot completed fine. > > The host, Dom0, and run queue state dumps also don''t hint at > anything being stuck (like wakeups from deep C states not > happening). > > Nevertheless, the MWAIT idle driver is to be suspected most. > I''m considering defaulting it to off for now (maybe just for the > non-ARAT case that I''m not able to test myself), but the issue > I see with this is that this may then continue to be that way > forever, if no-one gets to actually look at the problem.One of the three boxes I have using this new idle driver, when suppressing ARAT detection, actually exhibits intermittent (but frequent) hangs, so I apparently now have found a way to debug what''s going on. I''ll send a patch in a minute disabling the feature by default when ARAT isn''t there. Jan