|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [Xen-devel] [xen-unstable test] 8282: trouble: broken/fail/pass
flight 8282 xen-unstable real [real] http://www.chiark.greenend.org.uk/~xensrcts/logs/8282/ Failures and problems with tests :-( Tests which did not succeed and are blocking: test-amd64-i386-rhel6hvm-intel 3 host-install(3) broken test-amd64-amd64-win 3 host-install(3) broken test-amd64-i386-pv 3 host-install(3) broken test-amd64-i386-win 3 host-install(3) broken Tests which did not succeed, but are not blocking, including regressions (tests previously passed) regarded as allowable: test-amd64-amd64-xl-pcipt-intel 9 guest-start fail never pass test-amd64-i386-xl-multivcpu 5 xen-boot fail like 8256 test-amd64-amd64-xl 5 xen-boot fail like 8249 test-amd64-amd64-pv 5 xen-boot fail like 8244 test-amd64-i386-pair 8 xen-boot/dst_host fail like 8240 test-amd64-i386-pair 7 xen-boot/src_host fail like 8240 test-amd64-i386-xl-credit2 5 xen-boot fail like 8249 test-amd64-i386-rhel6hvm-amd 5 xen-boot fail like 8236 test-amd64-i386-win-vcpus1 16 leak-check/check fail never pass test-amd64-i386-xl 5 xen-boot fail like 8244 test-i386-i386-win 16 leak-check/check fail never pass test-i386-i386-pair 7 xen-boot/src_host fail like 8256 test-i386-i386-pair 8 xen-boot/dst_host fail like 8256 test-amd64-amd64-xl-win 13 guest-stop fail never pass test-amd64-i386-xl-win-vcpus1 5 xen-boot fail like 8244 test-i386-i386-xl-win 5 xen-boot fail like 8256 version targeted for testing: xen e8d1c8f074ba baseline version: xen 42edf1481c57 ------------------------------------------------------------ People who touched revisions under test: Bei Guan <gbtju85@xxxxxxxxx> Ian Campbell <ian.campbell@xxxxxxxxxx> Ian Jackson <ian.jackson@xxxxxxxxxxxxx> Jan Beulich <jbeulich@xxxxxxxxxx> Keir Fraser <keir@xxxxxxx> Liu, Jinsong <jinsong.liu@xxxxxxxxx> Olaf Hering <olaf@xxxxxxxxx> Roger Pau Monne <roger.pau@xxxxxxxxxxxxx> Tim Deegan <Tim.Deegan@xxxxxxxxxx> ------------------------------------------------------------ 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 fail test-amd64-i386-xl fail test-i386-i386-xl pass test-amd64-i386-rhel6hvm-amd fail test-amd64-i386-xl-credit2 fail test-amd64-amd64-xl-pcipt-intel fail test-amd64-i386-rhel6hvm-intel broken test-amd64-i386-xl-multivcpu fail test-amd64-amd64-pair pass test-amd64-i386-pair fail test-i386-i386-pair fail test-amd64-amd64-pv fail test-amd64-i386-pv broken test-i386-i386-pv pass test-amd64-i386-win-vcpus1 fail test-amd64-i386-xl-win-vcpus1 fail test-amd64-amd64-win broken test-amd64-i386-win broken test-i386-i386-win fail test-amd64-amd64-xl-win fail test-i386-i386-xl-win 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: 23749:e8d1c8f074ba tag: tip user: Jan Beulich <jbeulich@xxxxxxxxxx> date: Mon Jul 25 16:43:26 2011 +0100 x86-64/MMCFG: pass down firmware (ACPI) reservation status of used memory space Reserving the MMCFG address range(s) in E820 is specified to only be optional for the firmware to do. The requirement is to have them reserved in ACPI resources. Those, however, aren't directly visible to Xen as they require the ACPI interpreter to be active. Thus, if a range isn't reserved in E820, we should not completely disable use of MMCFG on the respective bus range, but rather keep it disabled until Dom0 can pass down information on the ACPI reservation status (though a new physdevop hypercall). Signed-off-by: Jan Beulich <jbeulich@xxxxxxxxxx> changeset: 23748:e1717d180897 user: Jan Beulich <jbeulich@xxxxxxxxxx> date: Mon Jul 25 16:42:53 2011 +0100 x86-64/MMCFG: finally make Fam10 enabling work Forcibly enabling the MMCFG space on AMD Fam10 CPUs cannot be expected to work since with the firmware not being aware of the address range used it cannot possibly reserve the space in E820 or ACPI resources. Hence we need to manually insert the range into the E820 table, and enable the range only when the insertion actually works without conflict. Further, the actual enabling of the space is done from identify_cpu(), which means that acpi_mmcfg_init() muts be called after that function (and hance should not be called from acpi_boot_init()). Otherwise, Dom0 would be able to use MMCFG, but Xen wouldn't. Signed-off-by: Jan Beulich <jbeulich@xxxxxxxxxx> changeset: 23747:b07b6fa76656 user: Jan Beulich <jbeulich@xxxxxxxxxx> date: Mon Jul 25 16:42:19 2011 +0100 x86-64/MMCFG: correct base address computation for regions not starting at bus 0 As per the specification, the base address reported by ACPI is the one that would be used if the region started at bus 0. Hence the start_bus_number offset needs to be added not only to the virtual address, but also the physical one when establishing the mapping, and it then needs to be subtracted when obtaining the virtual address for doing accesses. Signed-off-by: Jan Beulich <jbeulich@xxxxxxxxxx> changeset: 23746:aa54b8175954 user: Tim Deegan <Tim.Deegan@xxxxxxxxxx> date: Mon Jul 25 16:41:33 2011 +0100 VT-d: always clean up dpci timers. Message-ID: <20110718163848.GD18276@xxxxxxxxxxxxxxxxxxxxxxx> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) If a VM has all its PCI devices deassigned, need_iommu(d) becomes false but it might still have DPCI EOI timers that were init_timer()d but not yet kill_timer()d. That causes xen to crash later because the linked list of inactive timers gets corrupted, e.g.: (XEN) Xen call trace: (XEN) [<ffff82c480126256>] set_timer+0x1c2/0x24f (XEN) [<ffff82c48011fbf8>] schedule+0x129/0x5dd (XEN) [<ffff82c480122c1e>] __do_softirq+0x7e/0x89 (XEN) [<ffff82c480122c9d>] do_softirq+0x26/0x28 (XEN) [<ffff82c480153c85>] idle_loop+0x5a/0x5c (XEN) (XEN) (XEN) **************************************** (XEN) Panic on CPU 0: (XEN) Assertion 'entry->next->prev == entry' failed at /local/scratch/tdeegan/xen-unstable.hg/xen/include:172 (XEN) **************************************** The following patch makes sure that the domain destruction path always clears up the DPCI state even if !needs_iommu(d). Signed-off-by: Tim Deegan <Tim.Deegan@xxxxxxxxxx> changeset: 23745:9dbbf1631193 user: Keir Fraser <keir@xxxxxxx> date: Mon Jul 25 14:21:13 2011 +0100 hvmloader: Allow default response to be specified to xenstore_read(). Signed-off-by: Keir Fraser <keir@xxxxxxx> changeset: 23744:3244ff483d61 user: Keir Fraser <keir@xxxxxxx> date: Mon Jul 25 14:09:41 2011 +0100 hvmloader: Formatting cleanups. Signed-off-by: Keir Fraser <keir@xxxxxxx> changeset: 23743:360b31a5263c user: Keir Fraser <keir@xxxxxxx> date: Mon Jul 25 13:57:49 2011 +0100 hvmloader: Replace bios_relocate hook with bios_load hook Used by OVMF BIOS handler. Signed-off-by: Bei Guan <gbtju85@xxxxxxxxx> Signed-off-by: Keir Fraser <keir@xxxxxxx> changeset: 23742:50ddc200a60c user: Jan Beulich <jbeulich@xxxxxxxxxx> date: Mon Jul 25 13:48:08 2011 +0100 fix regression from c/s 23735:537918f518ee This was checking presence of the wrong (old) ELF note. I don't really understand how this failed consistently only for one of the xen-boot tests... Signed-off-by: Jan Beulich <jbeulich@xxxxxxxxxx> changeset: 23741:d8725d9fb865 user: Keir Fraser <keir@xxxxxxx> date: Sat Jul 23 09:57:04 2011 +0100 hvmloader: Declare get_hvm_info_table/get_shared_info as const funcs. The compiler can perform CSE on their call sites. Signed-off-by: Keir Fraser <keir@xxxxxxx> changeset: 23740:5f7dc61e166b user: Keir Fraser <keir@xxxxxxx> date: Sat Jul 23 09:56:13 2011 +0100 hvmloader: Remove bogus and unused RESERVED_MEMSIZE decl. Signed-off-by: Keir Fraser <keir@xxxxxxx> changeset: 23739:815ef5cf0261 user: Keir Fraser <keir@xxxxxxx> date: Sat Jul 23 09:43:47 2011 +0100 hvmloader: New functions mem_hole_alloc() and mem_hole_populate_ram(). These can be used by BIOS-specific handlers to set up memory regions as required by their firmware payload. Use mem_hole_alloc() to allocate properly reserved space for the shared-info-page mapping. The old location conflicts with space required for the OVMF BIOS (support for which is work in progress). Signed-off-by: Keir Fraser <keir@xxxxxxx> changeset: 23738:88847c424eec user: Roger Pau Monne <roger.pau@xxxxxxxxxxxxx> date: Sat Jul 23 08:58:37 2011 +0100 xend: remove PCI device listing from NetBSD, since it's Linux specific code. Signed-off-by: Roger Pau Monne <roger.pau@xxxxxxxxxxxxx> changeset: 23737:3d18ff6589e3 user: Liu, Jinsong <jinsong.liu@xxxxxxxxx> date: Sat Jul 23 08:56:58 2011 +0100 x86, mce: Dump mce log by ERST when mc panic We have implemented basic ERST logic before. Now linux3.0 as dom0 has included APEI logic. Hence it's time to add mce apei interface and enable APEI ERST feature. With it, it can save mce log by ERST method when mc panic. Signed-off-by: Liu, Jinsong <jinsong.liu@xxxxxxxxx> changeset: 23736:31683aa4bfb3 user: Liu, Jinsong <jinsong.liu@xxxxxxxxx> date: Sat Jul 23 08:55:59 2011 +0100 acpi: Add support for old and new bios erst, enable mce_apei logic When testing, we found different bios has different understanding about APEI ERST table header, depending on whether it count ACPI standard header or not. This patch add support for both bios version, and enable mce_apei. Signed-off-by: Liu, Jinsong <jinsong.liu@xxxxxxxxx> changeset: 23735:537918f518ee user: Jan Beulich <jbeulich@xxxxxxxxxx> date: Sat Jul 23 08:49:15 2011 +0100 add privileged (dom0) kernel feature indication With our switching away from supporting 32-bit Dom0 operation, users complained that attempts (perhaps due to lack of knowledge of that change) to boot the no longer privileged kernel in Dom0 resulted in apparently silent failure. To make the mismatch explicit and visible, add dom0 feature flag that the kernel can set to indicate operation as dom0 is supported. Due to the way elf_xen_parse_features() worked up to now (getting fixed here), adding features indications to the old, string based ELF note would make the respective kernel unusable on older hypervisors. For that reason, a new ELF Note is being introduced that allows specifying supported features as a bit array instead (with features unknown to the hypervisor simply ignored, as now also done by elf_xen_parse_features(), whereas here unknown kernel-required features still keep the kernel [and hence VM] from booting). Introduce and use elf_note_numeric_array() to be forward compatible (or else an old hypervisor wouldn't be able to parse kernel specified features occupying more than 64 bits - thanks, Ian!). Signed-off-by: Jan Beulich <jbeulich@xxxxxxxxxx> changeset: 23734:42edf1481c57 user: Ian Campbell <ian.campbell@xxxxxxxxxx> date: Fri Jul 22 08:55:19 2011 +0100 build: remove $(DESTDIR) from buildmakevars2file paths 23721:0ccb94d533d6 added this by mistake. Signed-off-by: Ian Campbell <ian.campbell@xxxxxxxxxx> ======================================== commit cd776ee9408ff127f934a707c1a339ee600bc127 Author: Ian Jackson <ian.jackson@xxxxxxxxxxxxx> Date: Tue Jun 28 13:50:53 2011 +0100 qemu-char.c: fix incorrect CONFIG_STUBDOM handling qemu-char.c:1123:7: warning: "CONFIG_STUBDOM" is not defined [-Wundef] Signed-off-by: Olaf Hering <olaf@xxxxxxxxx> Acked-by: Ian Jackson <ian.jackson@xxxxxxxxxxxxx> _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxx http://lists.xensource.com/xen-devel
|
 |
Lists.xenproject.org is hosted with RackSpace, monitoring our |