* [xen-4.4-testing test] 33394: regressions - FAIL
@ 2015-01-13 20:30 xen.org
2015-01-14 9:12 ` Jan Beulich
0 siblings, 1 reply; 4+ messages in thread
From: xen.org @ 2015-01-13 20:30 UTC (permalink / raw)
To: xen-devel; +Cc: ian.jackson
flight 33394 xen-4.4-testing real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/33394/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-i386-xl-qemut-winxpsp3-vcpus1 5 xen-boot fail REGR. vs. 33292
test-amd64-i386-pair 17 guest-migrate/src_host/dst_host fail REGR. vs. 33292
Tests which did not succeed, but are not blocking:
test-amd64-amd64-rumpuserxen-amd64 1 build-check(1) blocked n/a
test-amd64-i386-rumpuserxen-i386 1 build-check(1) blocked n/a
test-amd64-i386-libvirt 9 guest-start fail never pass
test-armhf-armhf-libvirt 9 guest-start fail never pass
test-amd64-amd64-libvirt 9 guest-start fail never pass
test-armhf-armhf-xl 10 migrate-support-check fail never pass
test-amd64-amd64-xl-qemut-win7-amd64 14 guest-stop fail never pass
build-i386-rumpuserxen 6 xen-build fail never pass
test-amd64-i386-xl-win7-amd64 14 guest-stop fail never pass
build-amd64-rumpuserxen 6 xen-build fail never pass
test-amd64-amd64-xl-win7-amd64 14 guest-stop fail never pass
test-amd64-amd64-xl-winxpsp3 14 guest-stop fail never pass
test-amd64-amd64-xl-pcipt-intel 9 guest-start fail never pass
test-amd64-i386-xend-winxpsp3 17 leak-check/check fail never pass
test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 14 guest-stop fail never pass
test-amd64-amd64-xl-qemuu-winxpsp3 14 guest-stop fail never pass
test-amd64-amd64-xl-qemuu-win7-amd64 14 guest-stop fail never pass
test-amd64-i386-xl-qemuu-win7-amd64 14 guest-stop fail never pass
test-amd64-i386-xl-winxpsp3-vcpus1 14 guest-stop fail never pass
test-amd64-i386-xend-qemut-winxpsp3 17 leak-check/check fail never pass
test-amd64-amd64-xl-qemut-winxpsp3 14 guest-stop fail never pass
test-amd64-i386-xl-qemut-win7-amd64 14 guest-stop fail never pass
version targeted for testing:
xen 30f10d4d2b102bd7184b84c9cc3d2246f060706a
baseline version:
xen 089dd62211042011e26de1b87b558394cdfe388b
------------------------------------------------------------
People who touched revisions under test:
Ian Campbell <ian.campbell@citrix.com>
Ian Jackson <ian.jackson@eu.citrix.com>
Luis R. Rodriguez <mcgrof@suse.com>
Wei Liu <wei.liu2@citrix.com>
------------------------------------------------------------
jobs:
build-amd64-xend pass
build-i386-xend pass
build-amd64 pass
build-armhf pass
build-i386 pass
build-amd64-libvirt pass
build-armhf-libvirt pass
build-i386-libvirt pass
build-amd64-pvops pass
build-armhf-pvops pass
build-i386-pvops pass
build-amd64-rumpuserxen fail
build-i386-rumpuserxen fail
test-amd64-amd64-xl pass
test-armhf-armhf-xl pass
test-amd64-i386-xl pass
test-amd64-i386-rhel6hvm-amd pass
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 pass
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 blocked
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-amd64-amd64-xl-win7-amd64 fail
test-amd64-i386-xl-win7-amd64 fail
test-amd64-i386-xl-credit2 pass
test-amd64-i386-freebsd10-i386 pass
test-amd64-i386-rumpuserxen-i386 blocked
test-amd64-amd64-xl-pcipt-intel fail
test-amd64-i386-rhel6hvm-intel pass
test-amd64-i386-qemut-rhel6hvm-intel pass
test-amd64-i386-qemuu-rhel6hvm-intel pass
test-amd64-amd64-libvirt fail
test-armhf-armhf-libvirt fail
test-amd64-i386-libvirt fail
test-amd64-i386-xl-multivcpu pass
test-amd64-amd64-pair pass
test-amd64-i386-pair fail
test-amd64-amd64-xl-sedf-pin pass
test-amd64-amd64-pv pass
test-amd64-i386-pv pass
test-amd64-amd64-xl-sedf pass
test-amd64-i386-xl-qemut-winxpsp3-vcpus1 fail
test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 fail
test-amd64-i386-xl-winxpsp3-vcpus1 fail
test-amd64-i386-xend-qemut-winxpsp3 fail
test-amd64-amd64-xl-qemut-winxpsp3 fail
test-amd64-amd64-xl-qemuu-winxpsp3 fail
test-amd64-i386-xend-winxpsp3 fail
test-amd64-amd64-xl-winxpsp3 fail
------------------------------------------------------------
sg-report-flight on osstest.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 30f10d4d2b102bd7184b84c9cc3d2246f060706a
Author: Ian Campbell <ian.campbell@citrix.com>
Date: Thu Nov 6 13:00:31 2014 +0000
tools: libxl: do not leak diskpath during local disk attach
libxl__device_disk_local_initiate_attach is assigning dls->diskpath with a
strdup of the device path. This is then passed to the callback, e.g.
parse_bootloader_result but bootloader_cleanup will not free it.
Since the callback is within the scope of the (e)gc and therefore doesn't need
to be malloc'd, a gc'd alloc will do. All other assignments to this field use
the gc.
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=767295
Reported-by: Gedalya <gedalya@gedalya.net>
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
Acked-by: Wei Liu <wei.liu2@citrix.com>
(cherry picked from commit 379b351889a8f02abe30a06e2ce9ba8b381b91ab)
commit f328f0c82f88860ddcc1e443b989d46ddb61e905
Author: Ian Campbell <ian.campbell@citrix.com>
Date: Thu Nov 6 13:59:43 2014 +0000
tools: libxl: do not overrun input buffer in libxl__parse_mac
Valgrind reports:
==7971== Invalid read of size 1
==7971== at 0x40877BE: libxl__parse_mac (libxl_internal.c:288)
==7971== by 0x405C5F8: libxl__device_nic_from_xs_be (libxl.c:3405)
==7971== by 0x4065542: libxl__append_nic_list_of_type (libxl.c:3484)
==7971== by 0x4065542: libxl_device_nic_list (libxl.c:3504)
==7971== by 0x406F561: libxl_retrieve_domain_configuration (libxl.c:6661)
==7971== by 0x805671C: reload_domain_config (xl_cmdimpl.c:2037)
==7971== by 0x8057F30: handle_domain_death (xl_cmdimpl.c:2116)
==7971== by 0x8057F30: create_domain (xl_cmdimpl.c:2580)
==7971== by 0x805B4B2: main_create (xl_cmdimpl.c:4652)
==7971== by 0x804EAB2: main (xl.c:378)
This is because on the final iteration the tok += 3 skips over the terminating
NUL to the next byte, and then *tok reads it. Fix this by using endptr as the
iterator.
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Reviewed-by: Don Slutz <dslutz@verizon.com>
Acked-by: Wei Liu <wei.liu2@citrix.com>
(cherry picked from commit 5a430eca0b27354456d1245ed3f637d5f2e17883)
commit b12283059bf07c7833f26552d45509b05ea83b30
Author: Luis R. Rodriguez <mcgrof@suse.com>
Date: Tue May 20 05:37:35 2014 -0700
libxc: check return values on mmap() and madvise() on xc_alloc_hypercall_buffer()
On a Thinkpad T4440p with OpenSUSE tumbleweed with v3.15-rc4
and today's latest xen tip from the git tree strace -f reveals
we end up on a never ending wait shortly after
write(20, "backend/console/5\0", 18 <unfinished ...>
This is right before we just wait on the qemu process which we
had mmap'd for. Without this you'll end up getting stuck on a
loop if mmap() worked but madvise() did not. While at it I noticed
even the mmap() error fail was not being checked, fix that too.
Signed-off-by: Luis R. Rodriguez <mcgrof@suse.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
(cherry picked from commit e86539a388314cd3dca88f5e69d7873343197cd8)
(qemu changes not included)
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [xen-4.4-testing test] 33394: regressions - FAIL
2015-01-13 20:30 [xen-4.4-testing test] 33394: regressions - FAIL xen.org
@ 2015-01-14 9:12 ` Jan Beulich
2015-01-14 9:52 ` Ian Campbell
0 siblings, 1 reply; 4+ messages in thread
From: Jan Beulich @ 2015-01-14 9:12 UTC (permalink / raw)
To: ian.jackson; +Cc: xen-devel
>>> On 13.01.15 at 21:30, <Ian.Jackson@eu.citrix.com> wrote:
> flight 33394 xen-4.4-testing real [real]
> http://www.chiark.greenend.org.uk/~xensrcts/logs/33394/
>
> Regressions :-(
>
> Tests which did not succeed and are blocking,
> including tests which could not be run:
> test-amd64-i386-xl-qemut-winxpsp3-vcpus1 5 xen-boot fail REGR. vs. 33292
In all recent xen-boot failures I looked at the boot process seems
stalled starting ntpd - is that perhaps infrastructure related?
> test-amd64-i386-pair 17 guest-migrate/src_host/dst_host fail REGR. vs. 33292
Both involved hosts appear to still be affected by the swiotlb issue
- wasn't that supposed to long be addressed?
Jan
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [xen-4.4-testing test] 33394: regressions - FAIL
2015-01-14 9:12 ` Jan Beulich
@ 2015-01-14 9:52 ` Ian Campbell
2015-01-14 12:00 ` David Vrabel
0 siblings, 1 reply; 4+ messages in thread
From: Ian Campbell @ 2015-01-14 9:52 UTC (permalink / raw)
To: Jan Beulich; +Cc: xen-devel, ian.jackson, David Vrabel
On Wed, 2015-01-14 at 09:12 +0000, Jan Beulich wrote:
> >>> On 13.01.15 at 21:30, <Ian.Jackson@eu.citrix.com> wrote:
> > flight 33394 xen-4.4-testing real [real]
> > http://www.chiark.greenend.org.uk/~xensrcts/logs/33394/
> >
> > Regressions :-(
> >
> > Tests which did not succeed and are blocking,
> > including tests which could not be run:
> > test-amd64-i386-xl-qemut-winxpsp3-vcpus1 5 xen-boot fail REGR. vs. 33292
>
> In all recent xen-boot failures I looked at the boot process seems
> stalled starting ntpd - is that perhaps infrastructure related?
That's not impossible, I'd suspect DNS related. Hopefully all this sort
of thing will be much better (or at least under our control) in the new
colo.
> > test-amd64-i386-pair 17 guest-migrate/src_host/dst_host fail REGR. vs. 33292
>
> Both involved hosts appear to still be affected by the swiotlb issue
> - wasn't that supposed to long be addressed?
The patches to increase the swiotlb size in osstest didn't help, I
think.
David V posted some patches upstream to fix the problem at the root, but
I don't remember seeing any responses from the upstream maintainers
(they touched some common and/or x86 code IIRC)
Ian.
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [xen-4.4-testing test] 33394: regressions - FAIL
2015-01-14 9:52 ` Ian Campbell
@ 2015-01-14 12:00 ` David Vrabel
0 siblings, 0 replies; 4+ messages in thread
From: David Vrabel @ 2015-01-14 12:00 UTC (permalink / raw)
To: Ian Campbell, Jan Beulich; +Cc: xen-devel, ian.jackson
On 14/01/15 09:52, Ian Campbell wrote:
> On Wed, 2015-01-14 at 09:12 +0000, Jan Beulich wrote:
>>>>> On 13.01.15 at 21:30, <Ian.Jackson@eu.citrix.com> wrote:
>>> flight 33394 xen-4.4-testing real [real]
>>> http://www.chiark.greenend.org.uk/~xensrcts/logs/33394/
>>>
>>> Regressions :-(
>>>
>>> Tests which did not succeed and are blocking,
>>> including tests which could not be run:
>>> test-amd64-i386-xl-qemut-winxpsp3-vcpus1 5 xen-boot fail REGR. vs. 33292
>>
>> In all recent xen-boot failures I looked at the boot process seems
>> stalled starting ntpd - is that perhaps infrastructure related?
>
> That's not impossible, I'd suspect DNS related. Hopefully all this sort
> of thing will be much better (or at least under our control) in the new
> colo.
>
>>> test-amd64-i386-pair 17 guest-migrate/src_host/dst_host fail REGR. vs. 33292
>>
>> Both involved hosts appear to still be affected by the swiotlb issue
>> - wasn't that supposed to long be addressed?
>
> The patches to increase the swiotlb size in osstest didn't help, I
> think.
>
> David V posted some patches upstream to fix the problem at the root, but
> I don't remember seeing any responses from the upstream maintainers
> (they touched some common and/or x86 code IIRC)
There are two main users of the swiotlb.
1. The mptsas driver incorrectly setting the DMA mask based on max_pfn.
The series I posted addresses this. But after only 1 (rude) response
from the relevant maintainers in 5 different versions of this series I
have no wish to pursue this further.
Someone else will need to pick it up if they care.
You can work around this by giving more than 4 GiB of PFN space to dom0
(e.g, dom0_mem=2G,max:4G would work).
2. > 4k buffers (from block I/O or network packets using compound pages.
This is only a problem with debug builds of Xen where pages are
deliberately allocated in reverse order. In non-debug builds this is
much less of a problem (most of dom0's memory ends up being machine
contiguous).
Our (XenServer's) long term plan is to introduce the PV IOMMU support to
make bus addresses contiguous. Malcolm will be able to advise on what
work remains if you wish to pick this up.
David
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2015-01-14 12:01 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2015-01-13 20:30 [xen-4.4-testing test] 33394: regressions - FAIL xen.org
2015-01-14 9:12 ` Jan Beulich
2015-01-14 9:52 ` Ian Campbell
2015-01-14 12:00 ` David Vrabel
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.