[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Xen-devel] [ovmf baseline-only test] 71359: tolerable FAIL



This run is configured for baseline tests only.

flight 71359 ovmf real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/71359/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 build-amd64-libvirt           5 libvirt-build                fail   like 71343
 build-i386-libvirt            5 libvirt-build                fail   like 71343

version targeted for testing:
 ovmf                 f78c8bf2c64f57d5148bea1a56ade2218a13e4d7
baseline version:
 ovmf                 7a85e8474127ae6df47337a04797b2b443b57682

Last test of basis    71343  2017-05-18 13:19:36 Z    1 days
Testing same since    71359  2017-05-19 09:24:46 Z    0 days    1 attempts

------------------------------------------------------------
People who touched revisions under test:
  Laszlo Ersek <lersek@xxxxxxxxxx>

jobs:
 build-amd64-xsm                                              pass    
 build-i386-xsm                                               pass    
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          fail    
 build-i386-libvirt                                           fail    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl-qemuu-ovmf-amd64                         pass    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          pass    


------------------------------------------------------------
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


Push not applicable.

------------------------------------------------------------
commit f78c8bf2c64f57d5148bea1a56ade2218a13e4d7
Author: Laszlo Ersek <lersek@xxxxxxxxxx>
Date:   Sat May 6 18:09:28 2017 +0200

    OvmfPkg/README: document 4MB flash layout
    
    Cc: Jordan Justen <jordan.l.justen@xxxxxxxxx>
    Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=527
    Contributed-under: TianoCore Contribution Agreement 1.0
    Signed-off-by: Laszlo Ersek <lersek@xxxxxxxxxx>
    Reviewed-by: Jordan Justen <jordan.l.justen@xxxxxxxxx>

commit c9e7907d09eaf2702ae5c6963f24ab53fc57dc33
Author: Laszlo Ersek <lersek@xxxxxxxxxx>
Date:   Sat May 6 16:02:47 2017 +0200

    OvmfPkg/PlatformPei: align EmuVariableNvStore at any page boundary
    
    EmuVariableFvbRuntimeDxe now uses a 4KB (EFI_PAGE_SIZE) block size.
    
    Cc: Jordan Justen <jordan.l.justen@xxxxxxxxx>
    Contributed-under: TianoCore Contribution Agreement 1.0
    Signed-off-by: Laszlo Ersek <lersek@xxxxxxxxxx>
    Regression-tested-by: Gary Lin <glin@xxxxxxxx>
    Reviewed-by: Jordan Justen <jordan.l.justen@xxxxxxxxx>

commit 7e8329267ecb62670263bfc6afec93f37bfa19d2
Author: Laszlo Ersek <lersek@xxxxxxxxxx>
Date:   Sat May 6 13:17:58 2017 +0200

    OvmfPkg/EmuVariableFvbRuntimeDxe: change block size to 4KB
    
    EmuVariableFvbRuntimeDxe currently produces a Firmware Volume Block
    protocol that is based on a block map of two blocks, each block having
    PcdFlashNvStorageFtwSpareSize for size.
    
    (The total size is 2 * PcdFlashNvStorageFtwSpareSize.)
    
    FaultTolerantWriteDxe in turn expects the block size to be a power of two.
    
    In the 4MB build of OVMF, PcdFlashNvStorageFtwSpareSize is 264KB, which is
    not a power of two. In order to equip EmuVariableFvbRuntimeDxe for this
    build, shrink the block size to 4KB (EFI_PAGE_SIZE), and grow the block
    count from 2 to EFI_SIZE_TO_PAGES(2 * PcdFlashNvStorageFtwSpareSize). The
    total size remains
    
      2 * PcdFlashNvStorageFtwSpareSize
      --------------------------------- * EFI_PAGE_SIZE
                EFI_PAGE_SIZE
    
    Right now EmuVariableFvbRuntimeDxe open-codes the block count of 2 in
    various limit checks, so introduce a few new macros:
    - EMU_FVB_NUM_TOTAL_BLOCKS, for the LHS of the above product,
    - EMU_FVB_NUM_SPARE_BLOCKS for the half of that.
    
    Also rework the FVB protocol members to support an arbitrary count of
    blocks.
    
    Keep the invariant intact that the first half of the firmware volume hosts
    the variable store and the FTW working block, and that the second half
    maps the FTW spare area.
    
    Cc: Jordan Justen <jordan.l.justen@xxxxxxxxx>
    Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=527
    Contributed-under: TianoCore Contribution Agreement 1.0
    Signed-off-by: Laszlo Ersek <lersek@xxxxxxxxxx>
    Regression-tested-by: Gary Lin <glin@xxxxxxxx>
    Reviewed-by: Jordan Justen <jordan.l.justen@xxxxxxxxx>

