|
[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
|
 |
Lists.xenproject.org is hosted with RackSpace, monitoring our |