|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [Xen-devel] [xen-unstable test] 30308: regressions - FAIL
flight 30308 xen-unstable real [real] http://www.chiark.greenend.org.uk/~xensrcts/logs/30308/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-xl-qemuu-win7-amd64 5 xen-boot fail REGR. vs. 30301 test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 9 guest-saverestore fail REGR. vs. 30301 Tests which did not succeed, but are not blocking: test-armhf-armhf-libvirt 9 guest-start fail never pass test-amd64-i386-libvirt 9 guest-start fail never pass test-amd64-amd64-xl-pcipt-intel 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-i386-xl-qemut-winxpsp3 14 guest-stop fail never pass test-amd64-i386-xl-qemuu-winxpsp3 14 guest-stop fail never pass test-amd64-i386-xl-qemut-winxpsp3-vcpus1 14 guest-stop fail never pass test-amd64-amd64-xl-qemut-win7-amd64 14 guest-stop fail never pass test-amd64-amd64-xl-qemuu-win7-amd64 14 guest-stop fail never pass test-amd64-i386-xl-qemut-win7-amd64 14 guest-stop fail never pass test-amd64-i386-xl-win7-amd64 14 guest-stop fail never pass test-amd64-amd64-xl-qemut-winxpsp3 14 guest-stop fail never pass test-amd64-amd64-xl-winxpsp3 14 guest-stop fail never pass test-amd64-i386-xl-winxpsp3-vcpus1 14 guest-stop fail never pass test-amd64-i386-xl-winxpsp3 14 guest-stop fail never pass test-amd64-amd64-xl-win7-amd64 14 guest-stop fail never pass test-amd64-amd64-xl-qemuu-winxpsp3 14 guest-stop fail never pass version targeted for testing: xen f8315ea4f0657dcd7f0bc5bec1328c522b0ceb83 baseline version: xen 72af6f455ac6afcd46d9a556f90349f2397507e8 ------------------------------------------------------------ People who touched revisions under test: Ian Campbell <ian.campbell@xxxxxxxxxx> Wei Liu <wei.liu2@xxxxxxxxxx> ------------------------------------------------------------ jobs: 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-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 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-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 pass 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 pass test-amd64-amd64-xl-sedf-pin 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-amd64-xl-qemut-winxpsp3 fail test-amd64-i386-xl-qemut-winxpsp3 fail test-amd64-amd64-xl-qemuu-winxpsp3 fail test-amd64-i386-xl-qemuu-winxpsp3 fail test-amd64-amd64-xl-winxpsp3 fail test-amd64-i386-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 f8315ea4f0657dcd7f0bc5bec1328c522b0ceb83 Merge: 5fc4efc 72af6f4 Author: Ian Campbell <ian.campbell@xxxxxxxxxx> Date: Wed Sep 17 20:15:28 2014 +0100 Merge branch 'staging' of ssh://xenbits.xen.org/home/xen/git/xen into staging commit 5fc4efcd3defde429bb048f89decb2ffd96d1c11 Author: Wei Liu <wei.liu2@xxxxxxxxxx> Date: Tue Sep 16 11:01:18 2014 +0100 xl: long output of "list" command now contains Dom0 information As we've already generated a JSON config for Dom0, print that out when requested. Signed-off-by: Wei Liu <wei.liu2@xxxxxxxxxx> Acked-by: Ian Campbell <ian.campbell@xxxxxxxxxx> commit e6afc7063afe06f4609fb2d18fde28f3b54e995e Author: Wei Liu <wei.liu2@xxxxxxxxxx> Date: Tue Sep 16 11:01:17 2014 +0100 xl: use libxl_retrieve_domain_configuration and JSON format Before this change, xl stores domain configuration in "xl" format, which is in fact a verbatim copy of user supplied domain config. Now libxl provides a new API to retrieve domain configuration, switch to that new API, store configuration in JSON format. Tests done so far (xl.{new,old} denotes xl with{,out} "libxl-json" support): 1. xl.new create then xl.new save, hexdump saved file: domain config saved in JSON format 2. xl.new create, xl.new save then xl.old restore: failed on mandatory flag check 3. xl.new create, xl.new save then xl.new restore: succeeded 4. xl.old create, xl.old save then xl.new restore: succeeded 5. xl.new create then local migrate, receiving end xl.new: succeeded 6. xl.old create then local migrate, receiving end xl.new: succeeded Note that "xl" config is still supported and handled when restarting a domain. "xl" config file takes precedence over "libxl-json" in that case, so that user who uses "config-update" to store new config file won't have regression. All other scenarios (migration, domain listing etc.) now use the new API. Lastly, print out warning when users invoke "config-update" to discourage them from using this command. Signed-off-by: Wei Liu <wei.liu2@xxxxxxxxxx> Acked-by: Ian Campbell <ian.campbell@xxxxxxxxxx> commit 12ebbe2bae28c0e170e76f61ade65b980ae36b55 Author: Wei Liu <wei.liu2@xxxxxxxxxx> Date: Tue Sep 16 11:01:16 2014 +0100 libxl: introduce libxl_userdata_unlink This will be used in later patch for xl to remove its "xl" userdata file. Both CTX lock and userdata lock are taken in this API. CTX lock is taken to maintain locking hierarchy, but it also has a side effect to protect against R-M-W by other threads. Userdata lock is used to protect against domain destruction. In general application should not rely on these internal locks to protect its own userdata files. It should deploys its own lock if it cares. Signed-off-by: Wei Liu <wei.liu2@xxxxxxxxxx> Acked-by: Ian Campbell <ian.campbell@xxxxxxxxxx> commit 9d5550ffc56e72a40c231cead3594403405f2e7e Author: Wei Liu <wei.liu2@xxxxxxxxxx> Date: Tue Sep 16 11:01:15 2014 +0100 libxl: introduce libxl_retrieve_domain_configuration Introduce a new public API to return domain configuration. This returned configuration can be used to rebuild a domain. Note that this configuration only describes the configuration necessary to reproduce the guest visible state and does not necessarily include specific decisions made by the toolstack regarding its current incarnation (e.g. disk backend) unless they were specified by the application when the domain was created. With this approach we can preserve what user has provided in the original configuration as well as valuable information from xenstore. Signed-off-by: Wei Liu <wei.liu2@xxxxxxxxxx> Acked-by: Ian Campbell <ian.campbell@xxxxxxxxxx> commit 6c0e7d1032363beb308c8ad11ce6c107cf047e26 Author: Wei Liu <wei.liu2@xxxxxxxxxx> Date: Tue Sep 16 11:01:14 2014 +0100 libxl: refactor libxl_get_memory_target Introduce a helper function which can return both "target" node and "static-max" node of a domain. Reimplement libxl_get_memory_target using this helper. libxl__fill_dom0_memory_info is adjusted as well. This helper will be used in later patch. Signed-off-by: Wei Liu <wei.liu2@xxxxxxxxxx> Acked-by: Ian Campbell <ian.campbell@xxxxxxxxxx> commit 577314768b430107845023d7e489ed0dd53892ad Author: Wei Liu <wei.liu2@xxxxxxxxxx> Date: Tue Sep 16 11:01:13 2014 +0100 libxl: make libxl_cd_insert "eject" + "insert" We introduce an intermediate empty state when inserting media into CDROM. The scheme works like this: lock json config write empty state to xenstore for (;;) { write user supplied disk to JSON write disk information to xenstore } unlock json config Bear in mind that all steps can fail. With the proposed scheme, we now know, if xenstore is empty, then CDROM should be considered empty; otherwise we should use JSON version of CDROM configuration. Signed-off-by: Wei Liu <wei.liu2@xxxxxxxxxx> Acked-by: Ian Campbell <ian.campbell@xxxxxxxxxx> commit 4197d3abbb3055d3798254eb7ba239bfb5824360 Author: Wei Liu <wei.liu2@xxxxxxxxxx> Date: Tue Sep 16 11:01:12 2014 +0100 libxl: synchronise configuration when we hotplug a device We update JSON version first, then write to xenstore, so that we maintain the following invariant: any device which is present in xenstore has a corresponding entry in JSON. The workflow is as followed: lock json config read json config update in-memory json config with new entry, replacing any stale entry for loop open xs transaction check device existence, abort if it exists write in-memory json config to disk commit xs transaction end for loop unlock json config Please see comment in libxl_internal.h for correctness proof. As those routines are called both during domain creation and device hotplug, we add a flag to indicate whether we need to update JSON config. This flag is only set to true when we hotplug a device. We cannot update JSON config during domain creation as JSON config is committed to disk only when domain creation finishes. Signed-off-by: Wei Liu <wei.liu2@xxxxxxxxxx> Acked-by: Ian Campbell <ian.campbell@xxxxxxxxxx> commit a788fe0cd8bcb51ef167fc451f837066362d8c82 Author: Wei Liu <wei.liu2@xxxxxxxxxx> Date: Tue Sep 16 11:01:11 2014 +0100 libxl: rework domain userdata file lock The lock introduced in d2cd9d4f ("libxl: functions to lock / unlock libxl userdata store") has a bug that can leak the lock file when domain destruction races with other functions that try to get hold of the lock. There are several issues: 1. The lock is released too early with libxl__userdata_destroyall deletes everything in userdata store, including the lock file. 2. The check of domain existence is only done at the beginning of lock function, by the time the lock is acquired, the domain might have been gone already. The effect of this two issues is we can run into such situation: Process 1 Process 2 domain destruction # LOCK FUNCTION # LOCK FUNCTION check domain existence check domain existence acquire lock (file created) # LOCK FUNCTION destroy all files (lock file deleted, lock released) acquire lock (file created) # LOCK FUNCTION destroy domain # UNLOCK (close fd only) [ lock file leaked ] Fix this problem by deploying following changes: 1. Unlink lock file in unlock function. 2. Modify libxl__userdata_destroyall to not delete domain-userdata-lock, so that the lock remains held until unlock function is called. 3. Check domain still exists when the lock is acquired, unlock if domain is already gone. Signed-off-by: Wei Liu <wei.liu2@xxxxxxxxxx> Acked-by: Ian Campbell <ian.campbell@xxxxxxxxxx> (qemu changes not included) _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
 |
Lists.xenproject.org is hosted with RackSpace, monitoring our |