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

[Xen-devel] [ovmf baseline-only test] 75448: trouble: blocked/broken



This run is configured for baseline tests only.

flight 75448 ovmf real [real]
http://osstest.xensource.com/osstest/logs/75448/

Failures and problems with tests :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-amd64-xsm                 <job status>                 broken
 build-i386                      <job status>                 broken
 build-amd64-pvops               <job status>                 broken
 build-i386-xsm                  <job status>                 broken
 build-amd64                     <job status>                 broken
 build-i386-pvops                <job status>                 broken

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-qemuu-ovmf-amd64  1 build-check(1)             blocked n/a
 build-amd64-libvirt           1 build-check(1)               blocked  n/a
 test-amd64-i386-xl-qemuu-ovmf-amd64  1 build-check(1)              blocked n/a
 build-i386-libvirt            1 build-check(1)               blocked  n/a
 build-amd64                   4 host-install(4)       broken baseline untested
 build-i386                    4 host-install(4)       broken baseline untested
 build-i386-pvops              4 host-install(4)       broken baseline untested
 build-i386-xsm                4 host-install(4)       broken baseline untested
 build-amd64-pvops             4 host-install(4)       broken baseline untested
 build-amd64-xsm               4 host-install(4)       broken baseline untested

version targeted for testing:
 ovmf                 eae7b476c2151141a43cc89d9629c47757f024f1
baseline version:
 ovmf                 3a0329bed2a2c7d1ba45bd2376a2320141ef2bec

Last test of basis    75444  2018-10-18 01:50:41 Z    0 days
Testing same since    75448  2018-10-18 12:50:42 Z    0 days    1 attempts

------------------------------------------------------------
People who touched revisions under test:
  Hao Wu <hao.a.wu@xxxxxxxxx>
  Jian J Wang <jian.j.wang@xxxxxxxxx>
  Yonghong Zhu <yonghong.zhu@xxxxxxxxx>

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


------------------------------------------------------------
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.xensource.com/osstest/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary

broken-job build-amd64-xsm broken
broken-job build-i386 broken
broken-job build-amd64-pvops broken
broken-job build-i386-xsm broken
broken-job build-amd64 broken
broken-job build-i386-pvops broken
broken-step build-amd64 host-install(4)
broken-step build-i386 host-install(4)
broken-step build-i386-pvops host-install(4)
broken-step build-i386-xsm host-install(4)
broken-step build-amd64-pvops host-install(4)
broken-step build-amd64-xsm host-install(4)

Push not applicable.

------------------------------------------------------------
commit eae7b476c2151141a43cc89d9629c47757f024f1
Author: Jian J Wang <jian.j.wang@xxxxxxxxx>
Date:   Wed Oct 17 12:49:57 2018 +0800

    UefiCpuPkg/CpuExceptionHandlerLib: always clear descriptor data in advance
    
    REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1237
    
    Sometimes the memory will be contaminated by random data left in last
    boot (warm reset). The code should not assume the allocated memory is
    always filled with zero. This patch add code to clear data structure
    used for stack switch to prevent such problem from happening.
    
    Cc: Eric Dong <eric.dong@xxxxxxxxx>
    Cc: Laszlo Ersek <lersek@xxxxxxxxxx>
    Cc: Ruiyu Ni <ruiyu.ni@xxxxxxxxx>
    Contributed-under: TianoCore Contribution Agreement 1.1
    Signed-off-by: Jian J Wang <jian.j.wang@xxxxxxxxx>
    Reviewed-by: Eric Dong <eric.dong@xxxxxxxxx>
    Reviewed-by: Laszlo Ersek <lersek@xxxxxxxxxx>
    Reviewed-by: Ruiyu Ni <ruiyu.ni@xxxxxxxxx>

commit fea5e28658c672ce2cbe38d0927ab27beb792097
Author: Yonghong Zhu <yonghong.zhu@xxxxxxxxx>
Date:   Wed Oct 17 20:15:07 2018 +0800

    BaseTools: Fix bug caused by 03c36c36a3
    
    In the expression for unicode string and general string compare, it
    should check whether it startswith "L'" or 'L"', but not "L".
    
    Contributed-under: TianoCore Contribution Agreement 1.1
    Signed-off-by: Yonghong Zhu <yonghong.zhu@xxxxxxxxx>
    Reviewed-by: Liming Gao <liming.gao@xxxxxxxxx>

