From patchwork Tue Jun 21 18:12:11 2016 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Ryan Harkin X-Patchwork-Id: 70590 Delivered-To: patch@linaro.org Received: by 10.140.28.4 with SMTP id 4csp2152640qgy; Tue, 21 Jun 2016 11:12:17 -0700 (PDT) X-Received: by 10.107.3.84 with SMTP id 81mr33766009iod.156.1466532737006; Tue, 21 Jun 2016 11:12:17 -0700 (PDT) Return-Path: Received: from ml01.01.org (ml01.01.org. [198.145.21.10]) by mx.google.com with ESMTPS id 64si36638847pfd.183.2016.06.21.11.12.16 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 21 Jun 2016 11:12:16 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of edk2-devel-bounces@lists.01.org designates 198.145.21.10 as permitted sender) client-ip=198.145.21.10; Authentication-Results: mx.google.com; dkim=neutral (body hash did not verify) header.i=@linaro.org; spf=pass (google.com: best guess record for domain of edk2-devel-bounces@lists.01.org designates 198.145.21.10 as permitted sender) smtp.mailfrom=edk2-devel-bounces@lists.01.org; dmarc=fail (p=NONE dis=NONE) header.from=linaro.org Received: from [127.0.0.1] (localhost [IPv6:::1]) by ml01.01.org (Postfix) with ESMTP id 398041A1E5E; Tue, 21 Jun 2016 11:12:46 -0700 (PDT) X-Original-To: edk2-devel@lists.01.org Delivered-To: edk2-devel@lists.01.org Received: from mail-lf0-x231.google.com (mail-lf0-x231.google.com [IPv6:2a00:1450:4010:c07::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ml01.01.org (Postfix) with ESMTPS id 588A91A1E04 for ; Tue, 21 Jun 2016 11:12:44 -0700 (PDT) Received: by mail-lf0-x231.google.com with SMTP id h129so36243401lfh.1 for ; Tue, 21 Jun 2016 11:12:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Ua5KXrVRYNUgJoUpG0zGJwKTHHS3m/dtK3RlQpFL7OE=; b=Z6QU24Ru4HwE6370XRpDohmfnJoElFppMuZ07/lR4zaOf2wYbUFkcRZZ/i72acq3OC pR64phIktyRDBpRJfT8GWTnWnnmT9lxH3H0cHvd/waSTwGqmj9S+jLyXNp/QiBT5aBn4 muVVLdYRoAq9cEAlubqGr78OJXwLUmwPukFc4= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Ua5KXrVRYNUgJoUpG0zGJwKTHHS3m/dtK3RlQpFL7OE=; b=ki/UihrSQCrFq1EXNreiOI4mbsj8ySuUuQ/ViLxQJYwfFgnn72PwIRrqPmPMoQHv2q 7iBumKWtfkjI9m2sxUUTyPXdRvVJfBncnV+rhxRuAi2GvY61p20hMh22qL+zGNTYuNiH UwZMT13Rq9azUcJT3hXyJ/2bXoIS2MhNkrAmanuthZ30ywLgy9+lmVTgkhFAKMhGBLzu Ts+OAA2Y1NbQM459gmU2rsgG5B0sQYKFkGH5GENBEaOQlkfKNQmHofjTj2i+LkXglOWj 7Ntfk8O7uDc6Ba3C3nV25b8KYtVUX/0LnkUANvqhJakNa9qnNJ4wJqRLR9jnj+r2amZs 4/eg== X-Gm-Message-State: ALyK8tKnJH527ZnKcFwVJ511LaBv4gcZOORfS1JhhBCFi1+/jVKyc331xwpoNSIdqGcZNHKkXNsVR2NDJGk5UHkG X-Received: by 10.25.16.105 with SMTP id f102mr7242329lfi.34.1466532732346; Tue, 21 Jun 2016 11:12:12 -0700 (PDT) MIME-Version: 1.0 Received: by 10.25.35.145 with HTTP; Tue, 21 Jun 2016 11:12:11 -0700 (PDT) In-Reply-To: References: <1456374135-14732-1-git-send-email-jiaxin.wu@intel.com> <1456374135-14732-2-git-send-email-jiaxin.wu@intel.com> <895558F6EA4E3B41AC93A00D163B7274137B5947@SHSMSX103.ccr.corp.intel.com> <895558F6EA4E3B41AC93A00D163B7274137B5B5E@SHSMSX103.ccr.corp.intel.com> <895558F6EA4E3B41AC93A00D163B7274137B5C69@SHSMSX103.ccr.corp.intel.com> From: Ryan Harkin Date: Tue, 21 Jun 2016 19:12:11 +0100 Message-ID: To: "Wu, Jiaxin" Subject: Re: [edk2] [Patch 1/4] MdeModulePkg: Change the default IPv4 config policy X-BeenThere: edk2-devel@lists.01.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: EDK II Development List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: "Ye, Ting" , "Fu, Siyuan" , edk2-devel-01 Errors-To: edk2-devel-bounces@lists.01.org Sender: "edk2-devel" Hi Jiaxin, On 21 June 2016 at 12:20, Ryan Harkin wrote: > Hi Jiaxin, > > On 21 June 2016 at 12:10, Wu, Jiaxin wrote: >> Hi Ryan, >> >> I can't reproduce your issue on NT32, I will try it in a real platform later. >> > > I am unable to reproduce the problem on my "FVP models" (a type of > emulator) either. The models use a different ethernet device than my > hardware. > > >>> On first boot, policy is static, it gets changed to DHCP, "ifconfig -s >>> eth0 dhcp" works. On reboot, policy is dhcp, PXE changes it a couple >>> of times, then drops to the shell with is set to static again. >>> "ifconfig -s eth0 dhcp" fails no matter how many times I reboot. >> >> First PXE boot --> ifconfig -s eth0 dhcp (Success) --> reboot, then PXE --> ifconfig -s eth0 dhcp (Your platform failed here, but my parts is always in a success no matter how many times I tried.) >> >>> It's only when I "ifconfig -s eth0 static ...." then "ifconfig -s eth0 dhcp" that >>> DHCP obtains an IP address again. >>> >>> It could easily be a bug in the LAN9118 driver too, but there's a bug >>> somewhere, because it isn't working as we expect :-O >> >> So, to help us analyze problem, could you sent me one wireshark packet for the above steps? >> > > I don't have wireshark set up, but I'll try to get it working and send > you a trace. > > However, I suspect that DHCP service (Is that the DORA you mentioned?) > is not being restarted for some reason, so in that case, no packets > would be sent out. > > I don't know how the DHCP service is handled or started, but I'll try > and find the points in the code where it's started and stopped and add > some trace to see if there are any errors. Any suggestions of where > to place some DEBUG would be welcome. > I decided to add DEBUG statements to function Ip4StartAutoConfig in Ip4Config2Impl.c. I appended my DEBUG to the end of each line, so I didn't change the line numbering when compared to the upstream version, currently last modified here: 364f4efa444150df3f074f563374dce1e153adc6 The debug code I added to each branch in the function looks like this: DEBUG ((EFI_D_ERROR, "%a:%d Instance->Policy=%d\n", __FUNCTION__, __LINE__, Instance->Policy)); Therefore, I can trace which branches the code is taking. On first boot, as expected, I can see that Ip4StartAutoConfig is not called at all. The default policy is static, so I'd expect that. Then, when I configure DHCP from Shell, I see the following debug: Ip4StartAutoConfig:921 Instance->Policy=0 Ip4StartAutoConfig:1032 Instance->Policy=0 This tells me that NetLibCreateServiceChild, gBS->OpenProtocol and Dhcp4->Configure succeeded and the DHCP process was started. That all looks good. So I reset the board and see this debug on boot: Warning: LAN9118 Driver in stopped state Ip4StartAutoConfig:921 Instance->Policy=1 Ip4StartAutoConfig:943 Instance->Policy=1 Ip4StartAutoConfig:947 Instance->Policy=1 Ip4StartAutoConfig:958 Instance->Policy=1 Ip4StartAutoConfig:921 Instance->Policy=1 Ip4StartAutoConfig:943 Instance->Policy=1 Ip4StartAutoConfig:958 Instance->Policy=1 Ip4StartAutoConfig:921 Instance->Policy=1 Ip4StartAutoConfig:962 Instance->Policy=1 Ip4StartAutoConfig:1032 Instance->Policy=1 EhcExecTransfer: transfer failed with 2 EhcControlTransfer: error - Device Error, transfer - 2 Press ENTER to boot now or any other key to show the Boot Menu in 8 seconds Booting EFI USB Device Booting EFI Misc Device Booting EFI Misc Device 1 Booting EFI Network ..PXE-E99: Unexpected network error. Booting EFI Internal Shell add-symbol-file /working/platforms/uefi/edk2/Build/ArmJuno/DEBUG_GCC49/AARCH64/ShellPkg/Application/Shell/Shell/DEBUG/Shell.dll 0xF86C4000 Loading driver at 0x000F86C3000 EntryPoint=0x000F86C4000 Shell.efi Shell> ifconfig -s eth0 dhcp Ip4StartAutoConfig:921 Instance->Policy=0 Ip4StartAutoConfig:924 Instance->Policy=0 So I can see that on boot, because the saved policy is DHCP, the code taking a few error branches. First off "NetLibCreateServiceChild" returns EFI_UNSUPPORTED. The comments say this means "No DHCPv4 Service Binding protocol, register a notify.". Dhcp4SbNotifyEvent is NULL, so we create a notify event. There could be a bug here, I suppose. Why is NetLibCreateServiceChild returning EFI_UNSUPPORTED? I guess I need to investigate this some more. Continuing, at this point Status is still EFI_UNSUPPORTED, so this is caught line 958 and we return from the function. That looks like a bug. If not, it could do with a comment explaining why we've just handled the EFI_UNSUPPORTED error without returning, yet we return here anyway. I applied this diff to fix the suspected bug: Now, after first boot, I see this output when I run "ifconfig -s eth0 dhcp". Basically the same as before: Shell> ifconfig -s eth0 dhcp Shell> tAutoConfig:921 Instance->Policy=0 Ip4StartAutoConfig:1030 Instance->Policy=0 Then, I reset the board and then it ASSERTs: Warning: LAN9118 Driver in stopped state Ip4StartAutoConfig:921 Instance->Policy=1 Ip4StartAutoConfig:943 Instance->Policy=1 Ip4StartAutoConfig:947 Instance->Policy=1 Ip4StartAutoConfig:960 Instance->Policy=1 ASSERT_EFI_ERROR (Status = Invalid Parameter) ASSERT [Ip4Dxe] /working/platforms/uefi/edk2/MdeModulePkg/Universal/Network/Ip4Dxe/Ip4Config2Impl.c(972): !EFI_ERROR (Status) This is because gBS->OpenProtocol returns Invalid Parameter. So it looks like my diff wasn't a bug fix at all. Or, there is another bug? What do you think? Regards, Ryan. _______________________________________________ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel diff --git a/MdeModulePkg/Universal/Network/Ip4Dxe/Ip4Config2Impl.c b/MdeModulePkg/Universal/Network/Ip4Dxe/Ip4Config2Impl.c index a1de443..fb8a46a 100644 --- a/MdeModulePkg/Universal/Network/Ip4Dxe/Ip4Config2Impl.c +++ b/MdeModulePkg/Universal/Network/Ip4Dxe/Ip4Config2Impl.c @@ -953,9 +953,7 @@ Ip4StartAutoConfig ( &Instance->Registration ); } - } - - if (EFI_ERROR (Status)) { + } else if (EFI_ERROR (Status)) { return Status; }