|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [Xen-devel] [ovmf test] 94773: regressions - FAIL
flight 94773 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/94773/ Regressions :-( Tests which did not succeed and are blocking, including tests which could not be run: test-amd64-i386-xl-qemuu-ovmf-amd64 17 guest-start/debianhvm.repeat fail REGR. vs. 94748 test-amd64-amd64-xl-qemuu-ovmf-amd64 17 guest-start/debianhvm.repeat fail REGR. vs. 94748 version targeted for testing: ovmf 855743f7177459bea95798e59b6b18dab867710c baseline version: ovmf dc99315b8732b6e3032d01319d3f534d440b43d0 Last test of basis 94748 2016-05-24 22:43:25 Z 1 days Failing since 94750 2016-05-25 03:43:08 Z 0 days 4 attempts Testing same since 94773 2016-05-25 19:44:42 Z 0 days 1 attempts ------------------------------------------------------------ People who touched revisions under test: Dandan Bi <dandan.bi@xxxxxxxxx> Hao Wu <hao.a.wu@xxxxxxxxx> Laszlo Ersek <lersek@xxxxxxxxxx> Marvin H?user <Marvin.Haeuser@xxxxxxxxxxx> Marvin Haeuser <Marvin.Haeuser@xxxxxxxxxxx> Yonghong Zhu <yonghong.zhu@xxxxxxxxx> jobs: build-amd64-xsm pass build-i386-xsm pass build-amd64 pass build-i386 pass build-amd64-libvirt pass build-i386-libvirt pass build-amd64-pvops pass build-i386-pvops pass test-amd64-amd64-xl-qemuu-ovmf-amd64 fail test-amd64-i386-xl-qemuu-ovmf-amd64 fail ------------------------------------------------------------ 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 Not pushing. ------------------------------------------------------------ commit 855743f7177459bea95798e59b6b18dab867710c Author: Laszlo Ersek <lersek@xxxxxxxxxx> Date: Wed May 18 20:13:41 2016 +0200 OvmfPkg: prevent 64-bit MMIO BAR degradation if there is no CSM According to edk2 commit "MdeModulePkg/PciBus: do not improperly degrade resource" and to the EFI_INCOMPATIBLE_PCI_DEVICE_SUPPORT_PROTOCOL definition in the Platform Init 1.4a specification, a platform can provide such a protocol in order to influence the PCI resource allocation performed by the PCI Bus driver. In particular it is possible instruct the PCI Bus driver, with a "wildcard" hint, to allocate the 64-bit MMIO BARs of a device in 64-bit address space, regardless of whether the device features an option ROM. (By default, the PCI Bus driver considers an option ROM reason enough for allocating the 64-bit MMIO BARs in 32-bit address space. It cannot know if BDS will launch a legacy boot option, and under legacy boot, a legacy BIOS binary from a combined option ROM could be dispatched, and fail to access MMIO BARs in 64-bit address space.) In platform code we can ascertain whether a CSM is present or not. If not, then legacy BIOS binaries in option ROMs can't be dispatched, hence the BAR degradation is detrimental, and we should prevent it. This is expected to conserve the 32-bit address space for 32-bit MMIO BARs. The driver added in this patch could be simplified based on the following facts: - In the Ia32 build, the 64-bit MMIO aperture is always zero-size, hence the driver will exit immediately. Therefore the driver could be omitted from the Ia32 build. - In the Ia32X64 and X64 builds, the driver could be omitted if CSM_ENABLE was defined (because in that case the degradation would be justified). On the other hand, if CSM_ENABLE was undefined, then the driver could be included, and it could provide the hint unconditionally (without looking for the Legacy BIOS protocol). These short-cuts are not taken because they would increase the differences between the OVMF DSC/FDF files. If we can manage without extreme complexity, we should use dynamic logic (vs. build time configuration), plus keep conditional compilation to a minimum. Cc: Jordan Justen <jordan.l.justen@xxxxxxxxx> Cc: Ruiyu Ni <ruiyu.ni@xxxxxxxxx> Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@xxxxxxxxxx> Reviewed-by: Ruiyu Ni <ruiyu.ni@xxxxxxxxx> Reviewed-by: Jordan Justen <jordan.l.justen@xxxxxxxxx> commit d85c5e31ed2b550dd801f82e4ddb5f7583332098 Author: Laszlo Ersek <lersek@xxxxxxxxxx> Date: Tue May 17 19:30:24 2016 +0200 OvmfPkg, ArmVirtPkg: rename QemuNewBootOrderLib to QemuBootOrderLib This completes the transition to the new BDS. The FILE_GUID in "QemuBootOrderLib.inf" is intentionally not changed. Cc: Ard Biesheuvel <ard.biesheuvel@xxxxxxxxxx> Cc: Gary Ching-Pang Lin <glin@xxxxxxxx> Cc: Jordan Justen <jordan.l.justen@xxxxxxxxx> Cc: Ruiyu Ni <ruiyu.ni@xxxxxxxxx> Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@xxxxxxxxxx> Reviewed-by: Ard Biesheuvel <ard.biesheuvel@xxxxxxxxxx> Reviewed-by: Jordan Justen <jordan.l.justen@xxxxxxxxx> commit 2542feea2ecd4dc73ee54cb32c875839413eed05 Author: Laszlo Ersek <lersek@xxxxxxxxxx> Date: Tue May 17 19:22:17 2016 +0200 OvmfPkg, ArmVirtPkg: clean up SetBootOrderFromQemu() parameter list With OvmfPkg's original QemuBootOrderLib (and USE_OLD_BDS) gone, we no longer need the BootOptionList parameter in the SetBootOrderFromQemu() prototype. Update the library class header file (including the function's documentation), and adapt the library instance and the call sites. Cc: Ard Biesheuvel <ard.biesheuvel@xxxxxxxxxx> Cc: Gary Ching-Pang Lin <glin@xxxxxxxx> Cc: Jordan Justen <jordan.l.justen@xxxxxxxxx> Cc: Ruiyu Ni <ruiyu.ni@xxxxxxxxx> Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@xxxxxxxxxx> Reviewed-by: Ard Biesheuvel <ard.biesheuvel@xxxxxxxxxx> Reviewed-by: Jordan Justen <jordan.l.justen@xxxxxxxxx> commit 35d3e9c5222304b2015566955a6c427016368793 Author: Laszlo Ersek <lersek@xxxxxxxxxx> Date: Tue May 17 18:52:49 2016 +0200 OvmfPkg: remove QemuBootOrderLib instance This library instance is no longer referenced. Cc: Ard Biesheuvel <ard.biesheuvel@xxxxxxxxxx> Cc: Gary Ching-Pang Lin <glin@xxxxxxxx> Cc: Jordan Justen <jordan.l.justen@xxxxxxxxx> Cc: Ruiyu Ni <ruiyu.ni@xxxxxxxxx> Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@xxxxxxxxxx> Reviewed-by: Jordan Justen <jordan.l.justen@xxxxxxxxx> commit c70c9bc39d7cc9e409b77c736020a65a632571c8 Author: Laszlo Ersek <lersek@xxxxxxxxxx> Date: Tue May 17 18:51:48 2016 +0200 OvmfPkg: remove PlatformBdsLib instance This library instance is no longer referenced. Cc: Ard Biesheuvel <ard.biesheuvel@xxxxxxxxxx> Cc: Gary Ching-Pang Lin <glin@xxxxxxxx> Cc: Jordan Justen <jordan.l.justen@xxxxxxxxx> Cc: Ruiyu Ni <ruiyu.ni@xxxxxxxxx> Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@xxxxxxxxxx> Reviewed-by: Jordan Justen <jordan.l.justen@xxxxxxxxx> commit dd43486577b35ea53794fd443d391e3d04143412 Author: Laszlo Ersek <lersek@xxxxxxxxxx> Date: Tue May 17 18:32:24 2016 +0200 OvmfPkg: remove USE_OLD_BDS build fallback macro Reasons: - USE_OLD_BDS requires duplicating updates between OVMF's library instances that depend on USE_OLD_BDS being FALSE vs. TRUE. Examples: d5aee61bfaaa OvmfPkg/QemuNewBootOrderLib: adapt Q35 SATA PMPN to UEFI spec Mantis 1353 1da761664949 OvmfPkg/QemuBootOrderLib: adapt Q35 SATA PMPN to UEFI spec Mantis 1353 - The Xen community has embraced the new BDS. Examples: 14b2ebc30c8b OvmfPkg/PlatformBootManagerLib: Postpone the shell registration 49effaf26ec9 OvmfPkg/PciHostBridgeLib: Scan for root bridges when running over Xen - OVMF doesn't build with "-D USE_OLD_BDS -D HTTP_BOOT_ENABLE" anyway, as NetworkPkg/HttpBootDxe now requires UefiBootManagerLib: 50a65824c74a NetworkPkg: Use UefiBootManagerLib API to create load option. We (correctly) don't resolve UefiBootManagerLib when USE_OLD_BDS is TRUE. - The new BDS has been working well; for example it's the only BDS available in ArmVirtPkg: 1946faa710e6 ArmVirtPkg/ArmVirtQemu: use MdeModulePkg/BDS Cc: Ard Biesheuvel <ard.biesheuvel@xxxxxxxxxx> Cc: Gary Ching-Pang Lin <glin@xxxxxxxx> Cc: Jordan Justen <jordan.l.justen@xxxxxxxxx> Cc: Ruiyu Ni <ruiyu.ni@xxxxxxxxx> Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@xxxxxxxxxx> Reviewed-by: Jordan Justen <jordan.l.justen@xxxxxxxxx> commit a27e904258b9e848d91cdf22e7c20e2131249cfb Author: Laszlo Ersek <lersek@xxxxxxxxxx> Date: Tue May 17 18:47:02 2016 +0200 OvmfPkg/README: refer to MdeModulePkg & PlatformBootManagerLib in examples The "UNIXGCC Debug" section happens to name PlatformBdsLib and IntelFrameworkModulePkg's BdsDxe as examples. OVMF will soon stop offering those even as a fallback option. Cc: Ard Biesheuvel <ard.biesheuvel@xxxxxxxxxx> Cc: Gary Ching-Pang Lin <glin@xxxxxxxx> Cc: Jordan Justen <jordan.l.justen@xxxxxxxxx> Cc: Ruiyu Ni <ruiyu.ni@xxxxxxxxx> Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@xxxxxxxxxx> Reviewed-by: Jordan Justen <jordan.l.justen@xxxxxxxxx> commit 8caa3caaed4b32d699b79c6d5aaa606b52d740e7 Author: Dandan Bi <dandan.bi@xxxxxxxxx> Date: Mon May 23 14:54:46 2016 +0800 MdeModulePkg: Make function comments and function match in UI codes Cc: Qiu Shumin <shumin.qiu@xxxxxxxxx> Cc: Eric Dong <eric.dong@xxxxxxxxx> Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Dandan Bi <dandan.bi@xxxxxxxxx> Reviewed-by: Qiu Shumin <shumin.qiu@xxxxxxxxx> commit 4b7345a7dd71bdc99a824facf55066838ec240da Author: Dandan Bi <dandan.bi@xxxxxxxxx> Date: Thu May 19 14:17:34 2016 +0800 MdeModulePkg/DisplayEngine: Fix memory leak issues in DisplayEngine The following codes are useless and cause memory leak issues. So now remove them. Cc: Cecil Sheng <cecil.sheng@xxxxxxx> Cc: Qiu Shumin <shumin.qiu@xxxxxxxxx> Cc: Eric Dong <eric.dong@xxxxxxxxx> Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Dandan Bi <dandan.bi@xxxxxxxxx> Reviewed-by: Eric Dong <eric.dong@xxxxxxxxx> commit e4979beee9e5d334d97fd8e2c79670ad08587bc6 Author: Yonghong Zhu <yonghong.zhu@xxxxxxxxx> Date: Fri May 6 15:20:23 2016 +0800 BaseTools/GenFds: enhance to get TOOL_CHAIN_TAG and TARGET value when user don't set TOOL_CHAIN_TAG and TARGET by â??D Flag, then GenFds would report failure for format: FILE DATA = $(OUTPUT_DIRECTORY)/$(TARGET)_$(TOOL_CHAIN_TAG)/testfile so this patch enhance to get the TOOL_CHAIN_TAG and TARGET value by following priority (high to low): 1. the Macro value set by -D Flag; 2. Get the value by the -t/-b option. 3. get the value from target.txt file. Besides, this patch also remove the error checking for missing -t/-b option. Cc: Liming Gao <liming.gao@xxxxxxxxx> Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Yonghong Zhu <yonghong.zhu@xxxxxxxxx> Reviewed-by: Liming Gao <liming.gao@xxxxxxxxx> commit 07fb9c264400d7ca2c14d3d8076102584038eb96 Author: Hao Wu <hao.a.wu@xxxxxxxxx> Date: Mon May 23 11:40:30 2016 +0800 MdeModulePkg RamDiskDxe: VALID_ARCH cleanup to list supported options Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Hao Wu <hao.a.wu@xxxxxxxxx> Reviewed-by: Feng Tian <feng.tian@xxxxxxxxx> commit bd3fc8133b2b17ad2e0427d1bf6b44b08cf2f3b2 Author: Marvin H?user <Marvin.Haeuser@xxxxxxxxxxx> Date: Fri May 20 03:04:02 2016 +0800 ShellPkg/App: Fix memory leak and save resources. 1) RunSplitCommand() allocates the initial SplitStdOut via CreateFileInterfaceMem(). Free SplitStdIn after the swap to fix the memory leak. 2) In RunSplitCommand(), SplitStdOut is checked for equality with StdIn. This cannot happen due to the if-check within the swap. Hence remove it. 3) UefiMain() doesn't free SplitList. Delete all list entries and reinitialize the list when in DEBUG. This does not include the CreateFileInterfaceMem()-allocated SplitStd mentioned in 1), so keep the ASSERT() until resolved. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Marvin Haeuser <Marvin.Haeuser@xxxxxxxxxxx> Reviewed-by: Qiu Shumin <shumin.qiu@xxxxxxxxx> _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
 |
Lists.xenproject.org is hosted with RackSpace, monitoring our |