From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mga04.intel.com (mga04.intel.com [192.55.52.120]) by mx.groups.io with SMTP id smtpd.web11.11239.1581956563533658897 for ; Mon, 17 Feb 2020 08:22:43 -0800 Authentication-Results: mx.groups.io; dkim=missing; spf=none, err=permanent DNS error (domain: linux.intel.com, ip: 192.55.52.120, mailfrom: maciej.rabeda@linux.intel.com) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga007.jf.intel.com ([10.7.209.58]) by fmsmga104.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 17 Feb 2020 08:22:43 -0800 X-IronPort-AV: E=Sophos;i="5.70,453,1574150400"; d="scan'208";a="223870378" Received: from mrabeda-mobl.ger.corp.intel.com (HELO [10.102.8.43]) ([10.102.8.43]) by orsmga007-auth.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 17 Feb 2020 08:22:41 -0800 Subject: Re: [edk2-devel] HTTP boot failed on timeout To: devel@edk2.groups.io, lersek@redhat.com, doron.bleiberg@ecitele.com References: <899f2970-6028-0a2a-c306-993c4e91af80@redhat.com> <42f673b2-9f67-30db-c084-b53b382fd14d@redhat.com> From: "Maciej Rabeda" Message-ID: <491eb053-32ec-9a31-4865-a7b0cf998f3e@linux.intel.com> Date: Mon, 17 Feb 2020 17:22:39 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.5.0 MIME-Version: 1.0 In-Reply-To: <42f673b2-9f67-30db-c084-b53b382fd14d@redhat.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: pl Hi Doron, As for -netdev backend, you can try using tap. See: https://gist.github.com/extremecoders-re/e8fd8a67a515fee0c873dcafc81d811c Looking forward to test results. Thanks, Maciej On 17-Feb-20 11:32, Laszlo Ersek wrote: > On 02/17/20 11:29, Laszlo Ersek wrote: >> On 02/17/20 09:17, doron.bleiberg@ecitele.com wrote: >>> Hi Community, >>> >>> I've also opened same topic at general discussion group, but after digging more into this issue I think the relevant group is here where all the technical stuff happens. >>> A short introduction to my problem: >>> I'm trying to boot QEMU VM using HTTP boot. >>> I've modified Conf/target.txt as follows: >>> ACTIVE_PLATFORM       = OvmfPkg/OvmfPkgX64.dsc >>> TARGET_ARCH           = X64 >>> TOOL_CHAIN_TAG        = GCC48 >>> TARGET                = RELEASE >>> >>> and OvmfPkg/OvmfPkgX64.dsc as follows: >>> DEFINE NETWORK_HTTP_BOOT_ENABLE     = TRUE >>> DEFINE SECURE_BOOT_ENABLE      = TRUE >>> BUILD_TARGETS                  = RELEASE >>> >>> and compiled compiled OvmfPkg/OvmfPkgX64.dsc >>> >>> I'm loading the OVMF.fd to QEMU VM in this way: >>> /usr/bin/qemu-system-x86_64 -name UEFI-HTTP-VM >>> -m 8192M -smp cpus=1 >>> -enable-kvm -machine smm=off >>> -boot order=c *-bios /opt/gns3/images/QEMU/Ovmf.fd* >>> -drive file=/opt/gns3/projects/1a83274a-c57f-4337-8a0d-1e68a9312e9a/project-files/qemu/d8f37f0b-2b63-455f-b536-b309b9020e36/hda_disk.qcow2,if=ide,index=0,media=disk >>> -uuid d8f37f0b-2b63-455f-b536-b309b9020e36 >>> -vnc 0.0.0.0:3 >>> -monitor tcp:127.0.0.1:33919,server,nowait >>> -net none -device virtio-net-pci,mac=0c:2e:9a:0e:36:00,netdev=gns3-0 -netdev socket,id=gns3-0,udp=127.0.0.1:10017,localaddr=127.0.0.1:10016 >>> -nographic >>> >>> The VM starts and boots, the HTTP boot is kicking in and the download is starting. However, after few seconds the download is stopped and the boot terminates with 'Error: Server response timeout'. >>> The process is repeatable and always terminates at the same point (42% upload completed in my case). >>> >>> I've drilled down the code and located the 'offending' code here: >>> file: NetworkPkg/HttpBootDxe/HttpBootSupport.c >>> line#: 1012 >>> Offending Code: while (!HttpIo->IsRxDone && ((HttpIo->TimeoutEvent == NULL) || EFI_ERROR (gBS->CheckEvent (HttpIo->TimeoutEvent)))) >>> Error Handler at line #1022: if (!HttpIo-> IsRxDone ) >>> >>> What I did i order to investigate: >>> I've also tried to add HTTP header: "Connection": "Keep-Alive" hoping it will result the HTTP server keeping sessions open. >>> Used Wireshark to capture and analyze the packets during download - I could not spot anything unusual. Eventually the packed transfer just stops >>> Raised HTTP server debug level - could not find anything valuable in the logs. As far as I can tell from the logs, the HTTP server works correctly and it seems the problem is in the client side (UEFI) >>> I'm downloading large file, so I've checked I have enough RAM to hold the image - seems OK. No complains regarding buffer size >>> >>> Few inputs: >>> My HTTP server version: Apache httpd/2.4.6 (CentOS) >>> File size is I'm trying to download and boot: ~420MB >>> >>> Error observed in the UEFI log when download terminates: >>> Error: Server response timeout. >>> BdsDxe: failed to load Boot0005 "UEFI HTTPv4 (MAC:0C2E9A0E3600)" from PciRoot(0x0)/Pci(0x3,0x0)/MAC(0C2E9A0E3600,0x1)/IPv4(0.0.0.0,0x0,DHCP,0.0.0.0,0.0.0.0,0.0.0.0)/Uri(): Not Found >>> >>> For me it seems like a potential problem on the UEFI side, maybe related to Poll or other networking stuff. >>> >>> I'll appreciate any help. >> As I mentioned on edk2-discuss, I'd suggest two tweaks (independently of >> each other): >> >> * try the builting virtio-net driver rather than the iPXE one. For that, >> use: >> >> -device virtio-net-pci,[other properties],romfile="" >> >> that is, add a 'romfile=""' property >> >> * Try using a different -netdev backend than a UDP socket. > Also QEMU v2.5.0 was tagged on 2015-12-16; please try a more recent QEMU > release (I'd suggest 4.2.0). > > Thanks > Laszlo > > > >