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

[ovmf test] 125434: regressions - FAIL



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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-amd64-xsm               6 xen-build                fail REGR. vs. 125295
 build-amd64                   6 xen-build                fail REGR. vs. 125295
 build-i386-xsm                6 xen-build                fail REGR. vs. 125295
 build-i386                    6 xen-build                fail REGR. vs. 125295

Tests which did not succeed, but are not blocking:
 test-amd64-i386-xl-qemuu-ovmf-amd64  1 build-check(1)              blocked n/a
 test-amd64-amd64-xl-qemuu-ovmf-amd64  1 build-check(1)             blocked n/a
 build-i386-libvirt            1 build-check(1)               blocked  n/a
 build-amd64-libvirt           1 build-check(1)               blocked  n/a

version targeted for testing:
 ovmf                 a3fffb4f5e1535e8e542669925eed489fdce6b62
baseline version:
 ovmf                 d900d7c9857a676d9271a0ab499c12b379dc3652

Last test of basis   125295  2018-07-18 03:40:40 Z    1 days
Failing since        125302  2018-07-18 07:10:48 Z    1 days   10 attempts
Testing same since   125434  2018-07-19 15:41:35 Z    0 days    1 attempts

------------------------------------------------------------
People who touched revisions under test:
  Eric Dong <eric.dong@xxxxxxxxx>
  Laszlo Ersek <lersek@xxxxxxxxxx>

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


------------------------------------------------------------
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 a3fffb4f5e1535e8e542669925eed489fdce6b62
Author: Laszlo Ersek <lersek@xxxxxxxxxx>
Date:   Wed Jul 18 14:00:25 2018 +0200

    OvmfPkg/AcpiPlatformDxe: clean up libs and protos in "AcpiPlatformDxe.inf"
    
    None of the source files referenced by "AcpiPlatformDxe.inf" #include
    "MdePkg/Include/Library/DxeServicesLib.h" or use interfaces declared
    therein, so drop DxeServicesLib from [LibraryClasses].
    
    "AcpiPlatformDxe.inf" references "AcpiPlatform.c", which installs ACPI
    tables built into the firmware image from under "OvmfPkg/AcpiTables/", in
    case dynamically generated ACPI tables are not available from Xen or QEMU.
    For this, the driver consumes gEfiFirmwareVolume2ProtocolGuid. Account for
    that in [Protocols].
    
    Cc: Ard Biesheuvel <ard.biesheuvel@xxxxxxxxxx>
    Cc: Jordan Justen <jordan.l.justen@xxxxxxxxx>
    Cc: Steven Shi <steven.shi@xxxxxxxxx>
    Reported-by: Steven Shi <steven.shi@xxxxxxxxx>
    Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1014
    Contributed-under: TianoCore Contribution Agreement 1.1
    Signed-off-by: Laszlo Ersek <lersek@xxxxxxxxxx>
    Reviewed-by: Ard Biesheuvel <ard.biesheuvel@xxxxxxxxxx>

commit 58942277bcbf41abda5f6e3a1c89d571105d5983
Author: Eric Dong <eric.dong@xxxxxxxxx>
Date:   Wed Jun 27 16:42:51 2018 +0800

    UefiCpuPkg/MpInitLib: Fix S3 resume hang issue.
    
    When resume from S3 and CPU loop mode is MWait mode,
    if driver calls APs to do task at EndOfPei point, the
    APs can't been wake up and bios hang at that point.
    
    The root cause is PiSmmCpuDxeSmm driver wakes up APs
    with HLT mode during S3 resume phase to do SMM relocation.
    After this task, PiSmmCpuDxeSmm driver not restore APs
    context which make CpuMpPei driver saved wake up buffer
    not works.
    
    The solution for this issue is let CpuMpPei driver hook
    S3SmmInitDone ppi notification. In this notify function,
    it check whether Cpu Loop mode is not HLT mode. If yes,
    CpuMpPei driver will set a flag to force BSP use INIT-SIPI
    -SIPI command to wake up the APs.
    
    Cc: Laszlo Ersek <lersek@xxxxxxxxxx>
    Cc: Ruiyu Ni <ruiyu.ni@xxxxxxxxx>
    Contributed-under: TianoCore Contribution Agreement 1.1
    Signed-off-by: Eric Dong <eric.dong@xxxxxxxxx>
    Reviewed-by: Ruiyu Ni <ruiyu.ni@xxxxxxxxx>

