|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [Xen-devel] [libvirt test] 112310: regressions - trouble: blocked/broken/fail/pass
flight 112310 libvirt real [real] http://logs.test-lab.xenproject.org/osstest/logs/112310/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: build-arm64-pvops 4 host-install(4) broken REGR. vs. 112276 build-arm64 4 host-install(4) broken REGR. vs. 112276 build-arm64-xsm 4 host-install(4) broken REGR. vs. 112276 build-i386-pvops 6 kernel-build fail REGR. vs. 112276 Tests which did not succeed, but are not blocking: test-arm64-arm64-libvirt-xsm 1 build-check(1) blocked n/a test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a build-arm64-libvirt 1 build-check(1) blocked n/a test-arm64-arm64-libvirt-qcow2 1 build-check(1) blocked n/a test-amd64-i386-libvirt 1 build-check(1) blocked n/a test-arm64-arm64-libvirt 1 build-check(1) blocked n/a test-amd64-i386-libvirt-xsm 1 build-check(1) blocked n/a test-amd64-i386-libvirt-pair 1 build-check(1) blocked n/a test-armhf-armhf-libvirt 14 saverestore-support-check fail like 112276 test-armhf-armhf-libvirt-xsm 14 saverestore-support-check fail like 112276 test-armhf-armhf-libvirt-raw 13 saverestore-support-check fail like 112276 test-amd64-amd64-libvirt-xsm 13 migrate-support-check fail never pass test-amd64-amd64-libvirt 13 migrate-support-check fail never pass test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass test-amd64-amd64-libvirt-vhd 12 migrate-support-check fail never pass test-armhf-armhf-libvirt 13 migrate-support-check fail never pass test-armhf-armhf-libvirt-xsm 13 migrate-support-check fail never pass test-armhf-armhf-libvirt-raw 12 migrate-support-check fail never pass version targeted for testing: libvirt cc1329b62759e7fc6a5a34ca18b5c072693aa3eb baseline version: libvirt f7237d63e8f02f3689f9b63b413fae7d4221faa9 Last test of basis 112276 2017-07-25 04:21:09 Z 1 days Testing same since 112310 2017-07-26 04:21:38 Z 0 days 1 attempts ------------------------------------------------------------ People who touched revisions under test: Andrea Bolognani <abologna@xxxxxxxxxx> John Ferlan <jferlan@xxxxxxxxxx> Martin Kletzander <mkletzan@xxxxxxxxxx> Michal Privoznik <mprivozn@xxxxxxxxxx> Pavel Hrdina <phrdina@xxxxxxxxxx> Scott Garfinkle <seg@xxxxxxxxxx> jobs: build-amd64-xsm pass build-arm64-xsm broken build-armhf-xsm pass build-i386-xsm pass build-amd64 pass build-arm64 broken build-armhf pass build-i386 pass build-amd64-libvirt pass build-arm64-libvirt blocked build-armhf-libvirt pass build-i386-libvirt pass build-amd64-pvops pass build-arm64-pvops broken build-armhf-pvops pass build-i386-pvops fail test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm pass test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm blocked test-amd64-amd64-libvirt-xsm pass test-arm64-arm64-libvirt-xsm blocked test-armhf-armhf-libvirt-xsm pass test-amd64-i386-libvirt-xsm blocked test-amd64-amd64-libvirt pass test-arm64-arm64-libvirt blocked test-armhf-armhf-libvirt pass test-amd64-i386-libvirt blocked test-amd64-amd64-libvirt-pair pass test-amd64-i386-libvirt-pair blocked test-arm64-arm64-libvirt-qcow2 blocked test-armhf-armhf-libvirt-raw pass test-amd64-amd64-libvirt-vhd 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 broken-step build-arm64-pvops host-install(4) broken-step build-arm64 host-install(4) broken-step build-arm64-xsm host-install(4) Not pushing. ------------------------------------------------------------ commit cc1329b62759e7fc6a5a34ca18b5c072693aa3eb Author: Pavel Hrdina <phrdina@xxxxxxxxxx> Date: Tue Jul 25 23:10:00 2017 +0200 qemu: we prefer C89 comment styles over C99 Introduced by commit 'a7bc2c8cfd6f'. Signed-off-by: Pavel Hrdina <phrdina@xxxxxxxxxx> commit a7bc2c8cfd6f13f7b3f8fcb793fee04b39473788 Author: Scott Garfinkle <seg@xxxxxxxxxx> Date: Tue Jul 25 09:33:50 2017 -0500 Generate unique socket file It's possible to have more than one unnamed virtio-serial unix channel. We need to generate a unique name for each channel. Currently, we use ".../unknown.sock" for all of them. Better practice would be to specify an explicit target path name; however, in the absence of that, we need uniqueness in the names we generate internally. Before the changes we'd get /var/lib/libvirt/qemu/channel/target/unknown.sock for each instance of <channel type='unix'> <source mode='bind'/> <target type='virtio'/> </channel> Now, we get vioser-00-00-01.sock, vioser-00-00-02.sock, etc. Signed-off-by: Scott Garfinkle <seg@xxxxxxxxxx> commit eaf2c9f89107b9f60cf8db2c919f78b987ff7177 Author: Martin Kletzander <mkletzan@xxxxxxxxxx> Date: Fri Jul 21 15:51:03 2017 +0200 Move machineName generation from virsystemd into domain_conf It is more related to a domain as we might use it even when there is no systemd and it does not use any dbus/systemd functions. In order not to use code from conf/ in util/ pass machineName in cgroups code as a parameter. That also fixes a leak of machineName in the lxc driver and cleans up and de-duplicates some code. Signed-off-by: Martin Kletzander <mkletzan@xxxxxxxxxx> commit aa0dfb91d547e4020018e77fd3211e35c6311de9 Author: Martin Kletzander <mkletzan@xxxxxxxxxx> Date: Fri Jul 21 15:56:46 2017 +0200 lxc: Make lxcProcessStop callable even without PID being available This way the function can work as a central point of clean-up code and we don't have to duplicate code. And it works similarly to the qemu driver. Signed-off-by: Martin Kletzander <mkletzan@xxxxxxxxxx> commit 2e6ecba1bcac898e1714db423cf3549c0d5f1ce0 Author: Martin Kletzander <mkletzan@xxxxxxxxxx> Date: Fri Jul 21 15:46:56 2017 +0200 qemu: Save qemu driver in qemuDomainObjPrivateData This way we can finally make it static and not use any externs anywhere. Signed-off-by: Martin Kletzander <mkletzan@xxxxxxxxxx> commit 6e6faf6d627d5ea291d9ff2378f7d1eb59e1d14e Author: Martin Kletzander <mkletzan@xxxxxxxxxx> Date: Fri Jul 21 15:29:00 2017 +0200 conf: Pass config.priv to xmlopt->privateData.alloc This will help us to get to some data more easily. Signed-off-by: Martin Kletzander <mkletzan@xxxxxxxxxx> commit 867bcc9c783cc07fc73413028a13ebf449cfb9d1 Author: John Ferlan <jferlan@xxxxxxxxxx> Date: Thu Jun 1 12:43:06 2017 -0400 secret: Handle object list removal and deletion properly Rather than rely on virSecretObjEndAPI to make the final virObjectUnref after the call to virSecretObjListRemove, be more explicit by calling virObjectUnref and setting @obj to NULL for secretUndefine and in the error path of secretDefineXML. Calling EndAPI will end up calling Unlock on an already unlocked object which has indeteriminate results (usually an ignored error). The virSecretObjEndAPI will both Unref and Unlock the object; however, the virSecretObjListRemove would have already Unlock'd the object so calling Unlock again is incorrect. Once the virSecretObjListRemove is called all that's left is to Unref our interest since that's the corrollary to the virSecretObjListAdd which returned our ref interest plus references for each hash table in which the object resides. In math terms, after an Add there's 2 refs on the object (1 for the object and 1 for the list). After calling Remove there's just 1 ref on the object. For the Add callers, calling EndAPI removes the ref for the object and unlocks it, but since it's in a list the other 1 remains. Signed-off-by: John Ferlan <jferlan@xxxxxxxxxx> commit d04bc0278d25f41272318ba72f11011874472481 Author: John Ferlan <jferlan@xxxxxxxxxx> Date: Tue Jul 25 09:02:09 2017 -0400 secret: Fix memory leak in virSecretLoad If the virSecretLoadValue fails, the code jumped to cleanup without setting @ret = obj, thus calling virSecretObjListRemove which only accounts for the object reference related to adding the object to the list during virSecretObjListAdd, but does not account for the reference to the object itself as the return of @ret would be NULL so the caller wouldn't call virSecretObjEndAPI on the object recently added thus reducing the refcnt to zero. This patch will perform the ObjListRemove in the failure path of virSecretLoadValue and Unref @obj in order to perform clean up and return @obj as NULL. The @def will be freed as part of the virObjectUnref. commit e4c0aff21514230f2f15aa5c7083219e1033f048 Author: John Ferlan <jferlan@xxxxxxxxxx> Date: Thu Jun 1 08:17:52 2017 -0400 secret: Properly handle @def after virSecretObjAdd in driver Since the virSecretObjListAdd technically consumes @def on success, the secretDefineXML should set @def = NULL immediately and process the remaining calls using a new @objDef variable. We can use use VIR_STEAL_PTR since we know the Add function just stores @def in obj->def. Because we steal @def into @objDef, if we jump to restore_backup: and @backup is set, then we need to ensure the @def would be free'd properly, so we'll steal it back from @objDef. For the other condition this fixes a double free of @def if the code had jumped to @backup == NULL thus calling virSecretObjListRemove without setting @def = NULL. In this case, the subsequent call to DefFree would succeed and free @def; however, the call to EndAPI would also call DefFree because the Unref done would be the last one for the @obj meaning the obj->def would be used to call DefFree, but it's already been free'd because @def wasn't managed right within this error path. Signed-off-by: John Ferlan <jferlan@xxxxxxxxxx> commit 7ca17da9f2f645398ea1315ce41b0a005651a02d Author: John Ferlan <jferlan@xxxxxxxxxx> Date: Wed May 31 15:11:28 2017 -0400 secret: Remove need for local configFile and base64File in ObjectAdd Rather than assign to a local variable, let's just assign directly to the object using the error path for cleanup. Signed-off-by: John Ferlan <jferlan@xxxxxxxxxx> commit 2d3c7122c88626d8f27fc72d77819469369016cc Author: Michal Privoznik <mprivozn@xxxxxxxxxx> Date: Tue Jul 25 10:31:54 2017 +0200 Revert "virthread: Introduce virRWLockInitPreferWriter" This reverts commit 328bd24443d2a345a5832ee48ebba0208f8036ea. As it turns out, this is not portable and very Linux & glibc specific. Worse, this may lead to not starving writers on Linux but everywhere else. Revert this and if the starvation occurs resolve it. Signed-off-by: Michal Privoznik <mprivozn@xxxxxxxxxx> Reviewed-by: Daniel P. Berrange <berrange@xxxxxxxxxx> commit bbda2883c43306874ea22fb48534091ecb6faf7b Author: Andrea Bolognani <abologna@xxxxxxxxxx> Date: Mon Jul 24 13:26:57 2017 +0200 conf: Rename virDomainControllerIsPCIHostBridge() to IsPSeriesPHB() The original name didn't hint at the fact that PHBs are a pSeries-specific concept. Suggested-by: Peter Krempa <pkrempa@xxxxxxxxxx> Signed-off-by: Andrea Bolognani <abologna@xxxxxxxxxx> commit 9b45cd8fab1c7d7d07dd3ae64970b3c93b78e04c Author: Andrea Bolognani <abologna@xxxxxxxxxx> Date: Wed Jul 19 10:37:04 2017 +0200 conf: Fix backwards migration of pSeries guests Recent commits made it so that pci-root controllers for pSeries guests are automatically assigned the spapr-pci-host-bridge model name; however, that prevents guests to migrate to older versions of libvirt which don't know about that model name at all, which at the moment is all of them :) To avoid the issue, just strip the model name from PHBs when formatting the migratable XML; guests that use more than one PHB are not going to be migratable anyway. Signed-off-by: Andrea Bolognani <abologna@xxxxxxxxxx> _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx https://lists.xen.org/xen-devel
|
 |
Lists.xenproject.org is hosted with RackSpace, monitoring our |