commit 53c64f4286ba86788e350a82a3798e1a7abf5ef7
Author: Yonghong Zhu <yonghong.zhu@xxxxxxxxx>
Date:   Tue Oct 16 16:10:24 2018 +0800

    BaseTools: Fix a bug --pcd option enable and use the pcd in expression
    
    the case is:
    in the DSC:
    [PcdsFixedAtBuild.common]
     TokenSpaceGuid.TestFixedPcd|0xFFEAA000
    
    [PcdsDynamicExDefault.common.DEFAULT]
    !if TokenSpaceGuid.PcdFlag == TRUE
    TokenSpaceGuid.PcdTest|TokenSpaceGuid.TestFixedPcd
    !endif
    
    Then build with --pcd TokenSpaceGuid.PcdFlag=TRUE, it report failure,
    but if we build without this --pcd option, it could build success.
    we found when the --pcd is enabled, the fixedatbuild pcds are not be
    collected into expression to calculate.
    
    Fixes: https://bugzilla.tianocore.org/show_bug.cgi?id=1256
    Contributed-under: TianoCore Contribution Agreement 1.1
    Signed-off-by: Yonghong Zhu <yonghong.zhu@xxxxxxxxx>
    Reviewed-by: Liming Gao <liming.gao@xxxxxxxxx>

commit 5317e9ccafed5a031c18293caa06b660af3e9a85
Author: Hao Wu <hao.a.wu@xxxxxxxxx>
Date:   Mon Oct 15 10:26:08 2018 +0800

    MdeModulePkg/UdfDxe: Handle dead codes in FileSystemOperations.c
    
    REF:https://bugzilla.tianocore.org/show_bug.cgi?id=1249
    
    We found potential dead codes within File.c during the code coverage test.
    
    After manual review, we think the below ones are positive reports:
    
    A. For function GetAllocationDescriptor():
    Due to the all the calling places for this function, the input parameter
    'RecordingFlags' can only with value 'LongAdsSequence' or
    'ShortAdsSequence'. Moreover, this is also mentioned in the function
    description comments for GetAllocationDescriptor().
    
    So the below code will never be reached:
    
      return EFI_DEVICE_ERROR;
    
    This commit will add "ASSERT (FALSE);" before the above line to indicate
    this and thus matching the function description comments.
    
    B. For function GetAllocationDescriptorLsn():
    Due to the all the calling places for this function, the input parameter
    'RecordingFlags' can only with value 'LongAdsSequence' or
    'ShortAdsSequence'. Moreover, this is also mentioned in the function
    description comments for GetAllocationDescriptorLsn().
    
    So the below code will never be reached:
    
      return EFI_UNSUPPORTED;
    
    This commit will add "ASSERT (FALSE);" before the above line to indicate
    this and thus matching the function description comments.
    
    Cc: Paulo Alcantara <palcantara@xxxxxxx>
    Cc: Paulo Alcantara <paulo@xxxxxxxx>
    Cc: Ruiyu Ni <ruiyu.ni@xxxxxxxxx>
    Cc: Jiewen Yao <jiewen.yao@xxxxxxxxx>
    Contributed-under: TianoCore Contribution Agreement 1.1
    Signed-off-by: Hao Wu <hao.a.wu@xxxxxxxxx>
    Reviewed-by: Star Zeng <star.zeng@xxxxxxxxx>

commit 11941d3b1bfab594ff108ddbfed61bc31e8eb674
Author: Hao Wu <hao.a.wu@xxxxxxxxx>
Date:   Wed Oct 10 21:00:20 2018 +0800

    MdeModulePkg/UdfDxe: Handle dead codes in File.c
    
    REF:https://bugzilla.tianocore.org/show_bug.cgi?id=1249
    
    We found potential dead codes within File.c during the code coverage test.
    
    After manual review, we think the below ones are positive reports:
    
    A. In function UdfRead():
      else if (IS_FID_DELETED_FILE (Parent->FileIdentifierDesc)) {
        Status = EFI_DEVICE_ERROR;
      }
    
    A File Identifier Descriptor will be get from the UDF media only by
    function ReadDirectoryEntry(). And within this function, all the File
    Identifier Descriptor with 'DELETED_FILE' characteristics will be skipped
    and will not be returned. Hence, the above codes in function UdfRead()
    will never be hit.
    
    This commit will add "ASSERT (FALSE);" before the above line to indicate
    this.
    
    Cc: Ruiyu Ni <ruiyu.ni@xxxxxxxxx>
    Contributed-under: TianoCore Contribution Agreement 1.1
    Signed-off-by: Hao Wu <hao.a.wu@xxxxxxxxx>
    Reviewed-by: Paulo Alcantara <palcantara@xxxxxxx>
    Reviewed-by: Star Zeng <star.zeng@xxxxxxxxx>

