[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [Xen-devel] [ovmf test] 102305: regressions - FAIL
flight 102305 ovmf real [real] http://logs.test-lab.xenproject.org/osstest/logs/102305/ 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 9ec9a7a59769927ad1f5662f78a52031cb9cd758 baseline version: ovmf e242cdfb307a6dfe2c0f75c4719f5c1f6b418625 Last test of basis 102292 2016-11-16 08:17:51 Z 0 days Testing same since 102298 2016-11-16 11:44:14 Z 0 days 2 attempts ------------------------------------------------------------ People who touched revisions under test: Jeff Fan <jeff.fan@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 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
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |