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

[Xen-devel] [ovmf test] 94784: regressions - FAIL



flight 94784 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/94784/

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                 6b571c4d8c827a39a5e249d5d9db4f99aebb5d63
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    1 days    5 attempts
Testing same since    94784  2016-05-26 02:56:04 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 6b571c4d8c827a39a5e249d5d9db4f99aebb5d63
Author: Hao Wu <hao.a.wu@xxxxxxxxx>
Date:   Wed May 25 10:00:08 2016 +0800

    MdeModulePkg NvmExpressDxe: Fix VS2010 build error
    
    Potentially uninitialized 'Status' might be returned in functions
    NvmeCreateIoCompletionQueue() and NvmeCreateIoSubmissionQueue() in file
    NvmExpressHci.c.
    
    Contributed-under: TianoCore Contribution Agreement 1.0
    Signed-off-by: Hao Wu <hao.a.wu@xxxxxxxxx>
    Reviewed-by: Qiu Shumin <shumin.qiu@xxxxxxxxx>
    Reviewed-by: Feng Tian <feng.tian@xxxxxxxxx>

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

 


Rackspace

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