[ovmf baseline-only test] 71063: all pass

[ovmf baseline-only test] 71063: all pass

[Platform Team regression test user]

This run is configured for baseline tests only.

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

Perfect :-)
All tests in this flight passed as required
version targeted for testing:
 ovmf                 f2333c707dd04f069c102bcae004561ec590a3a0
baseline version:
 ovmf                 3df29b5d16d39b335b7daca625b3781e1da9920c

Last test of basis    71026  2017-03-20 11:23:09 Z    1 days
Testing same since    71063  2017-03-21 07:50:39 Z    0 days    1 attempts

------------------------------------------------------------
People who touched revisions under test:
  Ard Biesheuvel <ard.biesheuvel@linaro.org>
  Laszlo Ersek <lersek@redhat.com>
  Suman Prakash <suman.p@samsung.com.com>
  Suman Prakash <suman.p@samsung.com>

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                         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 f2333c707dd04f069c102bcae004561ec590a3a0
Author: Suman Prakash <suman.p@samsung.com>
Date:   Mon Mar 20 16:34:55 2017 +0800

    MdeModulePkg/NvmExpressDxe: Memory leak fix in async code flow
    
    For async commands, the buffer allocated for Prp list is
    not getting freed, which will cause memory leak for async
    read write command. For example testing async command flow
    with custom application to send multiple read write commands
    were resulting in decrease of available memory page in memmap,
    which eventually resulted in system hang. Hence freeing
    AsyncRequest->MapData, AsyncRequest->MapMeta, AsyncRequest->MapPrpList and
    AsyncRequest->PrpListHost when async command is completed.
    
    Cc: Feng Tian <feng.tian@intel.com>
    Contributed-under: TianoCore Contribution Agreement 1.0
    Signed-off-by: Suman Prakash <suman.p@samsung.com.com>
    Reviewed-by: Hao Wu <hao.a.wu@intel.com>

commit 38b15ebe4fd5888493131d30fc31833a5e9a7d36
Author: Laszlo Ersek <lersek@redhat.com>
Date:   Mon Mar 20 11:24:23 2017 +0100

    MdeModulePkg/Core/Dxe: downgrade "CodeSegmentCount is 0" msg to DEBUG_WARN
    
    UEFI executables that consist of a single read+write+exec PE/COFF section
    trigger this message, but such a binary layout isn't actually an error.
    The image can be launched alright, only image protection cannot be applied
    to it fully.
    
    One example that elicits the message is (some) Linux kernels (with the EFI
    stub of course).
    
    Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
    Cc: Feng Tian <feng.tian@intel.com>
    Cc: Jiewen Yao <jiewen.yao@intel.com>
    Cc: Star Zeng <star.zeng@intel.com>
    Contributed-under: TianoCore Contribution Agreement 1.0
    Signed-off-by: Laszlo Ersek <lersek@redhat.com>
    Acked-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
    Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>

commit 76874be3d411bf8daac051718e20932e0bf97d70
Author: Laszlo Ersek <lersek@redhat.com>
Date:   Fri Mar 17 19:57:09 2017 +0100

    MdeModulePkg/RamDiskDxe: fix C string literal catenation in info messages
    
    RamDiskDxe installs the RamDiskAcpiCheck() Ready To Boot callback
    function. If EFI_ACPI_TABLE_PROTOCOL and/or EFI_ACPI_SDT_PROTOCOL are not
    found, then informational messages are logged, and the RAM disks are not
    published to the (nonexistent) NFIT table.
    
    The logic is fine, but the info messages are not concatenated correctly
    from multiple string literals -- the second parts are passed as (unused)
    arguments to DEBUG(). Fix the typos.
    
    Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
    Cc: Feng Tian <feng.tian@intel.com>
    Cc: Hao Wu <hao.a.wu@intel.com>
    Cc: Leif Lindholm <leif.lindholm@linaro.org>
    Cc: Star Zeng <star.zeng@intel.com>
    Contributed-under: TianoCore Contribution Agreement 1.0
    Signed-off-by: Laszlo Ersek <lersek@redhat.com>
    Reviewed-by: Feng Tian <feng.tian@intel.com>
    Reviewed-by: Hao Wu <hao.a.wu@intel.com>
    Reviewed-by: Star Zeng <star.zeng@intel.com>

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