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

[ovmf baseline-only test] 67557: all pass



This run is configured for baseline tests only.

flight 67557 ovmf real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/67557/

Perfect :-)
All tests in this flight passed as required
version targeted for testing:
 ovmf                 7822a1d91d53e80525f571183a24d54488f5437f
baseline version:
 ovmf                 7503cd70fb864a5663edb121c9b2488b4c69e7f5

Last test of basis    67553  2016-08-18 05:22:29 Z    0 days
Testing same since    67557  2016-08-18 17:21:52 Z    0 days    1 attempts

------------------------------------------------------------
People who touched revisions under test:
  Eugene Cohen <eugene@xxxxxx>
  Jiaxin Wu <jiaxin.wu@xxxxxxxxx>
  Prince Agyeman <prince.agyeman@xxxxxxxxx>
  Star Zeng <star.zeng@xxxxxxxxx>
  Zhang Lubo <lubo.zhang@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                         pass    
 test-amd64-i386-xl-qemuu-ovmf-amd64                          pass    


------------------------------------------------------------
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.xs.citrite.net/~osstest/testlogs/logs

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


Push not applicable.

------------------------------------------------------------
commit 7822a1d91d53e80525f571183a24d54488f5437f
Author: Jiaxin Wu <jiaxin.wu@xxxxxxxxx>
Date:   Mon Aug 15 11:49:56 2016 +0800

    NetworkPkg/IpSecDxe: Fix wrong IKE header "FLAG" update
    
    *v2: update the commit log and refine the code comments.
    
    There are three kinds of IKE Exchange process:
    #1. Initial Exchange
    #2. CREATE_CHILD_SA_Exchange
    #3. Information Exchange
    
    The IKE header "FLAG" update is incorrect in #2 and #3 exchange,
    which may cause the continue session failure. This patch is used
    to correct the updates of IKE header "FLAG" according the RFC4306
    section 3.1.
    
    Cc: Ye Ting <ting.ye@xxxxxxxxx>
    Cc: Fu Siyuan <siyuan.fu@xxxxxxxxx>
    Cc: Zhang Lubo <lubo.zhang@xxxxxxxxx>
    Contributed-under: TianoCore Contribution Agreement 1.0
    Signed-off-by: Jiaxin Wu <jiaxin.wu@xxxxxxxxx>
    Reviewed-by: Ye Ting <ting.ye@xxxxxxxxx>

commit 40b83d6114f55ed975d9d632f0cd9679781c64e0
Author: Jiaxin Wu <jiaxin.wu@xxxxxxxxx>
Date:   Mon Aug 15 11:27:59 2016 +0800

    NetworkPkg/IpSecDxe: Fix UEFI IKE Initial Exchange failure
    
    *v2: update the commit log.
    
    IKE Initial Exchange message should cover below process:
               Initiator                    Responder
    Message1 HDR,SAil,KEi,Ni  ------>
    Message2                  <------   HDR,SArl,KEr,Nr,[CERTREQ]
    Message3 HDR,SK{}         ------>
    Message4                  <------   HDR,SK{}
    
    If Initial Exchange message is initiated by Linux IKE, it works well.
    But the failure will happen if it's initiated by UEFI IKE. This issue
    is caused by the no status check of NotifyCookiePayload.
    
    While parsing the IKEv2 packet for IKE_SA_INIT exchange, if the packet
    doesn't contain COOKIE Notify payload, EFI_INVALID_PARAMETER will be
    returned from Ikev2ParserNotifyCookiePayload(). Current implementation
    return this error status directly, then the session will be broken. The
    correct behavior should check this status. If no COOKIE Notify payload,
    initiator don't need to retry the IKE_SA_INIT.
    
    Cc: Ye Ting <ting.ye@xxxxxxxxx>
    Cc: Fu Siyuan <siyuan.fu@xxxxxxxxx>
    Cc: Zhang Lubo <lubo.zhang@xxxxxxxxx>
    Contributed-under: TianoCore Contribution Agreement 1.0
    Signed-off-by: Jiaxin Wu <jiaxin.wu@xxxxxxxxx>
    Reviewed-by: Ye Ting <ting.ye@xxxxxxxxx>