commit f355dd34049c88167768e4a8acf85934aaae2dd2
Author: Hao Wu <hao.a.wu@xxxxxxxxx>
Date:   Mon Oct 8 14:30:14 2018 +0800

    MdeModulePkg/UdfDxe: Use debug msg instead of ASSERT in UdfOpen()
    
    REF:https://bugzilla.tianocore.org/show_bug.cgi?id=1248
    
    Within function UdfOpen():
    This commit will use debug messages instead of using ASSERT when an error
    occurs after calling GetFileSize().
    
    Cc: Ruiyu Ni <ruiyu.ni@xxxxxxxxx>
    Contributed-under: TianoCore Contribution Agreement 1.1
    Signed-off-by: Hao Wu <hao.a.wu@xxxxxxxxx>
    Reviewed-by: Paulo Alcantara <palcantara@xxxxxxx>
    Reviewed-by: Star Zeng <star.zeng@xxxxxxxxx>

commit 6086569e7ee7f4787fc96c72d253174469058f11
Author: Hao Wu <hao.a.wu@xxxxxxxxx>
Date:   Sat Sep 29 13:03:50 2018 +0800

    MdeModulePkg/UdfDxe: Use error handling when fail to return LSN
    
    REF:https://bugzilla.tianocore.org/show_bug.cgi?id=1248
    
    This commit will refine the ASSERTs in function GetLongAdLsn() and
    GetAllocationDescriptorLsn() when the logical sector number cannot be
    returned due to unrecognized media format.
    
    Error handling logic will be used for those ASSERTs.
    
    Cc: Ruiyu Ni <ruiyu.ni@xxxxxxxxx>
    Contributed-under: TianoCore Contribution Agreement 1.1
    Signed-off-by: Hao Wu <hao.a.wu@xxxxxxxxx>
    Reviewed-by: Paulo Alcantara <palcantara@xxxxxxx>
    Reviewed-by: Star Zeng <star.zeng@xxxxxxxxx>

commit 5fb22f5920039393f74030c74c216517a131dbe0
Author: Hao Wu <hao.a.wu@xxxxxxxxx>
Date:   Tue Oct 9 11:03:27 2018 +0800

    MdeModulePkg/UdfDxe: ASSERT for false positives of NULL ptr deref
    
    This commit adds ASSERTs to address false positive reports of NULL
    pointer dereference issues raised from static analysis with regard to
    function ReadDirectoryEntry().
    
    Cc: Ruiyu Ni <ruiyu.ni@xxxxxxxxx>
    Contributed-under: TianoCore Contribution Agreement 1.1
    Signed-off-by: Hao Wu <hao.a.wu@xxxxxxxxx>
    Reviewed-by: Paulo Alcantara <palcantara@xxxxxxx>
    Reviewed-by: Star Zeng <star.zeng@xxxxxxxxx>

commit ebb12f514287696ed916d722a03eb49e7cab2ff0
Author: Hao Wu <hao.a.wu@xxxxxxxxx>
Date:   Fri Sep 28 20:12:23 2018 +0800

    MdeModulePkg/UdfDxe: Use error handling for memory allocation failure
    
    REF:https://bugzilla.tianocore.org/show_bug.cgi?id=1247
    
    For functions DuplicateFid() and DuplicateFe(), this commit will use error
    handling logic instead of ASSERTs for memory allocation failure.
    
    Cc: Ruiyu Ni <ruiyu.ni@xxxxxxxxx>
    Contributed-under: TianoCore Contribution Agreement 1.1
    Signed-off-by: Hao Wu <hao.a.wu@xxxxxxxxx>
    Reviewed-by: Paulo Alcantara <palcantara@xxxxxxx>
    Reviewed-by: Star Zeng <star.zeng@xxxxxxxxx>

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel

 


Rackspace

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