commit 89f385ce0ad7bf2c93a80ff7733e45f2af88937a
Author: Laszlo Ersek <lersek@xxxxxxxxxx>
Date:   Sat May 6 13:52:08 2017 +0200

    OvmfPkg/EmuVariableFvbRuntimeDxe: strip trailing whitespace
    
    Cc: Jordan Justen <jordan.l.justen@xxxxxxxxx>
    Contributed-under: TianoCore Contribution Agreement 1.0
    Signed-off-by: Laszlo Ersek <lersek@xxxxxxxxxx>
    Regression-tested-by: Gary Lin <glin@xxxxxxxx>
    Reviewed-by: Jordan Justen <jordan.l.justen@xxxxxxxxx>

commit 38292c08728d10c141a69b05bbdb3afc2c6618e6
Author: Laszlo Ersek <lersek@xxxxxxxxxx>
Date:   Thu May 18 14:48:13 2017 +0200

    OvmfPkg/QemuFlashFvbServicesRuntimeDxe: correct NumOfLba vararg type in 
EraseBlocks()
    
    According to the PI spec, Volume 3,
    EFI_FIRMWARE_VOLUME_BLOCK2_PROTOCOL.EraseBlocks():
    
    > The variable argument list is a list of tuples. Each tuple describes a
    > range of LBAs to erase and consists of the following:
    > * An EFI_LBA that indicates the starting LBA
    > * A UINTN that indicates the number of blocks to erase
    
    (NB, in edk2, EFI_FIRMWARE_VOLUME_BLOCK_PROTOCOL is a typedef to
    EFI_FIRMWARE_VOLUME_BLOCK2_PROTOCOL.)
    
    In this driver, the NumOfLba local variable is defined with type UINTN,
    but the TYPE argument passed to VA_ARG() is UINT32. Fix the mismatch.
    
    Cc: Jordan Justen <jordan.l.justen@xxxxxxxxx>
    Reported-by: Jordan Justen <jordan.l.justen@xxxxxxxxx>
    Contributed-under: TianoCore Contribution Agreement 1.0
    Signed-off-by: Laszlo Ersek <lersek@xxxxxxxxxx>
    Reviewed-by: Jordan Justen <jordan.l.justen@xxxxxxxxx>

commit 9c4eef656fa3ea455125abc66780942780b46f85
Author: Laszlo Ersek <lersek@xxxxxxxxxx>
Date:   Thu May 18 14:48:13 2017 +0200

    OvmfPkg/EmuVariableFvbRuntimeDxe: correct NumOfLba vararg type in 
