Re: [edk2] [Patch] NetworkPkg: Need update Http token status while timeout happened

[Wu, Jiaxin]

Siyuan, 
I agree Http->Response() is designed to a unblocking interface. Actually, 
current implementation is blocking one. So, handling EFI_TIMEOUT status in the 
token (HttpBootDxe driver) or return directly, both of them are fine to me . 
But Tcp->Cancel() still should be necessary calling if we handle the case in 
HttpBootDxe driver. 

Thanks.
Jiaxin

> -Original Message-
> From: Fu, Siyuan
> Sent: Tuesday, May 24, 2016 9:17 AM
> To: Wu, Jiaxin ; edk2-devel@lists.01.org
> Cc: Ye, Ting ; Gary Lin ; Samer El-Haj-
> Mahmoud ; Hegde Nagaraj P 
> Subject: RE: [Patch] NetworkPkg: Need update Http token status while
> timeout happened
> 
> Hi, Jiaxin
> 
> The Http->Response() is a unblocking interface, that the function return
> status should be SUCCESS once the token has been queued to the driver.
> Then if there is an error later, the Status in the token should be updated and
> Event will be signaled.
> So I think the original code in HTTP driver does make sense, but the HTTP
> boot driver function has bug that, when download the message body, it
> should also check the Status in the token, not only the function.
> 
> Best Regards
> Siyuan
> 
> 
> > -Original Message-
> > From: Wu, Jiaxin
> > Sent: Friday, May 20, 2016 3:24 PM
> > To: edk2-devel@lists.01.org
> > Cc: Ye, Ting ; Fu, Siyuan ;
> > Gary Lin ; Samer El-Haj-Mahmoud ;
> Hegde
> > Nagaraj P 
> > Subject: [Patch] NetworkPkg: Need update Http token status while
> > timeout happened
> >
> > Http token status should be updated to EFI_TIMEOUT while timeout
> > happened by any abruptly interrupted (e.g. network disconnection,
> > cable plug/unplug...). Otherwise, HttpBootDxe driver will continue
> > treat it as no error happened, and its ReceivedSize will be updated to
> > ContentLength directly. Moreover, If download image type is RAM Disk,
> > the corresponding info will be registered to system.
> >
> > Cc: Ye Ting 
> > Cc: Fu Siyuan 
> > Cc: Gary Lin 
> > Cc: Samer El-Haj-Mahmoud 
> > Cc: Hegde Nagaraj P 
> > Contributed-under: TianoCore Contribution Agreement 1.0
> > Signed-off-by: Jiaxin Wu 
> > ---
> >  NetworkPkg/HttpDxe/HttpImpl.c  |  3 +++
> > NetworkPkg/HttpDxe/HttpProto.c | 16 +++-
> >  2 files changed, 14 insertions(+), 5 deletions(-)
> >
> > diff --git a/NetworkPkg/HttpDxe/HttpImpl.c
> > b/NetworkPkg/HttpDxe/HttpImpl.c index f4ae28a..05a96e9 100644
> > --- a/NetworkPkg/HttpDxe/HttpImpl.c
> > +++ b/NetworkPkg/HttpDxe/HttpImpl.c
> > @@ -1259,10 +1259,13 @@ Exit:
> >
> >  Error2:
> >NetMapInsertHead (>TxTokens, ValueInItem->HttpToken,
> > ValueInItem);
> >
> >  Error:
> > +
> > +  HttpCloseConnection (HttpInstance);
> > +
> >HttpTcpTokenCleanup (Wrap);
> >
> >if (HttpHeaders != NULL) {
> >  FreePool (HttpHeaders);
> >}
> > diff --git a/NetworkPkg/HttpDxe/HttpProto.c
> > b/NetworkPkg/HttpDxe/HttpProto.c index afa7fe4..c3608c0 100644
> > --- a/NetworkPkg/HttpDxe/HttpProto.c
> > +++ b/NetworkPkg/HttpDxe/HttpProto.c
> > @@ -1,9 +1,9 @@
> >  /** @file
> >Miscellaneous routines for HttpDxe driver.
> >
> > -Copyright (c) 2015, Intel Corporation. All rights reserved.
> > +Copyright (c) 2015 - 2016, Intel Corporation. All rights
> > +reserved.
> >  (C) Copyright 2016 Hewlett Packard Enterprise Development LP
> > This program and the accompanying materials  are licensed and made
> > available under the terms and conditions of the BSD License  which
> > accompanies this distribution.  The full text of the license may be
> > found at  http://opensource.org/licenses/bsd-license.php
> > @@ -1605,10 +1605,11 @@ HttpTcpReceiveHeader (
> >while (!HttpInstance->IsRxDone && ((Timeout == NULL) ||
> > EFI_ERROR (gBS->CheckEvent (Timeout {
> >  Tcp4->Poll (Tcp4);
> >}
> >
> >if (!HttpInstance->IsRxDone) {
> > +Tcp4->Cancel (Tcp4, >CompletionToken);
> >  gBS->CloseEvent (Rx4Token->CompletionToken.Event);
> >  Rx4Token->CompletionToken.Status = EFI_TIMEOUT;
> >}
> >
> >Status = Rx4Token->CompletionToken.Status; @@ -1671,10 +1672,11
> > @@ HttpTcpReceiveHeader (
> >while (!HttpInstance->IsRxDone && ((Timeout == NULL) ||
> > EFI_ERROR (gBS->CheckEvent (Timeout {
> >  Tcp6->Poll (Tcp6);
> >}
> >
> >if (!HttpInstance->IsRxDone) {
> > +Tcp6->Cancel (Tcp6, >CompletionToken);
> >  gBS->CloseEvent (Rx6Token->CompletionToken.Event);
> >  Rx6Token->CompletionToken.Status = EFI_TIMEOUT;
> >}
> >
> >Status = Rx6Token->CompletionToken.Status; @@ -1745,11 +1747,12
> > @@ HttpTcpReceiveBody (
> >HTTP_PROTOCOL *HttpInstance;
> >EFI_TCP6_PROTOCOL *Tcp6;
> > 

Re: [edk2] [BaseTools] PACKAGES_PATH issue?

[Andrew Fish]

Liming,

I finally figured out what was causing the issue. It looks like it is a DEFINE 
combined with PACKAGES_PATH seems to cause the issue in the FDF file. 

The DSC file is still set to OvmfPkg/AcpiTables/AcpiTables.inf, I'm not sure if 
that is also required. It seems like if the DEFINE is relative to WORKSPACE 
everything works, if it has to be processed with PACKAGES_PATH that seems to 
bring out the issue. 

~/work/src/edk2(master)>OvmfPkg/build.sh
...
build.py...
 : error 7000: Failed to execute command
GenFds -f /Users/andrewfish/work/src/edk2/OvmfPkg/OvmfPkgX64.fdf 
--conf=/Users/andrewfish/work/src/edk2/Conf -o 
/Users/andrewfish/work/src/edk2/Build/OvmfX64/DEBUG_XCODE5 -t XCODE5 -b DEBUG 
-p /Users/andrewfish/work/src/edk2/OvmfPkg/OvmfPkgX64.dsc -a X64 -D 
"EFI_SOURCE=/Users/andrewfish/work/src/edk2/EdkCompatibilityPkg" -D 
"EDK_SOURCE=/Users/andrewfish/work/src/edk2/EdkCompatibilityPkg" -D 
"TOOL_CHAIN_TAG=XCODE5" -D "TOOLCHAIN=XCODE5" -D "TARGET=DEBUG" -D 
"WORKSPACE=/Users/andrewfish/work/src/edk2" -D 
"EDK_TOOLS_PATH=/Users/andrewfish/work/src/edk2/BaseTools" -D "ARCH=X64" -D 
"ECP_SOURCE=/Users/andrewfish/work/src/edk2/EdkCompatibilityPkg" 
[/Users/andrewfish/work/src/edk2]


~/work/src/edk2(master)>export PACKAGES_PATH="$WORKSPACE/OvmfPkg"
~/work/src/edk2(master)>git diff OvmfPkg/
diff --git a/OvmfPkg/OvmfPkgX64.fdf b/OvmfPkg/OvmfPkgX64.fdf
index 84a40a3..7094648 100644
--- a/OvmfPkg/OvmfPkgX64.fdf
+++ b/OvmfPkg/OvmfPkgX64.fdf
@@ -17,7 +17,7 @@
 
 [Defines]
 !include OvmfPkg.fdf.inc
-
+DEFINE ACPI = AcpiTables
 #
 # Build the variable store and the firmware code as one unified flash device
 # image.
@@ -272,7 +272,7 @@ INF  OvmfPkg/SmbiosPlatformDxe/SmbiosPlatformDxe.inf
 
 INF  MdeModulePkg/Universal/Acpi/AcpiTableDxe/AcpiTableDxe.inf
 INF  OvmfPkg/AcpiPlatformDxe/AcpiPlatformDxe.inf
-INF  RuleOverride=ACPITABLE OvmfPkg/AcpiTables/AcpiTables.inf
+INF  RuleOverride=ACPITABLE $(ACPI)/AcpiTables.inf
 INF  MdeModulePkg/Universal/Acpi/S3SaveStateDxe/S3SaveStateDxe.inf
 INF  
MdeModulePkg/Universal/Acpi/BootScriptExecutorDxe/BootScriptExecutorDxe.inf
 
Thanks,

Andrew Fish


> On May 23, 2016, at 8:34 AM, Andrew Fish  wrote:
> 
> 
>> On May 23, 2016, at 5:52 AM, Gao, Liming  wrote:
>> 
>> Andrew:
>>  The buid output path is always in $(WORKSPACE)\Build directory.
> 
> You mean the path in $(WORKSPACE)\Build does not match the WORKSPACE relative 
> path of the file? That seems to imply that code from different packages could 
> get mixed together in the $(WORKSPACE)\Build output. That seems very very 
> confusing to the user. 
> 
>> It is not related to $(PACKAGES_PATH). PACKAGES_PATH is designed to search 
>> source files, doesn’t impact build output directory. 
>> 
> 
> That is not what I was seeing? I'm seeing $(WORKSPACE) relative paths in 
> $(WORKSPACE)\Build and then I'm see logic that is not using the full path to 
> search for files? 
> 
> I have output that looks like: 
> Build/X/DEBUG_XCODE5/X64/edk2/MdeModulePkg/Universal/Acpi/AcpiTableDxe/AcpiTableDxe/OUTPUT/
> But I saw the Python searching a location like this for files:
> Build/X/DEBUG_XCODE5/X64/MdeModulePkg/Universal/Acpi/AcpiTableDxe/AcpiTableDxe/OUTPUT/
> 
> Thanks,
> 
> Andrew Fish
> 
>> I try Ovmf platform. Its AcpiTables can be found and be built into FFS.
>> 
>> Thanks
>> Liming <>
>> <>From: af...@apple.com  [mailto:af...@apple.com 
>> ] 
>> Sent: Saturday, May 21, 2016 8:21 AM
>> To: Gao, Liming >
>> Cc: edk2-devel >
>> Subject: Re: [edk2] [BaseTools] PACKAGES_PATH issue?
>> 
>> Liming,
>> 
>> I found one more issues. My ACPI tables are breaking the build. It looks 
>> like the failure is no input files. What I've figured out in GetFileList() 
>> is FfsInf.EfiOutputPath is constructed incorrectly. The path does not 
>> included the prefix from the PACKAGES_PATH and thus the directory does not 
>> exist and no files are found. It looks like the issue is 
>> __GetEFIOutPutPath__() as it is using self.InfFileName and that has not been 
>> adjusted for PACKAGES_PATH?
>> 
>> Thanks,
>> 
>> Andrew Fish
>> 
>>> On May 20, 2016, at 1:34 AM, Gao, Liming wrote:
>>> 
>>> Andrew:
>>> Thanks for your point out. It is bug. Your fix is correct. I will send the 
>>> patch for it. 
>>> 
>>> Thanks
>>> Liming
 -Original Message-
 From: af...@apple.com  [mailto:af...@apple.com 
 ]
 Sent: Friday, May 20, 2016 1:25 PM
 To: Gao, Liming 
 Cc: edk2-devel 
 Subject: Re: [edk2] [BaseTools] RuleOverride = BINARY code location?
 
 
> On May 19, 2016, at 8:18 PM, Gao, Liming wrote:
> 
> Thanks Andrew. I will continue to investigate it.
> 
 
>>> F = 'FileNoExtention'
>>> os.path.splitext(F)[1]
 ''
>>> '' in '.out'
 

Re: [edk2] [Patch] NetworkPkg: update code for NULL pointer check.

[Wu, Jiaxin]

Reviewed-By: Wu Jiaxin 


> -Original Message-
> From: Fu, Siyuan
> Sent: Monday, May 23, 2016 5:49 PM
> To: edk2-devel@lists.01.org
> Cc: Ye, Ting ; Wu, Jiaxin 
> Subject: [Patch] NetworkPkg: update code for NULL pointer check.
> 
> This patch updates the HTTP driver to initialize the local variable for NULL 
> and
> check the NULL pointer before dereference it.
> 
> Cc: Ye Ting 
> Cc: Wu Jiaxin 
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Fu Siyuan 
> ---
>  NetworkPkg/HttpDxe/HttpImpl.c | 17 ++---
>  1 file changed, 10 insertions(+), 7 deletions(-)
> 
> diff --git a/NetworkPkg/HttpDxe/HttpImpl.c
> b/NetworkPkg/HttpDxe/HttpImpl.c index f4ae28a..7ee6613 100644
> --- a/NetworkPkg/HttpDxe/HttpImpl.c
> +++ b/NetworkPkg/HttpDxe/HttpImpl.c
> @@ -253,6 +253,7 @@ EfiHttpRequest (
>// Initializations
>//
>Url = NULL;
> +  UrlParser = NULL;
>HostName = NULL;
>RequestMsg = NULL;
>HostNameStr = NULL;
> @@ -1063,7 +1064,7 @@ HttpResponseWorker (
>  if (SizeofHeaders != 0) {
>HeaderTmp = AllocateZeroPool (SizeofHeaders);
>if (HeaderTmp == NULL) {
> -goto Error;
> +goto Error2;
>}
> 
>CopyMem (HeaderTmp, Tmp, SizeofHeaders); @@ -1075,7 +1076,7 @@
> HttpResponseWorker (
>//
>if (mHttpUtilities == NULL) {
>  Status = EFI_NOT_READY;
> -goto Error;
> +goto Error2;
>}
> 
>//
> @@ -1089,7 +1090,7 @@ HttpResponseWorker (
>   >HeaderCount
>   );
>if (EFI_ERROR (Status)) {
> -goto Error;
> +goto Error2;
>}
> 
>FreePool (HttpHeaders);
> @@ -1214,7 +1215,7 @@ HttpResponseWorker (
>  >TimeoutEvent
>  );
>  if (EFI_ERROR (Status)) {
> -  goto Error;
> +  goto Error2;
>  }
>}
> 
> @@ -1223,7 +1224,7 @@ HttpResponseWorker (
>//
>Status = gBS->SetTimer (HttpInstance->TimeoutEvent, TimerRelative,
> HTTP_RESPONSE_TIMEOUT * TICKS_PER_SECOND);
>if (EFI_ERROR (Status)) {
> -goto Error;
> +goto Error2;
>}
> 
>//
> @@ -1234,7 +1235,7 @@ HttpResponseWorker (
>gBS->SetTimer (HttpInstance->TimeoutEvent, TimerCancel, 0);
> 
>if (EFI_ERROR (Status)) {
> -goto Error;
> +goto Error2;
>}
> 
>FreePool (Wrap);
> @@ -1258,7 +1259,9 @@ Exit:
>return Status;
> 
>  Error2:
> -  NetMapInsertHead (>TxTokens, ValueInItem->HttpToken,
> ValueInItem);
> +  if (ValueInItem != NULL) {
> +NetMapInsertHead (>TxTokens, ValueInItem->HttpToken,
> + ValueInItem);  }
> 
>  Error:
>HttpTcpTokenCleanup (Wrap);
> --
> 2.7.4.windows.1

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH] MdeModulePkg RamDiskDxe: VALID_ARCH cleanup to list supported options

[Tian, Feng]

Thomas,

Usually it's verified and added by Arm owner:-) But yes, I also think Hao can 
add it at this time.

Thanks
Feng

-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Palmer, 
Thomas
Sent: Tuesday, May 24, 2016 10:19 AM
To: Wu, Hao A ; edk2-devel@lists.01.org; Tian, Feng 

Subject: Re: [edk2] [PATCH] MdeModulePkg RamDiskDxe: VALID_ARCH cleanup to list 
supported options

No AARCH64 ?

Thomas

-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Hao Wu
Sent: Monday, May 23, 2016 8:59 PM
To: edk2-devel@lists.01.org; feng.t...@intel.com
Cc: Hao Wu 
Subject: [edk2] [PATCH] MdeModulePkg RamDiskDxe: VALID_ARCH cleanup to list 
supported options

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Hao Wu 
---
 MdeModulePkg/MdeModulePkg.dsc | 2 +-
 MdeModulePkg/Universal/Disk/RamDiskDxe/RamDiskDxe.inf | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/MdeModulePkg/MdeModulePkg.dsc b/MdeModulePkg/MdeModulePkg.dsc 
index 936f46d..abce62d 100644
--- a/MdeModulePkg/MdeModulePkg.dsc
+++ b/MdeModulePkg/MdeModulePkg.dsc
@@ -330,7 +330,6 @@
   MdeModulePkg/Universal/Disk/PartitionDxe/PartitionDxe.inf
   MdeModulePkg/Universal/Disk/UnicodeCollation/EnglishDxe/EnglishDxe.inf
   MdeModulePkg/Universal/Disk/CdExpressPei/CdExpressPei.inf
-  MdeModulePkg/Universal/Disk/RamDiskDxe/RamDiskDxe.inf
   MdeModulePkg/Universal/DriverSampleDxe/DriverSampleDxe.inf
   MdeModulePkg/Universal/HiiDatabaseDxe/HiiDatabaseDxe.inf
   
MdeModulePkg/Universal/MemoryTest/GenericMemoryTestDxe/GenericMemoryTestDxe.inf
@@ -449,6 +448,7 @@
   MdeModulePkg/Universal/FaultTolerantWriteDxe/FaultTolerantWriteSmmDxe.inf
   MdeModulePkg/Universal/RegularExpressionDxe/RegularExpressionDxe.inf
   
MdeModulePkg/Universal/SmmCommunicationBufferDxe/SmmCommunicationBufferDxe.inf
+  MdeModulePkg/Universal/Disk/RamDiskDxe/RamDiskDxe.inf
 
 [Components.X64]
   MdeModulePkg/Universal/CapsulePei/CapsuleX64.inf
diff --git a/MdeModulePkg/Universal/Disk/RamDiskDxe/RamDiskDxe.inf 
b/MdeModulePkg/Universal/Disk/RamDiskDxe/RamDiskDxe.inf
index d1eb429..f513e85 100644
--- a/MdeModulePkg/Universal/Disk/RamDiskDxe/RamDiskDxe.inf
+++ b/MdeModulePkg/Universal/Disk/RamDiskDxe/RamDiskDxe.inf
@@ -26,7 +26,7 @@
 #
 # The following information is for reference only and not required by the 
build tools.
 #
-#  VALID_ARCHITECTURES  = IA32 X64 IPF EBC
+#  VALID_ARCHITECTURES  = IA32 X64
 #
 
 [Sources]
--
1.9.5.msysgit.0

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] TCP4: Failure to Acknowledge due to DPC Dispatch Nesting

[Fu, Siyuan]

Hi, Eugene

Thanks for your detail analysis to help understanding the problem. We think 
it's a bug about the DelayedAck flag update in TCP driver, not in DPC, and here 
is the detail.

At the time the TcpTicking() is running, the under layer (MnpSystemPoll) also 
has a timer to receive network packets and queue them to the DPC. In you 
described case, when TcpTickingDpc() calls TcpSendAck() to send a delayed ACK 
to the remote, it first calls TcpTransmitSegment to transmit the ACK (point 1), 
then clear the TCP_CTRL_ACK_NOW and set DelayedAck to zero (point 2) as below.

   TcpTicking
  TcpSendAck
 TcpTransmitSegment (#1)
 Clear Tcb's flag (#2)

But there are some DispatchDpc between #1 and #2, it not only transmited the 
ACK message to the under layer driver, but also invoked these MNP queued DPC 
and delivered these packets to the upper layer driver (TCP), then set the Tcb's 
flag. So things come to:

   TcpTicking
  TcpSendAck
 TcpTransmitSegment (#1)
DispatchDpc
   New 
TCP packet arrived, and set the Tcb's flag (#3)
 Clear Tcb's flag (#2)

In another word, the TcpSendAck() function transmit the packet first, then 
clear the flag later, while the flag may be set by the incoming data during the 
transmit, so the clear operation is incorrect. The correct to operate the flag 
is to set the flag first, then make transmit. In this way, if the transmit 
operation invoke the DPC and deliver some new data to upper layer, the new set 
flag won't be override.

Best Regards
Siyuan

From: Ye, Ting
Sent: Tuesday, May 24, 2016 9:23 AM
To: Cohen, Eugene ; edk2-devel@lists.01.org; Fu, Siyuan 
; Wu, Jiaxin ; Zhang, Lubo 

Cc: Vaughn, Gregory (IPG LJ Printer Lab) 
Subject: RE: TCP4: Failure to Acknowledge due to DPC Dispatch Nesting

Hi Eugene,

Thanks for reporting this. We saw your email yesterday, though we need some 
time to investigate the issue. We will reply as soon as we have a conclusion.

Thanks again,
Ting

-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Cohen, 
Eugene
Sent: Monday, May 23, 2016 10:07 PM
To: edk2-devel@lists.01.org; Fu, Siyuan 
>; Wu, Jiaxin 
>; Zhang, Lubo 
>
Cc: Vaughn, Gregory (IPG LJ Printer Lab) 
>
Subject: Re: [edk2] TCP4: Failure to Acknowledge due to DPC Dispatch Nesting

Adding some maintainers...

We are looking forward to a response.

Thanks,

Eugene

> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
> Cohen, Eugene
> Sent: Friday, May 20, 2016 2:11 PM
> To: edk2-devel@lists.01.org
> Cc: Vaughn, Gregory (IPG LJ Printer Lab) 
> >
> Subject: [edk2] TCP4: Failure to Acknowledge due to DPC Dispatch
> Nesting
>
>
> We have isolated a problem where the TCP4 driver fails to acknowledge
> received data under certain circumstances.
>
> Background on DPCs: The DPC mechanism allows functions to be called at
> a later point in time at a requested TPL level.  Functions are queued
> through the DPC Protocol's QueueDpc interface.  DPCs are dispatched
> anytime a module calls the DispatchDpc function in the DPC protocol.
> The dispatch process will execute all queued DPCs that were registered
> to execute at or above the caller's TPL level (e.g. if caller is at
> TPL_CALLBACK the DPC dispatch will execute anything between CALLBACK and 
> HIGH_LEVEL).
>
> The stack depends on DispatchDpc being called at appropriate
> preemption points to advance packet processing.  The dispatch function
> is called in multiple layers as you can see by searching for
> DispatchDpc with calls originating from ArpDxe, Ip4Dxe, MnpDxe,
> Udp4Dxe, UefiPxeBcDxe, DnsDxe, HttpDxe, Ip6Dxe and Udp6Dxe.
>
> Currently it's possible for DPC dispatching to occur in a nested manner.
> Imagine a case where an upper network stack layer queues a DPC (for
> example the TCP layer's TcpTickingDpc) and in the DPC handler it makes
> use of lower layers (like sending a packet through IP+MNP).  As part
> of packet processing these lower layers will call DispatchDpc
> resulting in nested DPCs execution.
>
>
> Here's an example of the DPC nesting, the indent level indicates the
> level of nesting for the DPC
>
> TcpTicking
> DpcDispatchDpc TPL=CALLBACK
> 

Re: [edk2] [PATCH] MdeModulePkg RamDiskDxe: VALID_ARCH cleanup to list supported options

[Palmer, Thomas]

No AARCH64 ?

Thomas

-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Hao Wu
Sent: Monday, May 23, 2016 8:59 PM
To: edk2-devel@lists.01.org; feng.t...@intel.com
Cc: Hao Wu 
Subject: [edk2] [PATCH] MdeModulePkg RamDiskDxe: VALID_ARCH cleanup to list 
supported options

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Hao Wu 
---
 MdeModulePkg/MdeModulePkg.dsc | 2 +-
 MdeModulePkg/Universal/Disk/RamDiskDxe/RamDiskDxe.inf | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/MdeModulePkg/MdeModulePkg.dsc b/MdeModulePkg/MdeModulePkg.dsc 
index 936f46d..abce62d 100644
--- a/MdeModulePkg/MdeModulePkg.dsc
+++ b/MdeModulePkg/MdeModulePkg.dsc
@@ -330,7 +330,6 @@
   MdeModulePkg/Universal/Disk/PartitionDxe/PartitionDxe.inf
   MdeModulePkg/Universal/Disk/UnicodeCollation/EnglishDxe/EnglishDxe.inf
   MdeModulePkg/Universal/Disk/CdExpressPei/CdExpressPei.inf
-  MdeModulePkg/Universal/Disk/RamDiskDxe/RamDiskDxe.inf
   MdeModulePkg/Universal/DriverSampleDxe/DriverSampleDxe.inf
   MdeModulePkg/Universal/HiiDatabaseDxe/HiiDatabaseDxe.inf
   
MdeModulePkg/Universal/MemoryTest/GenericMemoryTestDxe/GenericMemoryTestDxe.inf
@@ -449,6 +448,7 @@
   MdeModulePkg/Universal/FaultTolerantWriteDxe/FaultTolerantWriteSmmDxe.inf
   MdeModulePkg/Universal/RegularExpressionDxe/RegularExpressionDxe.inf
   
MdeModulePkg/Universal/SmmCommunicationBufferDxe/SmmCommunicationBufferDxe.inf
+  MdeModulePkg/Universal/Disk/RamDiskDxe/RamDiskDxe.inf
 
 [Components.X64]
   MdeModulePkg/Universal/CapsulePei/CapsuleX64.inf
diff --git a/MdeModulePkg/Universal/Disk/RamDiskDxe/RamDiskDxe.inf 
b/MdeModulePkg/Universal/Disk/RamDiskDxe/RamDiskDxe.inf
index d1eb429..f513e85 100644
--- a/MdeModulePkg/Universal/Disk/RamDiskDxe/RamDiskDxe.inf
+++ b/MdeModulePkg/Universal/Disk/RamDiskDxe/RamDiskDxe.inf
@@ -26,7 +26,7 @@
 #
 # The following information is for reference only and not required by the 
build tools.
 #
-#  VALID_ARCHITECTURES  = IA32 X64 IPF EBC
+#  VALID_ARCHITECTURES  = IA32 X64
 #
 
 [Sources]
--
1.9.5.msysgit.0

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

[edk2] [PATCH] MdeModulePkg RamDiskDxe: VALID_ARCH cleanup to list supported options

[Hao Wu]

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Hao Wu 
---
 MdeModulePkg/MdeModulePkg.dsc | 2 +-
 MdeModulePkg/Universal/Disk/RamDiskDxe/RamDiskDxe.inf | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/MdeModulePkg/MdeModulePkg.dsc b/MdeModulePkg/MdeModulePkg.dsc
index 936f46d..abce62d 100644
--- a/MdeModulePkg/MdeModulePkg.dsc
+++ b/MdeModulePkg/MdeModulePkg.dsc
@@ -330,7 +330,6 @@
   MdeModulePkg/Universal/Disk/PartitionDxe/PartitionDxe.inf
   MdeModulePkg/Universal/Disk/UnicodeCollation/EnglishDxe/EnglishDxe.inf
   MdeModulePkg/Universal/Disk/CdExpressPei/CdExpressPei.inf
-  MdeModulePkg/Universal/Disk/RamDiskDxe/RamDiskDxe.inf
   MdeModulePkg/Universal/DriverSampleDxe/DriverSampleDxe.inf
   MdeModulePkg/Universal/HiiDatabaseDxe/HiiDatabaseDxe.inf
   
MdeModulePkg/Universal/MemoryTest/GenericMemoryTestDxe/GenericMemoryTestDxe.inf
@@ -449,6 +448,7 @@
   MdeModulePkg/Universal/FaultTolerantWriteDxe/FaultTolerantWriteSmmDxe.inf
   MdeModulePkg/Universal/RegularExpressionDxe/RegularExpressionDxe.inf
   
MdeModulePkg/Universal/SmmCommunicationBufferDxe/SmmCommunicationBufferDxe.inf
+  MdeModulePkg/Universal/Disk/RamDiskDxe/RamDiskDxe.inf
 
 [Components.X64]
   MdeModulePkg/Universal/CapsulePei/CapsuleX64.inf
diff --git a/MdeModulePkg/Universal/Disk/RamDiskDxe/RamDiskDxe.inf 
b/MdeModulePkg/Universal/Disk/RamDiskDxe/RamDiskDxe.inf
index d1eb429..f513e85 100644
--- a/MdeModulePkg/Universal/Disk/RamDiskDxe/RamDiskDxe.inf
+++ b/MdeModulePkg/Universal/Disk/RamDiskDxe/RamDiskDxe.inf
@@ -26,7 +26,7 @@
 #
 # The following information is for reference only and not required by the 
build tools.
 #
-#  VALID_ARCHITECTURES  = IA32 X64 IPF EBC
+#  VALID_ARCHITECTURES  = IA32 X64
 #
 
 [Sources]
-- 
1.9.5.msysgit.0

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [Patch] NetworkPkg: update code for NULL pointer check.

[Ye, Ting]

Reviewed-by: Ye Ting  

-Original Message-
From: Fu, Siyuan 
Sent: Monday, May 23, 2016 11:06 AM
To: edk2-devel@lists.01.org
Cc: Ye; Ye, Ting ; Wu; Wu, Jiaxin 
Subject: [Patch] NetworkPkg: update code for NULL pointer check.

This patch updates the HTTP driver to initialize the local variable for NULL 
and check the NULL pointer before dereference it.

Cc: Ye, Ting 
Cc: Wu, Jiaxin 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Fu Siyuan 
---
 NetworkPkg/HttpDxe/HttpImpl.c | 17 ++---
 1 file changed, 10 insertions(+), 7 deletions(-)

diff --git a/NetworkPkg/HttpDxe/HttpImpl.c b/NetworkPkg/HttpDxe/HttpImpl.c 
index f4ae28a..7ee6613 100644
--- a/NetworkPkg/HttpDxe/HttpImpl.c
+++ b/NetworkPkg/HttpDxe/HttpImpl.c
@@ -253,6 +253,7 @@ EfiHttpRequest (
   // Initializations
   //
   Url = NULL;
+  UrlParser = NULL;
   HostName = NULL;
   RequestMsg = NULL;
   HostNameStr = NULL;
@@ -1063,7 +1064,7 @@ HttpResponseWorker (
 if (SizeofHeaders != 0) {
   HeaderTmp = AllocateZeroPool (SizeofHeaders);
   if (HeaderTmp == NULL) {
-goto Error;
+goto Error2;
   }
 
   CopyMem (HeaderTmp, Tmp, SizeofHeaders); @@ -1075,7 +1076,7 @@ 
HttpResponseWorker (
   //
   if (mHttpUtilities == NULL) {
 Status = EFI_NOT_READY;
-goto Error;
+goto Error2;
   }
 
   //
@@ -1089,7 +1090,7 @@ HttpResponseWorker (
  >HeaderCount
  );
   if (EFI_ERROR (Status)) {
-goto Error;
+goto Error2;
   }
 
   FreePool (HttpHeaders);
@@ -1214,7 +1215,7 @@ HttpResponseWorker (
 >TimeoutEvent
 );
 if (EFI_ERROR (Status)) {
-  goto Error;
+  goto Error2;
 }
   }
 
@@ -1223,7 +1224,7 @@ HttpResponseWorker (
   //
   Status = gBS->SetTimer (HttpInstance->TimeoutEvent, TimerRelative, 
HTTP_RESPONSE_TIMEOUT * TICKS_PER_SECOND);
   if (EFI_ERROR (Status)) {
-goto Error;
+goto Error2;
   }
 
   //
@@ -1234,7 +1235,7 @@ HttpResponseWorker (
   gBS->SetTimer (HttpInstance->TimeoutEvent, TimerCancel, 0);
 
   if (EFI_ERROR (Status)) {
-goto Error;
+goto Error2;
   }
 
   FreePool (Wrap);
@@ -1258,7 +1259,9 @@ Exit:
   return Status;
 
 Error2:
-  NetMapInsertHead (>TxTokens, ValueInItem->HttpToken, 
ValueInItem);
+  if (ValueInItem != NULL) {
+NetMapInsertHead (>TxTokens, ValueInItem->HttpToken, 
+ ValueInItem);  }
 
 Error:
   HttpTcpTokenCleanup (Wrap);
--
2.7.4.windows.1

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [RFC] Email tags for Bugzilla and administrative events

[Mangefeste, Tony]

The server had a bit of a hiccup, but it's back :)

> -Original Message-
> From: Laszlo Ersek [mailto:ler...@redhat.com]
> Sent: Monday, May 23, 2016 2:57 PM
> To: Mangefeste, Tony 
> Cc: edk2-devel@lists.01.org 
> Subject: Re: [edk2] [RFC] Email tags for Bugzilla and administrative events
> 
> On 05/23/16 20:33, Mangefeste, Tony wrote:
> > Folks,
> >
> > I'm ramping up work on deploying the Bugzilla server for our
> > community.  A few things you will begin to see, and your comments are
> > appreciated on the below.
> >
> > 1. I'm going to send updates to the list.  I'm going to add the tag
> > [INFO] to the subject line to pass down information to the community.
> > This is going to include some information related to bugzilla, or
> > anything else community related.
> >
> > 2. Our bugzilla server is being hosted by ACG Multimedia.  They are a
> > vendor contracted by Intel, managed by me, and they own the physical
> > hardware that is hosting the server.  Data submitted to our community
> > bugzilla server does not reside on Intel machines, and as such only
> > content pertaining to Tianocore should be added to our server.
> >
> > 3. The server URL is (https://tianocore.acgmultimedia.com).  At this
> > time I'd like to ask all maintainers to please logon and create an
> > account.  I will use this information to assign package maintainers to
> > specific security groups, email and such.
> 
> At first the server threw different error messages at me ("Forbidden"
> and something about not finding "Auth.pm" or similar). Ultimately I managed
> to enter my email address, but the confirmation email doesn't seem to
> arrive. (It might arrive later I guess.)
> 
> > 4. Feel free to submit issues, but for now, it is *not yet live*.
> > I'm working on it in real time, and anticipate making a broader
> > announcement to the community on June 6, 2016.
> >
> > The big ask right now pertains to maintainers.  Please create your
> > accounts, with secure passwords.  Everyone else may create their
> > account, but please do not load the database with issues right now.
> >
> > Lastly, please wind down usage of Github Issues!
> 
> We have live tickets where we're communicating with users. I think I
> shouldn't abort that communication immediately.
> 
> If the GitHub issue tracker can be convinced to reject new issues (with a
> pointer to this mailing list message), that could allow for an easier 
> transition.
> (I.e., minimize the number of tickets that are severed in half by the
> bugtracker switch-over.)
> 
> Looking forward to using Bugzilla!

We will migrate the issues from GitHub to BZ, before we shut it down! 

> 
> Thanks!
> Laszlo
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH 1/1] CorebootPayloadPkg: Consume PlatformHookLib in PlatformBootManagerLib

[Leahy, Leroy P]

Reviewed by: Lee Leahy 

Lee Leahy
(425) 881-4919
Intel Corporation
Suite 125
2700 - 156th Ave NE
Bellevue, WA  98007-6554


From: Ma, Maurice
Sent: Monday, May 23, 2016 3:03 PM
To: edk2-devel@lists.01.org
Cc: Ma, Maurice; Agyeman, Prince; Leahy, Leroy P
Subject: [PATCH 1/1] CorebootPayloadPkg: Consume PlatformHookLib in 
PlatformBootManagerLib

When coreboot uses different baud rate from the default (115200), the
current BDS driver will not be able to enable serial console display
due to the inconsistent serial port PCD settings.  By adding the
PlatformHookLib reference in the inf file, it will enforce the PCDs
to be aligned with what have been passed from coreboot.

Cc: Prince Agyeman 
Cc: Lee Leahy 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Maurice Ma 
---
 .../Library/PlatformBootManagerLib/PlatformBootManagerLib.inf  | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git 
a/CorebootPayloadPkg/Library/PlatformBootManagerLib/PlatformBootManagerLib.inf 
b/CorebootPayloadPkg/Library/PlatformBootManagerLib/PlatformBootManagerLib.inf
index 59227c759886..475c65d8a16f 100644
--- 
a/CorebootPayloadPkg/Library/PlatformBootManagerLib/PlatformBootManagerLib.inf
+++ 
b/CorebootPayloadPkg/Library/PlatformBootManagerLib/PlatformBootManagerLib.inf
@@ -1,7 +1,7 @@
 ## @file
 #  Include all platform action which can be customized by IBV/OEM.
 #
-#  Copyright (c) 2012 - 2015, Intel Corporation. All rights reserved.
+#  Copyright (c) 2012 - 2016, Intel Corporation. All rights reserved.
 #  This program and the accompanying materials
 #  are licensed and made available under the terms and conditions of the BSD 
License
 #  which accompanies this distribution.  The full text of the license may be 
found at
@@ -52,6 +52,7 @@
   DevicePathLib
   HiiLib
   PrintLib
+  PlatformHookLib

 [Guids]

--
1.9.5.msysgit.0

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [BaseTools] PACKAGES_PATH issue?

[Andrew Fish]

> On May 23, 2016, at 5:52 AM, Gao, Liming  wrote:
> 
> Andrew:
>   The buid output path is always in $(WORKSPACE)\Build directory.

You mean the path in $(WORKSPACE)\Build does not match the WORKSPACE relative 
path of the file? That seems to imply that code from different packages could 
get mixed together in the $(WORKSPACE)\Build output. That seems very very 
confusing to the user. 

> It is not related to $(PACKAGES_PATH). PACKAGES_PATH is designed to search 
> source files, doesn’t impact build output directory. 
>  

That is not what I was seeing? I'm seeing $(WORKSPACE) relative paths in 
$(WORKSPACE)\Build and then I'm see logic that is not using the full path to 
search for files? 

I have output that looks like: 
Build/X/DEBUG_XCODE5/X64/edk2/MdeModulePkg/Universal/Acpi/AcpiTableDxe/AcpiTableDxe/OUTPUT/
But I saw the Python searching a location like this for files:
Build/X/DEBUG_XCODE5/X64/MdeModulePkg/Universal/Acpi/AcpiTableDxe/AcpiTableDxe/OUTPUT/

Thanks,

Andrew Fish

> I try Ovmf platform. Its AcpiTables can be found and be built into FFS.
>  
> Thanks
> Liming <>
>  <>From: af...@apple.com  [mailto:af...@apple.com 
> ] 
> Sent: Saturday, May 21, 2016 8:21 AM
> To: Gao, Liming >
> Cc: edk2-devel >
> Subject: Re: [edk2] [BaseTools] PACKAGES_PATH issue?
>  
> Liming,
> 
> I found one more issues. My ACPI tables are breaking the build. It looks like 
> the failure is no input files. What I've figured out in GetFileList() is 
> FfsInf.EfiOutputPath is constructed incorrectly. The path does not included 
> the prefix from the PACKAGES_PATH and thus the directory does not exist and 
> no files are found. It looks like the issue is __GetEFIOutPutPath__() as it 
> is using self.InfFileName and that has not been adjusted for PACKAGES_PATH?
> 
> Thanks,
> 
> Andrew Fish
> 
> > On May 20, 2016, at 1:34 AM, Gao, Liming wrote:
> > 
> > Andrew:
> > Thanks for your point out. It is bug. Your fix is correct. I will send the 
> > patch for it. 
> > 
> > Thanks
> > Liming
> >> -Original Message-
> >> From: af...@apple.com  [mailto:af...@apple.com 
> >> ]
> >> Sent: Friday, May 20, 2016 1:25 PM
> >> To: Gao, Liming 
> >> Cc: edk2-devel 
> >> Subject: Re: [edk2] [BaseTools] RuleOverride = BINARY code location?
> >> 
> >> 
> >>> On May 19, 2016, at 8:18 PM, Gao, Liming wrote:
> >>> 
> >>> Thanks Andrew. I will continue to investigate it.
> >>> 
> >> 
> > F = 'FileNoExtention'
> > os.path.splitext(F)[1]
> >> ''
> > '' in '.out'
> >> True
> >> 
> >> So I think the bug is the `in` it should be `==`
> > '' == '.out'
> >> False
> >> 
> >> Thanks,
> >> 
> >> Andrew Fish
> >> 
> >> 
>  -Original Message-
>  From: af...@apple.com  [mailto:af...@apple.com 
>  ]
>  Sent: Friday, May 20, 2016 10:01 AM
>  To: Gao, Liming 
>  Cc: edk2-devel 
>  Subject: Re: [edk2] [BaseTools] RuleOverride = BINARY code location?
>  
>  
> > On May 18, 2016, at 5:44 PM, Andrew Fish wrote:
> > 
> >> 
> >> On May 18, 2016, at 5:43 PM, Gao, Liming 
> >> wrote:
> >> 
> >> Andrew:
> >> |.bin will search the file with the postfix .bin in INF file directory 
> >> and its
>  output directory. So, there may be more than .bin files are found. Please
> >> see
>  the code login in GetFileList() from
>  C:\R9Tip\edk2\BaseTools\Source\Python\GenFds\Section.py.
> >> 
> > 
>  
>  Thanks for the pointer.
>  
>  This is the code that adding the OS executables in GetFileList() that is
> >> adding
>  the OS executables without the .bin extension.
>  if os.path.exists(Makefile):
>  # Update to search files with suffix in all sub-dirs.
>  Tuple = os.walk(FfsInf.EfiOutputPath)
>  for Dirpath, Dirnames, Filenames in Tuple:
>  for F in Filenames:
>  if os.path.splitext(F)[1] in (Suffix):
>  FullName = os.path.join(Dirpath, F)
>  if os.path.getmtime(FullName) >
> >> os.path.getmtime(Makefile):
>  FileList.append(FullName)
>  
>  
>  I think the issue is:
>  if os.path.splitext(F)[1] in (Suffix):
>  
>  If the file does not have an extension it matches.
>  
>  Sorry might be wrong have to go out to a writers reading with my wife so
>  have to stop looking right now.
>  
>  Contributed-under: TianoCore Contribution Agreement 1.0
>  
>  Thanks,
>  
>  Andrew Fish
> >>> ___
> >>> edk2-devel mailing list
> >>> edk2-devel@lists.01.org 
> >>> https://lists.01.org/mailman/listinfo/edk2-devel 
> >>> 
> > 

Re: [edk2] [RFC] MdePkg: BaseLib: don't use aligned pointers for unaligned accessors

[Leif Lindholm]

Hi Mike,

Apologies for going silent - I spent last week in China, with very
restricted access to my primary email account.

On Tue, May 17, 2016 at 05:38:21PM +, Kinney, Michael D wrote:
> Leif,
> 
> What are the specific warnings that are being triggered by CLANG
> -Weverything for the unaligned access APIs in BaseLib?

The -Weverything is actually a sidetrack here, it was just that some
of the many casts were implicitly sign-changing, which generated
warnings and caused me to have a closer look.
This does however display another way in which the existing code is
incorrect.

> Are there other options than changing the BaseLib API definitions?
> My two concerns are:
> 
> 1) Impacts to modules/libs that call the unaligned access functions
>in BaseLib.  Changing
> I am not sure if changing a parameter from UINTx * to VOID * is
> backwards compatible for All caller use cases or not.

It is. It is semantically equivalent to changing them to a CHAR *.
"A pointer to void shall have the same representation and alignment
requirements as a pointer to a character type." (6.2.5-28 in C11,
nearby in previous revisions of the language.)

Which is what the interface is meant to represent; providing
single-byte-aligned accesses for types that would normally require
more.

> 2) Loss of some type checking as I mentioned below.

Basline remains is - this is not valid C code, and I was entirely
serious when I said I think the "optimization errors" that caused the
split into a separate implementation for ARM* was caused by the
incorrect explicit pointer alignment.

The current implementatiom provides the compiler with information
about the underlying data structures which can be factually incorrect.
So the type checking is already explicitly disabled.

If people would be happy with it, I could submit a new version that
gets rid of all of the implementations and replaces it with a simple
header file. If that is not fine (code implementation in header
files), I could just fix MdePkg/Library/BaseLib/Unaligned.c and drop
the ARM/IPF versions?

For ARM, we build everything with -mno-unaligned-access, and for
AARCH64 we build with -mstrict-align in CC_XIPFLAGS. So before our MMU
is enabled (and unaligned accesses are fine), the compiler will never
try to be clever, and afterwards it works as expected. The current
implementation however deprives it of the information it needs to
guarantee it is able to perform its work correctly.

Regards,

Leif

> Thanks,
> 
> Mike
> 
> > -Original Message-
> > From: af...@apple.com [mailto:af...@apple.com]
> > Sent: Thursday, May 12, 2016 4:27 PM
> > To: Kinney, Michael D 
> > Cc: Leif Lindholm ; edk2-devel@lists.01.org; Gao, 
> > Liming
> > ; Ard Biesheuvel 
> > Subject: Re: [edk2] [RFC] MdePkg: BaseLib: don't use aligned pointers for 
> > unaligned
> > accessors
> > 
> > 
> > > On May 12, 2016, at 4:01 PM, Kinney, Michael D 
> > >  wrote:
> > >
> > > Leif,
> > >
> > > Yes.  Typecasts are used by the caller if the type does not match.  Here 
> > > is an
> > > example from the PciCfg2.c that you referenced.
> > >
> > >  IN OUTVOID  *Buffer
> > >
> > >  //
> > >  // Aligned Pci address access
> > >  //
> > >  WriteUnaligned16 (((UINT16 *) Buffer), PciRead16 (PciLibAddress));
> > >
> > >
> > > Since Buffer is type VOID *, a typecast to UINT16 * is made.  That is 
> > > valid C
> > > code.
> > 
> > Mike,
> > 
> > Leif may be talking about:
> > 
> > The C Standard, 6.3.2.3, paragraph 7 [ISO/IEC 9899:2011], states:
> > A pointer to an object or incomplete type may be converted to a pointer to a
> > different object or incomplete type. If the resulting pointer is not 
> > correctly
> > aligned for the referenced type, the behavior is undefined.
> > 
> > I always like to reference Chris Lattner's LLVM blog post on undefined 
> > behavior, but
> > this is not an example of the specific case. But the restrictions on type 
> > conversions
> > exist to enable TBAA.
> > http://blog.llvm.org/2011/05/what-every-c-programmer-should-know.html
> > Violating Type Rules: It is undefined behavior to cast an int* to a float* 
> > and
> > dereference it (accessing the "int" as if it were a "float"). C requires 
> > that these
> > sorts of type conversions happen through memcpy: using pointer casts is not 
> > correct
> > and undefined behavior results. The rules for this are quite nuanced and I 
> > don't want
> > to go into the details here (there is an exception for char*, vectors have 
> > special
> > properties, unions change things, etc). This behavior enables an analysis 
> > known as
> > "Type-Based Alias Analysis" (TBAA) which is used by a broad range of memory 
> > access
> > optimizations in the compiler, and can significantly improve performance of 
> > the
> > generated code. For example, this rule allows clang to 

Re: [edk2] StdLib for EFI DRIVER type

[Carsey, Jaben]

StdLib also supports apps not in the shell environment.

You can certainly port many the APIs to work for drivers.  The goal of StdLib 
is to support existing applications being moved to UEFI environment.  That does 
not really apply to drivers.

What is the issue that you are finding a StdLib solution for?

-Jaben

> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
> jabir
> Sent: Monday, May 23, 2016 7:16 AM
> To: edk2-devel@lists.01.org
> Subject: [edk2] StdLib for EFI DRIVER type
> Importance: High
> 
> Hi,
> 
> I found that StdLib package can be only used for Apps in shell
> environment.. Is there any way to port StdLib for EFI DRIVER type? Is there
> any alternate package that can be used?
> Please help. Thanks in advance.
> 
> --
> Jabir
> ___
> edk2-devel mailing list
> edk2-devel@lists.01.org
> https://lists.01.org/mailman/listinfo/edk2-devel
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [RFC] Structured PCD Proposal

[Gao, Liming]

Andrew:
  Sorry, I have not fully understood your prototype. In this prototype, after 
the module with sample.pcd and sample.h is built, the output AutoGenTool file 
is generated. It includes below contents for PCD value initialization. The 
driver can directly consumes PcdFakePcdExample, and convert it to structure 
FAKE_PCD_EXAMPLE type, then access its field. There is no change in PcdLib and 
Pcd Driver. Right?

+++
[PcdsFixedAtBuild.common]
  gMdeModulePkgTokenGuid.PcdFakePcdExample| { 0x53, 0x47, 0xc1, 0xe0, 0xbe, 
0xf9, 0xd2, 0x11, 0x9a, 0x0c, 0x00, 0x90, 0x27, 0x3f, 0xc1, 0x4d, 0x21, 0x30, 
0x04, 0x00, 0x03, 0x00, 0x00, 0x00,} | FAKE_PCD_EXAMPLE
  gMdeModulePkgTokenGuid.PcdFakeDevicePathExample| { 0x03, 0x0f, 0x0b, 0x00, 
0xff, 0xff, 0xff, 0xff, 0x03, 0x01, 0x01, 0x7f, 0xff, 0x04, 0x00,} | 
EFI_DEVICE_PATH_PROTOCOL

+++

Thanks
Liming
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Andrew 
Fish
Sent: Monday, May 23, 2016 6:04 AM
To: Kinney, Michael D 
Cc: edk2-devel@lists.01.org 
Subject: Re: [edk2] [RFC] Structured PCD Proposal

Mike,

I did a quick prototype that just outputs the current PCD DSC syntax with an 
extra | C typedef name at the end when you build.  The example includes a 
structure with bit-fields and a device path.


build -p MdeModulePkg/MdeModulePkg.dsc -a X64 -t XCODE5

+++
[PcdsFixedAtBuild.common]
  gMdeModulePkgTokenGuid.PcdFakePcdExample| { 0x53, 0x47, 0xc1, 0xe0, 0xbe, 
0xf9, 0xd2, 0x11, 0x9a, 0x0c, 0x00, 0x90, 0x27, 0x3f, 0xc1, 0x4d, 0x21, 0x30, 
0x04, 0x00, 0x03, 0x00, 0x00, 0x00,} | FAKE_PCD_EXAMPLE
  gMdeModulePkgTokenGuid.PcdFakeDevicePathExample| { 0x03, 0x0f, 0x0b, 0x00, 
0xff, 0xff, 0xff, 0xff, 0x03, 0x01, 0x01, 0x7f, 0xff, 0x04, 0x00,} | 
EFI_DEVICE_PATH_PROTOCOL

+++

There are a few hacks:
1) The parser is not very robust from an error handling point of view.
2) Some of the compiler flags are missing. The reason is I could not undo the 
-E from the flags I was trying to reuse. So this may take a little flags 
cleanup to work.
3) I only had enough time to do the XCODE version, and I set the flags needed 
to make sure you get the EFI Spec structure packing.

Thanks,

Andrew Fish



diff --git a/BaseTools/BinWrappers/PosixLike/StructuredPcdAutoGen.py 
b/BaseTools/BinWrappers/PosixLike/StructuredPcdAutoGen.py
new file mode 100755
index 000..82a9b3b
--- /dev/null
+++ b/BaseTools/BinWrappers/PosixLike/StructuredPcdAutoGen.py
@@ -0,0 +1,85 @@
+#!/usr/bin/python -u
+## @file
+# Prototype .pcd parser
+#
+# Parse the meta data
+#// @PCDTYPE [PcdsFixedAtBuild.common]
+#// @PCD 
gMdeModulePkgTokenGuid.PcdFakePcdExample|FAKE_PCD_EXAMPLE|gFakePcdExample
+#
+# Create a C application to generate the PCD data.
+#
+# Copyright (c) 2016, Apple Inc. All rights reserved.
+# This program and the accompanying materials
+# are licensed and made available under the terms and conditions of the BSD 
License
+# which accompanies this distribution.  The full text of the license may be 
found at
+# http://opensource.org/licenses/bsd-license.php
+#
+# THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS,
+# WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR IMPLIED.
+#
+
+import sys
+
+programStart = '''
+// AutoGen file do not hand edit.
+#include 
+
+#ifdef NULL
+#undef NULL
+#endif
+
+#include "%s"
+
+int
+main (int argv, char **argc)
+{
+  unsigned char *c;
+  int i;
+
+'''
+
+programWork = '''
+  printf ("  @1| {");
+  for (i=0, c = (unsigned char *)(unsigned long long) &@2; i < sizeof (@2); 
i++) {
+printf (" 0x%02x,", c[i]);
+   }
+   printf ("} | @3\\n");
+'''
+
+""
+
+programEnd = '''
+  printf ("\\n");
+  return 0;
+}
+
+'''
+
+def main (filename):
+''' strip out lines that do not start with @, and the @'''
+print programStart % filename
+
+pcd = {}
+pcdType = ''
+with open(filename) as openfile:
+for line_of_c in openfile.readlines():
+line = line_of_c.split()
+if len(line) >= 3 and line[0] == '//':
+if '@PCDTYPE' in line[1]:
+#// @PCDTYPE [PcdsFixedAtBuild.common]
+print '  printf ("%s\\n");' % line[2]
+if '@PCD' in line[1]:
+#// @PCD 
gMdeModulePkgTokenGuid.PcdFakePcdExample|FAKE_PCD_EXAMPLE|gFakePcdExample
+PcdEntry = line[2].split('|')
+if len (PcdEntry) >= 3:
+print programWork.replace('@1', 
PcdEntry[0]).replace('@2', PcdEntry[2]).replace('@3', PcdEntry[1])
+
+print programEnd
+
+if __name__ == "__main__":
+if len (sys.argv) < 2:
+sys.exit()
+
+ 

[edk2] StdLib for EFI DRIVER type

[jabir]

Hi,

I found that StdLib package can be only used for Apps in shell
environment.. Is there any way to port StdLib for EFI DRIVER type? Is there
any alternate package that can be used?
Please help. Thanks in advance.

--
Jabir
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [BaseTools] PACKAGES_PATH issue?

[Laszlo Ersek]

On 05/23/16 14:52, Gao, Liming wrote:
> Andrew:
> The buid output path is always in $(WORKSPACE)\Build directory. It is
> not related to $(PACKAGES_PATH). PACKAGES_PATH is designed to search
> source files, doesn't impact build output directory.
> 
> I try Ovmf platform. Its AcpiTables can be found and be built into FFS.

Is it possible that Andrew's out-of-tree FDF file is missing the like of
commit 259d87146b07?

Thanks
Laszlo

> Thanks
> Liming
> From: af...@apple.com [mailto:af...@apple.com]
> Sent: Saturday, May 21, 2016 8:21 AM
> To: Gao, Liming 
> Cc: edk2-devel 
> Subject: Re: [edk2] [BaseTools] PACKAGES_PATH issue?
> 
> Liming,
> 
> I found one more issues. My ACPI tables are breaking the build. It
> looks like the failure is no input files. What I've figured out in
> GetFileList() is FfsInf.EfiOutputPath is constructed incorrectly. The
> path does not included the prefix from the PACKAGES_PATH and thus the
> directory does not exist and no files are found. It looks like the
> issue is __GetEFIOutPutPath__() as it is using self.InfFileName and
> that has not been adjusted for PACKAGES_PATH?
> 
> Thanks,
> 
> Andrew Fish
> 
>> On May 20, 2016, at 1:34 AM, Gao, Liming wrote:
>>
>> Andrew:
>> Thanks for your point out. It is bug. Your fix is correct. I will send the 
>> patch for it.
>>
>> Thanks
>> Liming
>>> -Original Message-
>>> From: af...@apple.com [mailto:af...@apple.com]
>>> Sent: Friday, May 20, 2016 1:25 PM
>>> To: Gao, Liming
>>> Cc: edk2-devel
>>> Subject: Re: [edk2] [BaseTools] RuleOverride = BINARY code location?
>>>
>>>
 On May 19, 2016, at 8:18 PM, Gao, Liming wrote:

 Thanks Andrew. I will continue to investigate it.

>>>
>> F = 'FileNoExtention'
>> os.path.splitext(F)[1]
>>> ''
>> '' in '.out'
>>> True
>>>
>>> So I think the bug is the `in` it should be `==`
>> '' == '.out'
>>> False
>>>
>>> Thanks,
>>>
>>> Andrew Fish
>>>
>>>
> -Original Message-
> From: af...@apple.com [mailto:af...@apple.com]
> Sent: Friday, May 20, 2016 10:01 AM
> To: Gao, Liming
> Cc: edk2-devel
> Subject: Re: [edk2] [BaseTools] RuleOverride = BINARY code location?
>
>
>> On May 18, 2016, at 5:44 PM, Andrew Fish wrote:
>>
>>>
>>> On May 18, 2016, at 5:43 PM, Gao, Liming
>>> wrote:
>>>
>>> Andrew:
>>> |.bin will search the file with the postfix .bin in INF file directory 
>>> and its
> output directory. So, there may be more than .bin files are found. Please
>>> see
> the code login in GetFileList() from
> C:\R9Tip\edk2\BaseTools\Source\Python\GenFds\Section.py.
>>>
>>
>
> Thanks for the pointer.
>
> This is the code that adding the OS executables in GetFileList() that is
>>> adding
> the OS executables without the .bin extension.
> if os.path.exists(Makefile):
> # Update to search files with suffix in all sub-dirs.
> Tuple = os.walk(FfsInf.EfiOutputPath)
> for Dirpath, Dirnames, Filenames in Tuple:
> for F in Filenames:
> if os.path.splitext(F)[1] in (Suffix):
> FullName = os.path.join(Dirpath, F)
> if os.path.getmtime(FullName) >
>>> os.path.getmtime(Makefile):
> FileList.append(FullName)
>
>
> I think the issue is:
> if os.path.splitext(F)[1] in (Suffix):
>
> If the file does not have an extension it matches.
>
> Sorry might be wrong have to go out to a writers reading with my wife so
> have to stop looking right now.
>
> Contributed-under: TianoCore Contribution Agreement 1.0
>
> Thanks,
>
> Andrew Fish
 ___
 edk2-devel mailing list
 edk2-devel@lists.01.org
 https://lists.01.org/mailman/listinfo/edk2-devel
>>
> ___
> edk2-devel mailing list
> edk2-devel@lists.01.org
> https://lists.01.org/mailman/listinfo/edk2-devel
> 

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] TCP4: Failure to Acknowledge due to DPC Dispatch Nesting

[Cohen, Eugene]

Adding some maintainers...

We are looking forward to a response.

Thanks,

Eugene

> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
> Cohen, Eugene
> Sent: Friday, May 20, 2016 2:11 PM
> To: edk2-devel@lists.01.org
> Cc: Vaughn, Gregory (IPG LJ Printer Lab) 
> Subject: [edk2] TCP4: Failure to Acknowledge due to DPC Dispatch Nesting
> 
> 
> We have isolated a problem where the TCP4 driver fails to acknowledge
> received data under certain circumstances.
> 
> Background on DPCs: The DPC mechanism allows functions to be called at a
> later point in time at a requested TPL level.  Functions are queued through
> the DPC Protocol's QueueDpc interface.  DPCs are dispatched anytime a
> module calls the DispatchDpc function in the DPC protocol.  The dispatch
> process will execute all queued DPCs that were registered to execute at or
> above the caller's TPL level (e.g. if caller is at TPL_CALLBACK the DPC 
> dispatch
> will execute anything between CALLBACK and HIGH_LEVEL).
> 
> The stack depends on DispatchDpc being called at appropriate preemption
> points to advance packet processing.  The dispatch function is called in
> multiple layers as you can see by searching for DispatchDpc with calls
> originating from ArpDxe, Ip4Dxe, MnpDxe, Udp4Dxe, UefiPxeBcDxe,
> DnsDxe, HttpDxe, Ip6Dxe and Udp6Dxe.
> 
> Currently it's possible for DPC dispatching to occur in a nested manner.
> Imagine a case where an upper network stack layer queues a DPC (for
> example the TCP layer's TcpTickingDpc) and in the DPC handler it makes use
> of lower layers (like sending a packet through IP+MNP).  As part of packet
> processing these lower layers will call DispatchDpc resulting in nested DPCs
> execution.
> 
> 
> Here's an example of the DPC nesting, the indent level indicates the level of
> nesting for the DPC
> 
> TcpTicking
> DpcDispatchDpc TPL=CALLBACK
> TcpTickingDpc
> TcpTickingDpc Tcb: 0x49a42dd0, DelayedAck=1, CtrlFlag: 0x1019
> TcpTickingDpc call TcpSendAck delayed is: 1
> TcpSendAck  Seq=158464588 Ack=4152002304
> TcpTransmitSegment DelayedAck = 0
> Nbuf SendIpPacket: DestPort=62462 Seq=158464588 Ack=4152002304
> Window=19840
> MnpSyncSendPacket call DispatchDpc
> DpcDispatchDpc TPL=CALLBACK
> Ip4AccpetFrame call DispatchDpc
> DpcDispatchDpc TPL=CALLBACK
> Ip4FreeTxToken call DispatchDpc
> DpcDispatchDpc TPL=CALLBACK
> TcpInput: DestPort=8816 Seq=4152002304 Ack=158464588 Len=1460
> TcpClearTimer Tcb: 0x49a42dd0
> 
> Notice how the process of sending the TCP ACK via IP then MNP causes
> another DispatchDpc to occur before the TCP segment transmit call returns.
> This nesting continues on and a whole bunch of code has executed (all at
> CALLBACK TPL).  You can see near the end that we even begin processing
> another TCP packet.
> 
> 
> If we look in detail what the TcpSendAck does there are two key steps:
> 
>   if (TcpTransmitSegment (Tcb, Nbuf) == 0) {
> TCP_CLEAR_FLG (Tcb->CtrlFlag, TCP_CTRL_ACK_NOW);
> Tcb->DelayedAck = 0;
>   }
> 
> It transmits the segment and after the transmit returns it clears the
> DelayedAck counter since the presumption is that we sent an ACK for the
> most recent segment and we are caught up.  But because DPCs are
> dispatched within TcpTransmitSegment the assumption that this transmit
> was the last one is incorrect.
> 
> 
> Here is a portion of a trace illustrating the problem:
> 
> TcpTicking
> DpcDispatchDpc TPL=CALLBACK
> TcpTickingDpc
> TcpTickingDpc Tcb: 0x49a42dd0, DelayedAck=1, CtrlFlag: 0x1019
> TcpTickingDpc call TcpSendAck delayed is: 1
> TcpSndAck  Seq=158464588 Ack=4152002304
> TcpTransmitSegment DelayedAck = 0
> Nbuf SendIpPacket: DestPort=62462 Seq=158464588 Ack=4152002304
> Window=19840
> MnpSyncSendPacket call DispatchDpc
> DpcDispatchDpc TPL=CALLBACK
> 
> [snip - a bunch of nested DPC processing removed]
> 
>  DpcDispatchDpc Tpl= TPL=CALLBACK
>   TcpInput: DestPort=8816 Seq=4152019824 Ack=158464588 Len=1460
>   TcpClearTimer Tcb: 0x49a42dd0
>   TcpInput Seq=4152019824 Tcb: 0x49a42dd0, Tcb->DupAck = 0
>   TcpToSendAck add to delayedack Seq=158464588 Ack=4152021284
>   TcpToSendAck add to delayedack Tcb: 0x49a42dd0, Seq=158464588
> Ack=4152021284, DelayedAck=1
>   ^^ NOTE: the DelayedAck flag has been set to one indicating that we
> haven't acknowledged yet and need to soon
> 
>   [we return from 14 nested DPC calls !!]
> 
> TcpSndAck  Tcb->DelayedAck = 0
> ^^ But when the Dispatch returns from the TcpTransmitSegment we clear
> DelayedAck back to zero such that we never acknowledge the last packet we
> received.
> 
> TcpTickingDpc No timer active or expired
> TcpTickingDpc Tcb: 0x49918bd0, DelayedAck=0, CtrlFlag: 0x1019
> TcpTickingDpc No timer active or expired
> 
> In cases 

Re: [edk2] [BaseTools] PACKAGES_PATH issue?

[Gao, Liming]

Andrew:
  The buid output path is always in $(WORKSPACE)\Build directory. It is not 
related to $(PACKAGES_PATH). PACKAGES_PATH is designed to search source files, 
doesn't impact build output directory.

I try Ovmf platform. Its AcpiTables can be found and be built into FFS.

Thanks
Liming
From: af...@apple.com [mailto:af...@apple.com]
Sent: Saturday, May 21, 2016 8:21 AM
To: Gao, Liming 
Cc: edk2-devel 
Subject: Re: [edk2] [BaseTools] PACKAGES_PATH issue?

Liming,

I found one more issues. My ACPI tables are breaking the build. It looks like 
the failure is no input files. What I've figured out in GetFileList() is 
FfsInf.EfiOutputPath is constructed incorrectly. The path does not included the 
prefix from the PACKAGES_PATH and thus the directory does not exist and no 
files are found. It looks like the issue is __GetEFIOutPutPath__() as it is 
using self.InfFileName and that has not been adjusted for PACKAGES_PATH?

Thanks,

Andrew Fish

> On May 20, 2016, at 1:34 AM, Gao, Liming wrote:
>
> Andrew:
> Thanks for your point out. It is bug. Your fix is correct. I will send the 
> patch for it.
>
> Thanks
> Liming
>> -Original Message-
>> From: af...@apple.com [mailto:af...@apple.com]
>> Sent: Friday, May 20, 2016 1:25 PM
>> To: Gao, Liming
>> Cc: edk2-devel
>> Subject: Re: [edk2] [BaseTools] RuleOverride = BINARY code location?
>>
>>
>>> On May 19, 2016, at 8:18 PM, Gao, Liming wrote:
>>>
>>> Thanks Andrew. I will continue to investigate it.
>>>
>>
> F = 'FileNoExtention'
> os.path.splitext(F)[1]
>> ''
> '' in '.out'
>> True
>>
>> So I think the bug is the `in` it should be `==`
> '' == '.out'
>> False
>>
>> Thanks,
>>
>> Andrew Fish
>>
>>
 -Original Message-
 From: af...@apple.com [mailto:af...@apple.com]
 Sent: Friday, May 20, 2016 10:01 AM
 To: Gao, Liming
 Cc: edk2-devel
 Subject: Re: [edk2] [BaseTools] RuleOverride = BINARY code location?


> On May 18, 2016, at 5:44 PM, Andrew Fish wrote:
>
>>
>> On May 18, 2016, at 5:43 PM, Gao, Liming
>> wrote:
>>
>> Andrew:
>> |.bin will search the file with the postfix .bin in INF file directory 
>> and its
 output directory. So, there may be more than .bin files are found. Please
>> see
 the code login in GetFileList() from
 C:\R9Tip\edk2\BaseTools\Source\Python\GenFds\Section.py.
>>
>

 Thanks for the pointer.

 This is the code that adding the OS executables in GetFileList() that is
>> adding
 the OS executables without the .bin extension.
 if os.path.exists(Makefile):
 # Update to search files with suffix in all sub-dirs.
 Tuple = os.walk(FfsInf.EfiOutputPath)
 for Dirpath, Dirnames, Filenames in Tuple:
 for F in Filenames:
 if os.path.splitext(F)[1] in (Suffix):
 FullName = os.path.join(Dirpath, F)
 if os.path.getmtime(FullName) >
>> os.path.getmtime(Makefile):
 FileList.append(FullName)


 I think the issue is:
 if os.path.splitext(F)[1] in (Suffix):

 If the file does not have an extension it matches.

 Sorry might be wrong have to go out to a writers reading with my wife so
 have to stop looking right now.

 Contributed-under: TianoCore Contribution Agreement 1.0

 Thanks,

 Andrew Fish
>>> ___
>>> edk2-devel mailing list
>>> edk2-devel@lists.01.org
>>> https://lists.01.org/mailman/listinfo/edk2-devel
>
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

[edk2] [Patch] NetworkPkg: update code for NULL pointer check.

[Fu Siyuan]

This patch updates the HTTP driver to initialize the local variable for NULL
and check the NULL pointer before dereference it.

Cc: Ye Ting 
Cc: Wu Jiaxin 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Fu Siyuan 
---
 NetworkPkg/HttpDxe/HttpImpl.c | 17 ++---
 1 file changed, 10 insertions(+), 7 deletions(-)

diff --git a/NetworkPkg/HttpDxe/HttpImpl.c b/NetworkPkg/HttpDxe/HttpImpl.c
index f4ae28a..7ee6613 100644
--- a/NetworkPkg/HttpDxe/HttpImpl.c
+++ b/NetworkPkg/HttpDxe/HttpImpl.c
@@ -253,6 +253,7 @@ EfiHttpRequest (
   // Initializations
   //
   Url = NULL;
+  UrlParser = NULL;
   HostName = NULL;
   RequestMsg = NULL;
   HostNameStr = NULL;
@@ -1063,7 +1064,7 @@ HttpResponseWorker (
 if (SizeofHeaders != 0) {
   HeaderTmp = AllocateZeroPool (SizeofHeaders);
   if (HeaderTmp == NULL) {
-goto Error;
+goto Error2;
   }
 
   CopyMem (HeaderTmp, Tmp, SizeofHeaders);
@@ -1075,7 +1076,7 @@ HttpResponseWorker (
   //
   if (mHttpUtilities == NULL) {
 Status = EFI_NOT_READY;
-goto Error;
+goto Error2;
   }
 
   //
@@ -1089,7 +1090,7 @@ HttpResponseWorker (
  >HeaderCount
  );
   if (EFI_ERROR (Status)) {
-goto Error;
+goto Error2;
   }
 
   FreePool (HttpHeaders);
@@ -1214,7 +1215,7 @@ HttpResponseWorker (
 >TimeoutEvent
 );
 if (EFI_ERROR (Status)) {
-  goto Error;
+  goto Error2;
 }
   }
 
@@ -1223,7 +1224,7 @@ HttpResponseWorker (
   //
   Status = gBS->SetTimer (HttpInstance->TimeoutEvent, TimerRelative, 
HTTP_RESPONSE_TIMEOUT * TICKS_PER_SECOND);
   if (EFI_ERROR (Status)) {
-goto Error;
+goto Error2;
   }
 
   //
@@ -1234,7 +1235,7 @@ HttpResponseWorker (
   gBS->SetTimer (HttpInstance->TimeoutEvent, TimerCancel, 0);
 
   if (EFI_ERROR (Status)) {
-goto Error;
+goto Error2;
   }
 
   FreePool (Wrap);
@@ -1258,7 +1259,9 @@ Exit:
   return Status;
 
 Error2:
-  NetMapInsertHead (>TxTokens, ValueInItem->HttpToken, 
ValueInItem);
+  if (ValueInItem != NULL) {
+NetMapInsertHead (>TxTokens, ValueInItem->HttpToken, 
ValueInItem);
+  }
 
 Error:
   HttpTcpTokenCleanup (Wrap);
-- 
2.7.4.windows.1

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel