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

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



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

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 test-amd64-amd64-xl-qemuu-ovmf-amd64 9 debian-hvm-install fail REGR. vs. 102292
 test-amd64-i386-xl-qemuu-ovmf-amd64 9 debian-hvm-install fail REGR. vs. 102292

version targeted for testing:
 ovmf                 ad13d7d2d4a1d329a60b414843a888c54bdbad73
baseline version:
 ovmf                 e242cdfb307a6dfe2c0f75c4719f5c1f6b418625

Last test of basis   102292  2016-11-16 08:17:51 Z    0 days
Failing since        102298  2016-11-16 11:44:14 Z    0 days    3 attempts
Testing same since   102314  2016-11-16 20:45:18 Z    0 days    1 attempts

------------------------------------------------------------
People who touched revisions under test:
  Jeff Fan <jeff.fan@xxxxxxxxx>
  Liming Gao <liming.gao@xxxxxxxxx>
  Qin Long <qin.long@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 ad13d7d2d4a1d329a60b414843a888c54bdbad73
Author: Liming Gao <liming.gao@xxxxxxxxx>
Date:   Wed Nov 16 10:10:07 2016 +0800

    OvmfPkg AcpiTables: Use PcdDebugIoPort to describe QEMU debug console
    
    Cc: Laszlo Ersek <lersek@xxxxxxxxxx>
    Contributed-under: TianoCore Contribution Agreement 1.0
    Signed-off-by: Liming Gao <liming.gao@xxxxxxxxx>
    Reviewed-by: Laszlo Ersek <lersek@xxxxxxxxxx>

commit 9ec9a7a59769927ad1f5662f78a52031cb9cd758
Author: Qin Long <qin.long@xxxxxxxxx>
Date:   Fri Nov 4 15:31:28 2016 +0800

    MdePkg/BaseLib: Add one wrapper on RdRand access for parameter check.
    
    Add one wrapper implementation over assembly RdRand access to check
    possible NULL parameter, for better alignment with comment description.
    
    Cc: Liming Gao <liming.gao@xxxxxxxxx>
    Contributed-under: TianoCore Contribution Agreement 1.0
    Signed-off-by: Qin Long <qin.long@xxxxxxxxx>
    Reviewed-by: Liming Gao <liming.gao@xxxxxxxxx>

commit b3775af2775dd0fdf9c0698fb395ed3ffc81b2d3
Author: Jeff Fan <jeff.fan@xxxxxxxxx>
Date:   Mon Nov 14 11:43:26 2016 +0800

    UefiCpuPkg/MpInitLib: Update AP information when BSP switched
    
    When BSP switched, we need to update some AP information. For example,
    ApStartupSignalBuffer and ApTopOfStack.
    
    Cc: Feng Tian <feng.tian@xxxxxxxxx>
    Cc: Michael D Kinney <michael.d.kinney@xxxxxxxxx>
    Contributed-under: TianoCore Contribution Agreement 1.0
    Signed-off-by: Jeff Fan <jeff.fan@xxxxxxxxx>
    Reviewed-by: Feng Tian <feng.tian@xxxxxxxxx>

commit 845c5be1fd9bf7edfac4a103dfab70829686978f
Author: Jeff Fan <jeff.fan@xxxxxxxxx>
Date:   Mon Nov 14 11:38:25 2016 +0800

    UefiCpuPkg/MpInitLib: Program AP stack in fixed address
    
    Currently, MpInitLib will program AP stack in dynamic address. Each 
processor
    will calculate its stack address by adding stack size based on the last 
stack
    address. That means AP may have the different stack address everytime it is
    wakeup by INIT-SIPI-SIPI.
    
    When all APs have wakeup to execute AP task, each each has been assigned one
    stack address. Once the timeout happened on some of APs, BSP will send INIT-
    SIPI-SIPI to wake up APs. We need to re-assign stack for APs. Based on the
    current implementation, we might assign one stack address used by other APs.
    It will cause the unexpected stack overlapped issue.
    
    This fix changed the stack assignment policy. We will record the stack 
address
    assigned to AP at first time AP wakeup. When AP failed on AP task, BSP could
    reassigned the same stack for it.
    
    Getting initial APIC ID in assembly code could help AP to get saved its 
