From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from list by lists.gnu.org with archive (Exim 4.71) id 1ZN5I4-0007iM-Cc for mharc-grub-devel@gnu.org; Wed, 05 Aug 2015 16:27:56 -0400 Received: from eggs.gnu.org ([2001:4830:134:3::10]:39803) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZN5I1-0007hZ-Vo for grub-devel@gnu.org; Wed, 05 Aug 2015 16:27:54 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZN5Hu-0000Ja-HR for grub-devel@gnu.org; Wed, 05 Aug 2015 16:27:53 -0400 Received: from mx0b-00082601.pphosted.com ([67.231.153.30]:44199) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZN5Hu-0000IR-CS for grub-devel@gnu.org; Wed, 05 Aug 2015 16:27:46 -0400 Received: from pps.filterd (m0004060 [127.0.0.1]) by mx0b-00082601.pphosted.com (8.14.5/8.14.5) with SMTP id t75KRK0K019683; Wed, 5 Aug 2015 13:27:44 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=fb.com; h=message-id : date : from : mime-version : to : cc : subject : references : in-reply-to : content-type : content-transfer-encoding; s=facebook; bh=zcrvI0K8kltbNQSJg7hi82rMBVVI0fa5m8EBmp898ns=; b=IXbgbIxpjIgFIu1BYVxu3Q8S0dZvHvYFmct05sC3+b8a+9VJ0oRm+Ogoo3kXrpQu6k/8 KJnXliew96wCK3Yr+iq5+/wAr4Ok9TLw01RlZ3OAnr7DBZKOmtMPnWUn9U2jKxUSvJLi dgAynNRbFec+hqcZWoCaY/l5EhzIapW2lPY= Received: from mail.thefacebook.com ([199.201.64.23]) by mx0b-00082601.pphosted.com with ESMTP id 1w3rf70b2n-4 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 05 Aug 2015 13:27:44 -0700 Received: from localhost.localdomain (192.168.52.123) by mail.thefacebook.com (192.168.16.19) with Microsoft SMTP Server (TLS) id 14.3.195.1; Wed, 5 Aug 2015 13:26:35 -0700 Message-ID: <55C27179.6020104@fb.com> Date: Wed, 5 Aug 2015 16:26:33 -0400 From: Josef Bacik User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Andrei Borzenkov Subject: Re: [PATCH 1/3] efinet: handle get_status() properly References: <1438799799-32097-1-git-send-email-jbacik@fb.com> <20150805230442.1bf65b2d@opensuse.site> In-Reply-To: <20150805230442.1bf65b2d@opensuse.site> Content-Type: text/plain; charset="utf-8"; format=flowed X-Originating-IP: [192.168.52.123] X-Proofpoint-Spam-Reason: safe X-FB-Internal: Safe X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.14.151, 1.0.33, 0.0.0000 definitions=2015-08-05_10:2015-08-05, 2015-08-05, 1970-01-01 signatures=0 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by mx0b-00082601.pphosted.com id t75KRK0K019683 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.4.x X-Received-From: 67.231.153.30 Cc: grub-devel@gnu.org, mchang@suse.com X-BeenThere: grub-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: The development of GNU GRUB List-Id: The development of GNU GRUB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Aug 2015 20:27:55 -0000 On 08/05/2015 04:04 PM, Andrei Borzenkov wrote: > =D0=92 Wed, 5 Aug 2015 14:36:37 -0400 > Josef Bacik =D0=BF=D0=B8=D1=88=D0=B5=D1=82: > >> The EFI SNP documentation isn't super clear on the value that is retur= ned in >> txbuf when calling into GetStatus. The documentation says its the poi= nter to >> the recycle buffer, but the documentation for Transmit() says that it = should be >> the pointer to the buffer that we transmitted. > > Actually it says "Recycled transmit buffer address" and further > "GetStatus() until the transmitted buffer shows up in the recycled > transmit buffer" so it looks reasonably clear to me. > >> On the boxes I'm using = it's just >> a random pointer (usually 0x1). It is definitely transmitting stuff, = but the >> get_status call is not returning the pointer to the txbuf we passed in. > > Which sounds like firmware bug. To be sure - you observe it also using > current GIT master? > This is on git master as of last week, so I have your latest patch efinet: enable hardware filters when opening interface and it was still happening. I know what Transmit() says, but=20 GetStatus() says it'll just be a pointer to the recycled transmit buffer=20 address, which to me could mean the pointer to whatever the internal=20 queue was being used by UEFI. Anyway that's not important, what is=20 important is that the current code doesn't work with hardware that=20 exists in the wild. If it's a firmware bug then fine, what do users do=20 if they have buggy firmware that isn't being updated anymore? I think=20 making grub more tolerant to crappy firmware is a good thing. Thanks, Josef