commit f63a3e286765f47b79a73d56f8d687c4f3733979
Author: Eric Dong <eric.dong@xxxxxxxxx>
Date:   Thu Jul 12 18:21:01 2018 +0800

    UefiCpuPkg/MpInitLib: Load uCode once for each core.
    
    The SDM requires only one thread per core to load the
    microcode.
    
    This change enables this solution.
    
    Cc: Laszlo Ersek <lersek@xxxxxxxxxx>
    Cc: Ruiyu Ni <ruiyu.ni@xxxxxxxxx>
    Contributed-under: TianoCore Contribution Agreement 1.1
    Signed-off-by: Eric Dong <eric.dong@xxxxxxxxx>
    Acked-by: Laszlo Ersek <lersek@xxxxxxxxxx>
    Regression-tested-by: Laszlo Ersek <lersek@xxxxxxxxxx>
    Reviewed-by: Ruiyu Ni <ruiyu.ni@xxxxxxxxx>

commit 2a08913443bb3fff0056cc555e260b2c3fdd2120
Author: Eric Dong <eric.dong@xxxxxxxxx>
Date:   Wed Jul 11 19:07:28 2018 +0800

    UefiCpuPkg/MpInitLib: Use BSP uCode for APs if possible.
    
    Search uCode costs much time, if AP has same processor type
    with BSP, AP can use BSP saved uCode info to get better performance.
    
    This change enables this solution.
    
    Cc: Laszlo Ersek <lersek@xxxxxxxxxx>
    Cc: Ruiyu Ni <ruiyu.ni@xxxxxxxxx>
    Contributed-under: TianoCore Contribution Agreement 1.1
    Signed-off-by: Eric Dong <eric.dong@xxxxxxxxx>
    Acked-by: Laszlo Ersek <lersek@xxxxxxxxxx>
    Regression-tested-by: Laszlo Ersek <lersek@xxxxxxxxxx>
    Reviewed-by: Ruiyu Ni <ruiyu.ni@xxxxxxxxx>

commit 6936ee0342d25bea9f44499444ba1e4df6fc2200
Author: Eric Dong <eric.dong@xxxxxxxxx>
Date:   Fri Jul 13 08:40:27 2018 +0800

    UefiCpuPkg/MpInitLib: Relocate uCode to memory to save time.
    
    Read uCode from memory has better performance than from flash.
    But it needs extra effort to let BSP copy uCode from flash to
    memory. Also BSP already enable cache in SEC phase, so it use
    less time to relocate uCode from flash to memory. After
    verification, if system has more than one processor, it will
    reduce some time if load uCode from memory.
    
    This change enable this optimization.
    
    Cc: Laszlo Ersek <lersek@xxxxxxxxxx>
    Cc: Ruiyu Ni <ruiyu.ni@xxxxxxxxx>
    Contributed-under: TianoCore Contribution Agreement 1.1
    Signed-off-by: Eric Dong <eric.dong@xxxxxxxxx>
    Reviewed-by: Laszlo Ersek <lersek@xxxxxxxxxx>
    Regression-tested-by: Laszlo Ersek <lersek@xxxxxxxxxx>
    Reviewed-by: Ruiyu Ni <ruiyu.ni@xxxxxxxxx>

_______________________________________________
osstest-output mailing list
osstest-output@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/osstest-output

 


Rackspace

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