EraseBlocks()
    
    According to the PI spec, Volume 3,
    EFI_FIRMWARE_VOLUME_BLOCK2_PROTOCOL.EraseBlocks():
    
    > The variable argument list is a list of tuples. Each tuple describes a
    > range of LBAs to erase and consists of the following:
    > * An EFI_LBA that indicates the starting LBA
    > * A UINTN that indicates the number of blocks to erase
    
    (NB, in edk2, EFI_FIRMWARE_VOLUME_BLOCK_PROTOCOL is a typedef to
    EFI_FIRMWARE_VOLUME_BLOCK2_PROTOCOL.)
    
    In this driver, the NumOfLba local variable is defined with type UINTN,
    but the TYPE argument passed to VA_ARG() is UINT32. Fix the mismatch.
    
    Cc: Jordan Justen <jordan.l.justen@xxxxxxxxx>
    Contributed-under: TianoCore Contribution Agreement 1.0
    Signed-off-by: Laszlo Ersek <lersek@xxxxxxxxxx>
    Reviewed-by: Jordan Justen <jordan.l.justen@xxxxxxxxx>

commit 1ee0e6532fb1f863b48c169dbc42a71d0097c5c8
Author: Laszlo Ersek <lersek@xxxxxxxxxx>
Date:   Thu May 18 14:48:13 2017 +0200

    EmulatorPkg/FvbServicesRuntimeDxe: correct NumOfLba vararg type in 
EraseBlocks()
    
    According to the PI spec, Volume 3,
    EFI_FIRMWARE_VOLUME_BLOCK2_PROTOCOL.EraseBlocks():
    
    > The variable argument list is a list of tuples. Each tuple describes a
    > range of LBAs to erase and consists of the following:
    > * An EFI_LBA that indicates the starting LBA
    > * A UINTN that indicates the number of blocks to erase
    
    (NB, in edk2, EFI_FIRMWARE_VOLUME_BLOCK_PROTOCOL is a typedef to
    EFI_FIRMWARE_VOLUME_BLOCK2_PROTOCOL.)
    
    In this driver, the NumOfLba local variable is defined with type UINTN,
    but the TYPE argument passed to VA_ARG() is UINT32. Fix the mismatch.
    
    Cc: Andrew Fish <afish@xxxxxxxxx>
    Cc: Jordan Justen <jordan.l.justen@xxxxxxxxx>
    Reported-by: Jordan Justen <jordan.l.justen@xxxxxxxxx>
    Contributed-under: TianoCore Contribution Agreement 1.0
    Signed-off-by: Laszlo Ersek <lersek@xxxxxxxxxx>
    Reviewed-by: Jordan Justen <jordan.l.justen@xxxxxxxxx>

commit ce69cc776cfcc4a0869907cd4263fd134064dbaf
Author: Laszlo Ersek <lersek@xxxxxxxxxx>
Date:   Thu May 18 14:48:13 2017 +0200

    ArmPlatformPkg/NorFlashDxe: correct NumOfLba vararg type in EraseBlocks()
    
    According to the PI spec, Volume 3,
    EFI_FIRMWARE_VOLUME_BLOCK2_PROTOCOL.EraseBlocks():
    
    > The variable argument list is a list of tuples. Each tuple describes a
    > range of LBAs to erase and consists of the following:
    > * An EFI_LBA that indicates the starting LBA
    > * A UINTN that indicates the number of blocks to erase
    
    (NB, in edk2, EFI_FIRMWARE_VOLUME_BLOCK_PROTOCOL is a typedef to
    EFI_FIRMWARE_VOLUME_BLOCK2_PROTOCOL.)
    
    In this driver, the NumOfLba local variable is defined with type UINTN,
    but the TYPE argument passed to VA_ARG() is UINT32. Fix the mismatch.
    
    In addition, update the DEBUG macro invocation where NumOfLba is formatted
    with the %d conversion specifier: UINTN values should be converted to
    UINT64 and printed with %Lu or %Lx for portability between 32-bit and
    64-bit.
    
    Cc: Ard Biesheuvel <ard.biesheuvel@xxxxxxxxxx>
    Cc: Jordan Justen <jordan.l.justen@xxxxxxxxx>
    Cc: Leif Lindholm <leif.lindholm@xxxxxxxxxx>
    Reported-by: Jordan Justen <jordan.l.justen@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>

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
https://lists.xen.org/xen-devel

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.