From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from us-smtp-1.mimecast.com (us-smtp-1.mimecast.com [207.211.31.120]) by mx.groups.io with SMTP id smtpd.web12.7058.1581935551195071640 for ; Mon, 17 Feb 2020 02:32:31 -0800 Authentication-Results: mx.groups.io; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=Ku3iXQpL; spf=pass (domain: redhat.com, ip: 207.211.31.120, mailfrom: lersek@redhat.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1581935550; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=EhkCEv17uGS/jPOExeXTWAT6x8BLbadvmtZ+S1BzX6o=; b=Ku3iXQpL76rjbGMOsq3p5kocXWaTXTv/IgZibXahQwHg4tUpBkRttYCEpCtKVTmXE/l1O4 PITb4fy8ly69sO3j4dGfU9SUQTCjJ7qc0RkIeMow2U6szW1/9GLD8XYwciXAVMjC7NtSqQ W8QC2kaoRFknQ4CfEt8iPDyOv9AStY8= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-261-SZPtIAQaPi2NPshWpouZ1A-1; Mon, 17 Feb 2020 05:32:28 -0500 Received: from smtp.corp.redhat.com (int-mx03.intmail.prod.int.phx2.redhat.com [10.5.11.13]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id CE659802567; Mon, 17 Feb 2020 10:32:27 +0000 (UTC) Received: from lacos-laptop-7.usersys.redhat.com (ovpn-116-195.ams2.redhat.com [10.36.116.195]) by smtp.corp.redhat.com (Postfix) with ESMTP id 056B38DC1E; Mon, 17 Feb 2020 10:32:26 +0000 (UTC) Subject: Re: [edk2-devel] HTTP boot failed on timeout From: "Laszlo Ersek" To: devel@edk2.groups.io, doron.bleiberg@ecitele.com References: <899f2970-6028-0a2a-c306-993c4e91af80@redhat.com> Message-ID: <42f673b2-9f67-30db-c084-b53b382fd14d@redhat.com> Date: Mon, 17 Feb 2020 11:32:26 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <899f2970-6028-0a2a-c306-993c4e91af80@redhat.com> X-Scanned-By: MIMEDefang 2.79 on 10.5.11.13 X-MC-Unique: SZPtIAQaPi2NPshWpouZ1A-1 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Language: en-US Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable 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 diggi= ng more into this issue I think the relevant group is here where all the te= chnical 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=C2=A0 =C2=A0 =C2=A0 =C2=A0=3D OvmfPkg/OvmfPkgX64.dsc >> TARGET_ARCH=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=3D X64 >> TOOL_CHAIN_TAG=C2=A0 =C2=A0 =C2=A0 =C2=A0 =3D GCC48 >> TARGET=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =3D RELEAS= E >> >> and OvmfPkg/OvmfPkgX64.dsc as follows: >> DEFINE NETWORK_HTTP_BOOT_ENABLE=C2=A0 =C2=A0 =C2=A0=3D TRUE >> DEFINE SECURE_BOOT_ENABLE=C2=A0 =C2=A0 =C2=A0 =3D TRUE >> BUILD_TARGETS=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =3D RELEASE >> >> and compiled compiled=C2=A0OvmfPkg/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=3D1 >> -enable-kvm -machine smm=3Doff >> -boot order=3Dc *-bios /opt/gns3/images/QEMU/Ovmf.fd* >> -drive file=3D/opt/gns3/projects/1a83274a-c57f-4337-8a0d-1e68a9312e9a/pr= oject-files/qemu/d8f37f0b-2b63-455f-b536-b309b9020e36/hda_disk.qcow2,if=3Di= de,index=3D0,media=3Ddisk >> -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=3D0c:2e:9a:0e:36:00,netdev=3Dgns3-0= -netdev socket,id=3Dgns3-0,udp=3D127.0.0.1:10017,localaddr=3D127.0.0.1:100= 16 >> -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% u= pload completed in my case). >> >> I've drilled down the code and located the 'offending' code here: >> file:=C2=A0NetworkPkg/HttpBootDxe/HttpBootSupport.c >> line#: 1012 >> Offending Code: while (!HttpIo->IsRxDone && ((HttpIo->TimeoutEvent =3D= =3D 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:=C2=A0"Connection":=C2=A0"Keep-Alive"= hoping it will result the HTTP server keeping sessions open. >> Used Wireshark to capture and analyze the packets during download - I co= uld 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 th= e 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 Pc= iRoot(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. >=20 > As I mentioned on edk2-discuss, I'd suggest two tweaks (independently of > each other): >=20 > * try the builting virtio-net driver rather than the iPXE one. For that, > use: >=20 > -device virtio-net-pci,[other properties],romfile=3D"" >=20 > that is, add a 'romfile=3D""' property >=20 > * 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