|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [Xen-devel] [ovmf baseline-only test] 74587: trouble: blocked/broken
This run is configured for baseline tests only. flight 74587 ovmf real [real] http://osstest.xs.citrite.net/~osstest/testlogs/logs/74587/ Failures and problems with tests :-( Tests which did not succeed and are blocking, including tests which could not be run: build-amd64-xsm <job status> broken build-i386 <job status> broken build-amd64-pvops <job status> broken build-i386-pvops <job status> broken build-i386-xsm <job status> broken build-amd64 <job status> broken Tests which did not succeed, but are not blocking: test-amd64-amd64-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a build-amd64-libvirt 1 build-check(1) blocked n/a test-amd64-i386-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a build-i386-libvirt 1 build-check(1) blocked n/a build-amd64 2 hosts-allocate broken baseline untested build-amd64-pvops 2 hosts-allocate broken baseline untested build-amd64-xsm 2 hosts-allocate broken baseline untested build-i386-pvops 2 hosts-allocate broken baseline untested build-i386-xsm 2 hosts-allocate broken baseline untested build-i386 2 hosts-allocate broken baseline untested build-amd64-xsm 3 capture-logs broken baseline untested build-amd64 3 capture-logs broken baseline untested build-i386 3 capture-logs broken baseline untested build-amd64-pvops 3 capture-logs broken baseline untested build-i386-xsm 3 capture-logs broken baseline untested build-i386-pvops 3 capture-logs broken baseline untested version targeted for testing: ovmf bf453d581ecff2a73128873fd714a07508e2ab11 baseline version: ovmf 153f5c7a93be09403891404c06e5b0e24eb019a3 Last test of basis 74584 2018-04-13 00:27:52 Z 0 days Testing same since 74587 2018-04-13 03:22:19 Z 0 days 1 attempts ------------------------------------------------------------ People who touched revisions under test: Laszlo Ersek <lersek@xxxxxxxxxx> Steve Capper <steve.capper@xxxxxxxxxx> jobs: build-amd64-xsm broken build-i386-xsm broken build-amd64 broken build-i386 broken build-amd64-libvirt blocked build-i386-libvirt blocked build-amd64-pvops broken build-i386-pvops broken test-amd64-amd64-xl-qemuu-ovmf-amd64 blocked test-amd64-i386-xl-qemuu-ovmf-amd64 blocked ------------------------------------------------------------ sg-report-flight on osstest.xs.citrite.net logs: /home/osstest/logs images: /home/osstest/images Logs, config files, etc. are available at http://osstest.xs.citrite.net/~osstest/testlogs/logs Test harness code can be found at http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary broken-job build-amd64-xsm broken broken-job build-i386 broken broken-job build-amd64-pvops broken broken-job build-i386-pvops broken broken-job build-i386-xsm broken broken-job build-amd64 broken broken-step build-amd64 hosts-allocate broken-step build-amd64-pvops hosts-allocate broken-step build-amd64-xsm hosts-allocate broken-step build-i386-pvops hosts-allocate broken-step build-i386-xsm hosts-allocate broken-step build-i386 hosts-allocate broken-step build-amd64-xsm capture-logs broken-step build-amd64 capture-logs broken-step build-i386 capture-logs broken-step build-amd64-pvops capture-logs broken-step build-i386-xsm capture-logs broken-step build-i386-pvops capture-logs Push not applicable. ------------------------------------------------------------ commit bf453d581ecff2a73128873fd714a07508e2ab11 Author: Laszlo Ersek <lersek@xxxxxxxxxx> Date: Wed Apr 11 23:07:59 2018 +0200 ArmVirtPkg/ArmVirtQemu: hook NvVarStoreFormattedLib into VariableRuntimeDxe In spite of both ArmVirtQemu and ArmVirtQemuKernel formatting the variable store template at build time, link NvVarStoreFormattedLib into VariableRuntimeDxe via NULL class resolution on both platforms. This lets us test the depexes implemented in the previous patches. Cc: Ard Biesheuvel <ard.biesheuvel@xxxxxxxxxx> Cc: Leif Lindholm <leif.lindholm@xxxxxxxxxx> Cc: Steve Capper <steve.capper@xxxxxxxxxx> Cc: Supreeth Venkatesh <Supreeth.Venkatesh@xxxxxxx> Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Laszlo Ersek <lersek@xxxxxxxxxx> Reviewed-by: Ard Biesheuvel <ard.biesheuvel@xxxxxxxxxx> commit 8f4833bb305453fb30b886fee96888c4bdedbaa7 Author: Laszlo Ersek <lersek@xxxxxxxxxx> Date: Thu Apr 12 01:37:21 2018 +0200 ArmVirtPkg/PlatformHasAcpiDtDxe: depend on gEfiVariableArchProtocolGuid PlatformHasAcpiDtDxe consumes the DynamicHii PCD called "gArmVirtTokenSpaceGuid.PcdForceNoAcpi". The PcdGetBool() library call terminates in gRT->GetVariable(), in the MdeModulePkg/Universal/PCD/Dxe driver. Put "gEfiVariableArchProtocolGuid" on PlatformHasAcpiDtDxe's DEPEX so that we not attempt the call before the PCD driver can successfully read non-volatile variables. Cc: Ard Biesheuvel <ard.biesheuvel@xxxxxxxxxx> Cc: Leif Lindholm <leif.lindholm@xxxxxxxxxx> Cc: Steve Capper <steve.capper@xxxxxxxxxx> Cc: Supreeth Venkatesh <Supreeth.Venkatesh@xxxxxxx> Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Laszlo Ersek <lersek@xxxxxxxxxx> Reviewed-by: Ard Biesheuvel <ard.biesheuvel@xxxxxxxxxx> Reviewed-by: Leif Lindholm <leif.lindholm@xxxxxxxxxx> commit 221c4f626f357ed9fa5e5133514b339d5378a782 Author: Laszlo Ersek <lersek@xxxxxxxxxx> Date: Thu Apr 12 02:00:13 2018 +0200 ArmPlatformPkg/PL031RealTimeClockLib: depend on gEfiCpuArchProtocolGuid The RealTimeClockLib class is declared under EmbeddedPkg, so that platforms can provide the internals for the EmbeddedPkg/RealTimeClockRuntimeDxe driver. In turn the driver produces the Real Time Clock Arch Protocol, without which UEFI drivers cannot be dispatched. The PL031RealTimeClockLib instance calls gDS->SetMemorySpaceAttributes() in the LibRtcInitialize() public function. This DXE service depends on the CPU Arch Protocol. Add it to the depex. Cc: Ard Biesheuvel <ard.biesheuvel@xxxxxxxxxx> Cc: Leif Lindholm <leif.lindholm@xxxxxxxxxx> Cc: Steve Capper <steve.capper@xxxxxxxxxx> Cc: Supreeth Venkatesh <Supreeth.Venkatesh@xxxxxxx> Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Laszlo Ersek <lersek@xxxxxxxxxx> Reviewed-by: Ard Biesheuvel <ard.biesheuvel@xxxxxxxxxx> Tested-by: Steve Capper <steve.capper@xxxxxxxxxx> Reviewed-by: Leif Lindholm <leif.lindholm@xxxxxxxxxx> commit 96337c6dbbd0873eb611c82cd91483ef198b770b Author: Laszlo Ersek <lersek@xxxxxxxxxx> Date: Wed Apr 11 22:59:13 2018 +0200 ArmPlatformPkg/NorFlashDxe: depend on gEfiCpuArchProtocolGuid NorFlashFvbInitialize() calls gDS->SetMemorySpaceAttributes() to mark the varstore flash region as uncached. This DXE service depends on the CPU Architectural protocol, and the DXE core is allowed to return EFI_NOT_AVAILABLE_YET if it hasn't dispatched ArmPkg/Drivers/CpuDxe earlier. Make the dependency explicit. Cc: Ard Biesheuvel <ard.biesheuvel@xxxxxxxxxx> Cc: Leif Lindholm <leif.lindholm@xxxxxxxxxx> Cc: Steve Capper <steve.capper@xxxxxxxxxx> Cc: Supreeth Venkatesh <Supreeth.Venkatesh@xxxxxxx> Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Laszlo Ersek <lersek@xxxxxxxxxx> Reviewed-by: Ard Biesheuvel <ard.biesheuvel@xxxxxxxxxx> Tested-by: Steve Capper <steve.capper@xxxxxxxxxx> Reviewed-by: Leif Lindholm <leif.lindholm@xxxxxxxxxx> commit 6281a2ed3bb3ffe57ed54cabd9a31dcf13b415f8 Author: Laszlo Ersek <lersek@xxxxxxxxxx> Date: Wed Apr 11 22:50:18 2018 +0200 ArmPlatformPkg/NorFlashDxe: cue the variable driver with NvVarStoreFormatted The BEFORE depex opcode that we currently use to force ourselves in front of the variable driver cannot be combined with other depex opcodes. Replace the depex with TRUE, and signal NvVarStoreFormattedLib through the installation of "gEdkiiNvVarStoreFormattedGuid". Platforms that rely on NorFlashDxe to format the variable store (as opposed to formatting a variable store template through an FDF file, as part of the build) should hook NvVarStoreFormattedLib into the variable drivers they use, so that the latter await our cue. Cc: Ard Biesheuvel <ard.biesheuvel@xxxxxxxxxx> Cc: Leif Lindholm <leif.lindholm@xxxxxxxxxx> Cc: Steve Capper <steve.capper@xxxxxxxxxx> Cc: Supreeth Venkatesh <Supreeth.Venkatesh@xxxxxxx> Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Laszlo Ersek <lersek@xxxxxxxxxx> Reviewed-by: Ard Biesheuvel <ard.biesheuvel@xxxxxxxxxx> Tested-by: Steve Capper <steve.capper@xxxxxxxxxx> Reviewed-by: Leif Lindholm <leif.lindholm@xxxxxxxxxx> commit 0f87c53d0d0eb7e7c003e209705ec79264e0852b Author: Laszlo Ersek <lersek@xxxxxxxxxx> Date: Wed Apr 11 22:18:24 2018 +0200 ArmPlatformPkg/NorFlashDxe: initialize varstore headers eagerly The lazy initialization of the varstore FVB makes no longer sense at this point: - "mNorFlashInstanceTemplate.Initialize" is NULL; - in NorFlashCreateInstance(), we only set Instance->Initialize to non-NULL -- namely NorFlashFvbInitialize() -- if the FVB stands for the variable store (see "ContainVariableStorage" / "SupportFvb"); - we call Instance->Initialize() from three places: - from NorFlashWriteSingleBlock(), which is too late for the variable read service ("variable write" depends on "variable read"); - from InitializeFvAndVariableStoreHeaders(), but that is only reachable from NorFlashFvbInitialize(), i.e. recursively from Instance->Initialize() itself; - and from FvbRead(), which is never called by the variable driver, only by the FTW driver. However, the variable driver may read (not write) the memory-mapped varstore flash chip before the FTW driver is dispatched. Therefore the lazy initialization is both superfluous and insufficient. Initialize the varstore headers eagerly, before we install the FVB protocol interface. Cc: Ard Biesheuvel <ard.biesheuvel@xxxxxxxxxx> Cc: Leif Lindholm <leif.lindholm@xxxxxxxxxx> Cc: Steve Capper <steve.capper@xxxxxxxxxx> Cc: Supreeth Venkatesh <Supreeth.Venkatesh@xxxxxxx> Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Laszlo Ersek <lersek@xxxxxxxxxx> Reviewed-by: Ard Biesheuvel <ard.biesheuvel@xxxxxxxxxx> Tested-by: Steve Capper <steve.capper@xxxxxxxxxx> Reviewed-by: Leif Lindholm <leif.lindholm@xxxxxxxxxx> commit 7ab26d51808bd4ffab2510091b062a91cf6a8c81 Author: Laszlo Ersek <lersek@xxxxxxxxxx> Date: Wed Apr 11 20:58:58 2018 +0200 EmbeddedPkg: introduce NvVarStoreFormattedLib Some platforms don't format a variable store template at build time; instead they format the non-volatile varstore flash chip during boot, dynamically. Introduce NvVarStoreFormattedLib to enable such platforms to delay the "variable read" service drivers until the platform specific module(s) report that the variable store has been formatted. The platform-specific module that performs the formatting during startup is usually an FVB or MM FVB driver. Under the proposed scheme, it becomes responsible for installing gEdkiiNvVarStoreFormattedGuid with a NULL interface in the protocol database. In turn, the platform DSC will hook NvVarStoreFormattedLib into the variable service driver, to make the latter wait for the FVB driver. Platforms that need not delay the variable service driver like this may still use the same FVB driver; gEdkiiNvVarStoreFormattedGuid will simply be ignored. Cc: Ard Biesheuvel <ard.biesheuvel@xxxxxxxxxx> Cc: Leif Lindholm <leif.lindholm@xxxxxxxxxx> Cc: Steve Capper <steve.capper@xxxxxxxxxx> Cc: Supreeth Venkatesh <Supreeth.Venkatesh@xxxxxxx> Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Laszlo Ersek <lersek@xxxxxxxxxx> Reviewed-by: Ard Biesheuvel <ard.biesheuvel@xxxxxxxxxx> Tested-by: Steve Capper <steve.capper@xxxxxxxxxx> Reviewed-by: Leif Lindholm <leif.lindholm@xxxxxxxxxx> commit bacfd6ed8cea295e2d955d13bcd372499a4c6806 Author: Laszlo Ersek <lersek@xxxxxxxxxx> Date: Wed Apr 11 18:52:25 2018 +0200 ArmPkg/CpuDxe: order CpuDxe after ArmGicDxe via protocol depex Commit 61a7b0ec634f ("ArmPkg/Gic: force GIC driver to run before CPU arch protocol driver", 2018-02-06) explains why CpuDxe should be dispatched after ArmGicDxe. To implement the ordering, we should use a regular protocol depex rather than the less flexible AFTER opcode. ArmGicDxe installs gHardwareInterruptProtocolGuid and gHardwareInterrupt2ProtocolGuid as one of the last actions on its entry point stack; either of those is OK for CpuDxe to wait for. Cc: Ard Biesheuvel <ard.biesheuvel@xxxxxxxxxx> Cc: Leif Lindholm <leif.lindholm@xxxxxxxxxx> Cc: Steve Capper <steve.capper@xxxxxxxxxx> Cc: Supreeth Venkatesh <Supreeth.Venkatesh@xxxxxxx> Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Laszlo Ersek <lersek@xxxxxxxxxx> Reviewed-by: Ard Biesheuvel <ard.biesheuvel@xxxxxxxxxx> Tested-by: Steve Capper <steve.capper@xxxxxxxxxx> Reviewed-by: Leif Lindholm <leif.lindholm@xxxxxxxxxx> commit 04f6b66b5e77df031291696569dfd9ba9ac4c367 Author: Laszlo Ersek <lersek@xxxxxxxxxx> Date: Wed Apr 11 18:40:49 2018 +0200 ArmPkg/ArmGicDxe: annotate protocol usage in "ArmGicDxe.inf" "ArmGicDxe.inf" currently does not document how the protocols in the [Protocols] section are used. Such comments help us analyze behavior, so let's add them now. - gHardwareInterruptProtocolGuid and gHardwareInterrupt2ProtocolGuid are always produced on the InterruptDxeInitialize() -> (GicV2DxeInitialize() | GicV3DxeInitialize()) -> InstallAndRegisterInterruptService() call path. - gEfiCpuArchProtocolGuid is consumed in the CpuArchEventProtocolNotify() protocol notify callback. (Technically this is "conditional"; however the firmware cannot work without architectural protocols, so we can call it unconditional.) While at it, drop the gArmGicDxeFileGuid comment from FILE_GUID; we're going to make that GUID uninteresting soon. Cc: Ard Biesheuvel <ard.biesheuvel@xxxxxxxxxx> Cc: Leif Lindholm <leif.lindholm@xxxxxxxxxx> Cc: Steve Capper <steve.capper@xxxxxxxxxx> Cc: Supreeth Venkatesh <Supreeth.Venkatesh@xxxxxxx> Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Laszlo Ersek <lersek@xxxxxxxxxx> Reviewed-by: Ard Biesheuvel <ard.biesheuvel@xxxxxxxxxx> Tested-by: Steve Capper <steve.capper@xxxxxxxxxx> Reviewed-by: Leif Lindholm <leif.lindholm@xxxxxxxxxx> commit 534397e53849183d5f7ac1b74219f3634cffa294 Author: Laszlo Ersek <lersek@xxxxxxxxxx> Date: Thu Apr 12 00:03:45 2018 +0200 Omap35xxPkg/InterruptDxe: replace CPU Arch Protocol depex with notify In a later patch, we'll modify the depex of "ArmPkg/Drivers/CpuDxe/CpuDxe.inf" (currently "AFTER gArmGicDxeFileGuid") to "gHardwareInterruptProtocolGuid OR gHardwareInterrupt2ProtocolGuid". Considering platforms that include "ArmPkg/Drivers/CpuDxe/CpuDxe.inf", there are two classes: (1) The platform gets its gHardwareInterruptProtocolGuid or gHardwareInterrupt2ProtocolGuid instance from "ArmPkg/Drivers/ArmGic/ArmGicDxe.inf". For such platforms, the upcoming CpuDxe change is not a problem, because commit 61a7b0ec634f made ArmGicDxe wait for the CPU Arch Protocol with a protocol notify. (2) The platform gets its hardware interrupt protocol(s) from a different driver that has a hard depex on the CPU Arch Protocol. The upcoming CpuDxe change would lead to a loop in the DXE dispatch order. In the edk2 tree, only "BeagleBoardPkg/BeagleBoardPkg.dsc" falls in class (2), and the driver in question is "Omap35xxPkg/InterruptDxe". Port (most of) commit 61a7b0ec634f to it. Cc: Ard Biesheuvel <ard.biesheuvel@xxxxxxxxxx> Cc: Leif Lindholm <leif.lindholm@xxxxxxxxxx> Cc: Steve Capper <steve.capper@xxxxxxxxxx> Cc: Supreeth Venkatesh <Supreeth.Venkatesh@xxxxxxx> Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Laszlo Ersek <lersek@xxxxxxxxxx> Reviewed-by: Ard Biesheuvel <ard.biesheuvel@xxxxxxxxxx> Reviewed-by: Leif Lindholm <leif.lindholm@xxxxxxxxxx> _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxxx https://lists.xenproject.org/mailman/listinfo/xen-devel
|
 |
Lists.xenproject.org is hosted with RackSpace, monitoring our |