commit efe3f0099c0b986a01c2e8c7ca8ceacedcc965ba
Author: Prince Agyeman <prince.agyeman@xxxxxxxxx>
Date:   Wed Aug 17 10:55:22 2016 -0700

    CorebootPayloadPkg: fixed GCC49 and GCC5 hang in PeiCore
    
    Section alignment of .data in GCC49 and GCC5 are 0x40
    rather than 0x20 in GCC48 and below.
    This causes a hang in PeiCore.
    
    Contributed-under: TianoCore Contribution Agreement 1.0
    Signed-off-by: Prince Agyeman <prince.agyeman@xxxxxxxxx>
    Reviewed by: Maurice Ma <maurice.ma@xxxxxxxxx>

commit 617ef660f2e095310bd08d55248bd859908fecf2
Author: Prince Agyeman <prince.agyeman@xxxxxxxxx>
Date:   Wed Aug 17 09:32:12 2016 -0700

    CorebootPayloadPkg : Added MpInitLib to CorebootPayloadPkg.dsc
    
    MpInitLib is consumed by CpuDxe
    
    Contributed-under: TianoCore Contribution Agreement 1.0
    Signed-off-by: Prince Agyeman <prince.agyeman@xxxxxxxxx>
    Reviewed by: Maurice Ma <maurice.ma@xxxxxxxxx>

commit bd0656b5e2a57b0113d230c10866826d94301b5b
Author: Jiaxin Wu <jiaxin.wu@xxxxxxxxx>
Date:   Mon Aug 15 10:34:49 2016 +0800

    MdeModulePkg: Fix potential failure if UseDefaultAddress configured
    
    IpSb->Reconfig should not be set to TRUE to focal the reconfiguration
    during the policy changes from Static to DHCP. It's redundancy because
    the default router table and default addresses have been freed ahead (
    Detailed see Ip4Config2OnPolicyChanged() function). Otherwise, the
    potential failure will appear if UseDefaultAddress configured. Reproduce
    steps see below:
    
    #1. Set policy to DHCP.
    #2. If DHCP process is not complete yet, then run one APP to invoke UDP4
    Configure with "UseDefaultAddress = TRUE" (loop to call UDP4 Configure
    until Ip4Mode.IsConfigured changes to TRUE).
    #3. Even DHCP succeed but Ip4Mode.IsConfigured flag never set to TRUE
    
    Concrete analysis is as follows:
    In #1, the policy will be set to DHCP, and then Ip4Config2OnPolicyChanged()
    will be called. In this function, if "IpSb->Reconfig" flag is set to TRUE,
    the original "IpSb->DefaultInterface" will be abandoned/freed once the
    DHCP process finished.
    
    In #2, UDP4 Configure with "UseDefaultAddress = TRUE" is called, that means
    the default interface (IpSb->DefaultInterface) will be selected as current
    instance's interface.
    
    In #3, when DHCP process finished, the original DefaultInterface will be
    abandoned/freed because "IpSb->Reconfig" flag is true. Meanwhile, one new
    interface is assigned to "IpSb->DefaultInterface". This new interface is
    different to the original one assigned to the UDP4 Configured instance. So,
    even DHCP process succeed, the up caller will never have the chance to get
    it's truly status.
    
    Cc: Cohen Eugene <eugene@xxxxxx>
    Cc: Ye Ting <ting.ye@xxxxxxxxx>
    Cc: Fu Siyuan <siyuan.fu@xxxxxxxxx>
    Contributed-under: TianoCore Contribution Agreement 1.0
    Signed-off-by: Jiaxin Wu <jiaxin.wu@xxxxxxxxx>
    Tested-by: Eugene Cohen <eugene@xxxxxx>
    Reviewed-by: Ye Ting <ting.ye@xxxxxxxxx>

