From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received-SPF: Pass (sender SPF authorized) identity=mailfrom; client-ip=156.151.31.86; helo=userp2130.oracle.com; envelope-from=aaron.young@oracle.com; receiver=edk2-devel@lists.01.org Received: from userp2130.oracle.com (userp2130.oracle.com [156.151.31.86]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ml01.01.org (Postfix) with ESMTPS id 78F512110784A for ; Thu, 30 Aug 2018 13:17:33 -0700 (PDT) Received: from pps.filterd (userp2130.oracle.com [127.0.0.1]) by userp2130.oracle.com (8.16.0.22/8.16.0.22) with SMTP id w7UKDsqr039819; Thu, 30 Aug 2018 20:17:31 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=to : cc : from : subject : message-id : date : mime-version : content-type : content-transfer-encoding; s=corp-2018-07-02; bh=5+O0kwbISsV6u1zxFGeRPjpcUiKfcreGBGrk15mwuG8=; b=JqaWUUHX+pDmm8EQywwti7lbGLo/1u8XQuJ+xtamCirL9KYJJQnSykxDk6JZBN0g9aZS YtTxf+1JyGq4Lr57HC9l+vRpQCSjhJe5FsC5C+2EBMCHx8Dpb/XayWoessW6BlNgDP2+ tMppNCgNFmDPuLEjiI+9I8pp0Rw5zM5f1Z3mhXklKFNhfS8xAEFO8CEg3kRK3cXHMFMS rJusnuYGe+yHUdoLwvnhZV0zFkWYZC8WLDOfA58L1H4WK6sThPvEH3zD6c4VNc7aYRID YAe4Fmc95hr9v53cFv822DBDIomMveU1A8pWXkE3RKRw1aKaHU4VcDzdYPqt93r8kgZc 8w== Received: from aserv0021.oracle.com (aserv0021.oracle.com [141.146.126.233]) by userp2130.oracle.com with ESMTP id 2m2xhu6wvt-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 30 Aug 2018 20:17:31 +0000 Received: from userv0122.oracle.com (userv0122.oracle.com [156.151.31.75]) by aserv0021.oracle.com (8.14.4/8.14.4) with ESMTP id w7UKHTIs029939 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 30 Aug 2018 20:17:30 GMT Received: from abhmp0003.oracle.com (abhmp0003.oracle.com [141.146.116.9]) by userv0122.oracle.com (8.14.4/8.14.4) with ESMTP id w7UKHTAB001526; Thu, 30 Aug 2018 20:17:29 GMT Received: from [10.159.157.109] (/10.159.157.109) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 30 Aug 2018 13:17:27 -0700 To: edk2-devel@lists.01.org Cc: lersek@redhat.com, brijesh.singh@amd.com From: aaron.young@oracle.com Organization: Oracle Corporation Message-ID: Date: Thu, 30 Aug 2018 13:17:21 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.0 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=nai engine=5900 definitions=9001 signatures=668708 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=1 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1807170000 definitions=main-1808300204 Subject: Regression with PXE boot on OvmfPkg/VirtioNetDxe driver on aarch64 system X-BeenThere: edk2-devel@lists.01.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: EDK II Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Aug 2018 20:17:33 -0000 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US We have encountered what we believe to be a regression in the OvmfPkg/VirtioNetDxe driver. This regression causes PXE boot to fail with the following ASSERT: ASSERT [VirtioNetDxe]/builddir/build/BUILD/ovmf-92d07e48907f/OvmfPkg/VirtioNetDxe/SnpSharedHelpers.c(184): ((BOOLEAN)(0==1)) The failure was encountered on a aarch64/Armv8 system (Ampere server) using the latest mainline (edk2.git/master) code as of 8-28-2018. On a hunch, I reverted the following patchset which resulted in PXE boot being successful - which suggests this patchset is likely the culprit: https://lists.01.org/pipermail/edk2-devel/2017-September/014679.html The command used to initiate the VM PXE boot/install is: virt-install --name guest1 --vcpus 16 --ram 32000 --arch aarch64 --disk guest1.img,size=100 --network type=direct,source=enP4p1s0,model=virtio --pxe NOTE that I also tried simply removing the offending ASSERT() and PXE boot still fails with multiple errors (exceptions of some sort that I didn't log). What I'd like to know: 1. Is this a known failure? 2. Was aarch64 given much testing with this new patchset? 3. Is reverting this patchset a safe workaround for now until a fix is found? Or is there another simple workaround perhaps? 4. Any hunches what the issue could be? Thanks for any info/help/suggestions, -Aaron Young