stack
    address.
    
    Cc: Feng Tian <feng.tian@xxxxxxxxx>
    Cc: Michael D Kinney <michael.d.kinney@xxxxxxxxx>
    Contributed-under: TianoCore Contribution Agreement 1.0
    Signed-off-by: Jeff Fan <jeff.fan@xxxxxxxxx>
    Reviewed-by: Feng Tian <feng.tian@xxxxxxxxx>

commit 46d4b8858f0eea8952a4f3d289c47d96218159b4
Author: Jeff Fan <jeff.fan@xxxxxxxxx>
Date:   Mon Nov 14 11:09:00 2016 +0800

    UefiCpuPkg/MpInitLib: Add InitFlag and CpuInfo in MP_CPU_EXCHANGE_INFO
    
    Cc: Feng Tian <feng.tian@xxxxxxxxx>
    Cc: Michael D Kinney <michael.d.kinney@xxxxxxxxx>
    Contributed-under: TianoCore Contribution Agreement 1.0
    Signed-off-by: Jeff Fan <jeff.fan@xxxxxxxxx>
    Reviewed-by: Feng Tian <feng.tian@xxxxxxxxx>

commit 31a1e4da495ed211d7bdfdfe626a18c594aaa11c
Author: Jeff Fan <jeff.fan@xxxxxxxxx>
Date:   Mon Nov 14 10:49:51 2016 +0800

    UefiCpuPkg/MpInitLib: Remove CPU information from CPU_AP_DATA
    
    Some CPU information (InitialApicId/ApicId/Health) are duplicated in 
CPU_AP_DATA
    and CPU_INFO_IN_HOB.
    
    This update is to remove the ones from CPU_AP_DATA and update MpInitLib to
    consume the ones from CPU_INFO_IN_HOB.
    
    V2:
      Fixed potential un-initialized variable issue.
    
    Cc: Feng Tian <feng.tian@xxxxxxxxx>
    Cc: Michael D Kinney <michael.d.kinney@xxxxxxxxx>
    Contributed-under: TianoCore Contribution Agreement 1.0
    Signed-off-by: Jeff Fan <jeff.fan@xxxxxxxxx>
    Reviewed-by: Feng Tian <feng.tian@xxxxxxxxx>

commit cb33bde4ac7536f5a5621c7a56aecd981585e087
Author: Jeff Fan <jeff.fan@xxxxxxxxx>
Date:   Mon Nov 14 10:30:03 2016 +0800

    UefiCpuPkg/MpInitLib: Force sending INIT-SIPI-SIPI to reset APs
    
    If BSP found APs timeout happened when AP executing AP task, BSP will reset 
APs
    by WakeUpAP(). However, if ApLoopMode is ApMwaitLoop or ApRunLoop, 
WakeUpAp()
    will try to write semaphore in memory to wake up AP. It cannot wake up APs
    actually if APs still executing AP task.
    
    This fix is to set ApInitReconfig flag to force BSP to send INIT-SIPI-SIPI 
to
    wake up APs.
    
    Cc: Feng Tian <feng.tian@xxxxxxxxx>
    Cc: Michael D Kinney <michael.d.kinney@xxxxxxxxx>
    Contributed-under: TianoCore Contribution Agreement 1.0
    Signed-off-by: Jeff Fan <jeff.fan@xxxxxxxxx>
    Reviewed-by: Feng Tian <feng.tian@xxxxxxxxx>

commit d67cbc66045e824d61fca5bf51c90783161becdf
Author: Jeff Fan <jeff.fan@xxxxxxxxx>
Date:   Mon Nov 14 10:13:41 2016 +0800

    UefiCpuPkg/MpInitLib: Fixed offset error on Cr3Location
    
    Cr3Location offset value should be 0x34 not 0x3C.
    
    Cc: Feng Tian <feng.tian@xxxxxxxxx>
    Cc: Hao Wu <hao.a.wu@xxxxxxxxx>
    Cc: Michael D Kinney <michael.d.kinney@xxxxxxxxx>
    Contributed-under: TianoCore Contribution Agreement 1.0
    Signed-off-by: Jeff Fan <jeff.fan@xxxxxxxxx>
    Reviewed-by: Feng Tian <feng.tian@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®.