commit 3cb5b9970fbdf69362d1656f7e89808fc4f2bb2e
Author: Zhang Lubo <lubo.zhang@xxxxxxxxx>
Date:   Mon Aug 1 16:33:26 2016 +0800

    NetworkPkg: Fix assert issue in iSCSI driver
    
    The bug is caused by using already freed memory.
    If there is already an attempt and execute
    'reconnect -r' command, all the AttemptConfig structure
    will be freed, but the mCallbackInfo->Current is not
    configured as null and this pointer will be used again in
    IScsiFormExtractConfig.
    
    Contributed-under: TianoCore Contribution Agreement 1.0
    Signed-off-by: Zhang Lubo <lubo.zhang@xxxxxxxxx>
    Cc: Fu Siyuan <siyuan.fu@xxxxxxxxx>
    Cc: Ye Ting <ting.ye@xxxxxxxxx>
    Cc: Wu Jiaxin <jiaxin.wu@xxxxxxxxx>
    Reviewed-by: Ye Ting <ting.ye@xxxxxxxxx>
    Reviewed-by: Fu Siyuan <siyuan.fu@xxxxxxxxx>
    Reviewed-by: Wu Jiaxin <jiaxin.wu@xxxxxxxxx>

commit 79d909849c0e3d6a40989473accfee95e2c3660e
Author: Zhang Lubo <lubo.zhang@xxxxxxxxx>
Date:   Thu Aug 11 10:14:55 2016 +0800

    NetworkPkg: Refine codes of iSCSI driver
    
    The RSDT is only used when the bios need to support ACPI 1.0
    version. When change PcdAcpiExposedTableVersions to 0x3C, it
    will not support ACPI 1.0. The default is 0x3E.
    
    Contributed-under: TianoCore Contribution Agreement 1.0
    Signed-off-by: Zhang Lubo <lubo.zhang@xxxxxxxxx>
    Cc: Eric Dong <eric.dong@xxxxxxxxx>
    Cc: Ye Ting <ting.ye@xxxxxxxxx>
    Cc: Fu Siyuan <siyuan.fu@xxxxxxxxx>
    Reviewed-by: Ye Ting <ting.ye@xxxxxxxxx>
    Reviewed-by:  Eric Dong <eric.dong@xxxxxxxxx>

commit 998731099efd13edcd64cdd375a890a85f57ee6a
Author: Zhang Lubo <lubo.zhang@xxxxxxxxx>
Date:   Thu Aug 11 10:24:10 2016 +0800

    MdeModulePkg: Refine codes of iSCSI driver
    
    The RSDT is only used when the bios need to support ACPI 1.0
    version. When change PcdAcpiExposedTableVersions to 0x3C, it
    will not support ACPI 1.0. The default is 0x3E.
    
    Contributed-under: TianoCore Contribution Agreement 1.0
    Signed-off-by: Zhang Lubo <lubo.zhang@xxxxxxxxx>
    Cc: Eric Dong <eric.dong@xxxxxxxxx>
    Cc: Ye Ting <ting.ye@xxxxxxxxx>
    Cc: Fu Siyuan <siyuan.fu@xxxxxxxxx>
    Reviewed-by: Ye Ting <ting.ye@xxxxxxxxx>
    Reviewed-by:  Eric Dong <eric.dong@xxxxxxxxx>

commit a012df5ec643a0c08c2b723a02919a5c9373ca74
Author: Star Zeng <star.zeng@xxxxxxxxx>
Date:   Wed Aug 17 10:08:31 2016 +0800

    PcAtChipsetPkg AcpiTimerLib: Wait 363 ACPI timer counts to get TSC Freq
    
    Compute the number of ticks to wait to measure TSC frequency.
    Instead of (ACPI_TIMER_FREQUENCY / 10000) = 357 and 357 * 10000 = 3570000,
    use 363 * 9861 = 3579543 Hz which is within 2 Hz of ACPI_TIMER_FREQUENCY.
    363 counts is a calibration time of 101.4 uS.
    
    The idea comes from Michael and Paolo.
    
    Cc: Michael D Kinney <michael.d.kinney@xxxxxxxxx>
    Cc: Liming Gao <liming.gao@xxxxxxxxx>
    Cc: Paolo Bonzini <pbonzini@xxxxxxxxxx>
    Cc: Paul A Lohr <paul.a.lohr@xxxxxxxxx>
    Contributed-under: TianoCore Contribution Agreement 1.0
    Signed-off-by: Star Zeng <star.zeng@xxxxxxxxx>
    Reviewed-by: Paolo Bonzini <pbonzini@xxxxxxxxxx>
    Reviewed-by: Michael D Kinney <michael.d.kinney@xxxxxxxxx>

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

 


Rackspace

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