From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Mi9dC-00055b-Q5 for qemu-devel@nongnu.org; Mon, 31 Aug 2009 12:21:22 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Mi9d8-00051p-38 for qemu-devel@nongnu.org; Mon, 31 Aug 2009 12:21:22 -0400 Received: from [199.232.76.173] (port=52973 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Mi9d7-00051b-Sr for qemu-devel@nongnu.org; Mon, 31 Aug 2009 12:21:17 -0400 Received: from mx1.redhat.com ([209.132.183.28]:4285) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1Mi9d6-0003eB-5G for qemu-devel@nongnu.org; Mon, 31 Aug 2009 12:21:17 -0400 Message-ID: <4A9BF86A.70903@redhat.com> Date: Mon, 31 Aug 2009 19:20:58 +0300 From: Naphtali Sprei MIME-Version: 1.0 References: <4A840090.8050304@redhat.com> <20090829181755.GA8977@1und1.de> In-Reply-To: <20090829181755.GA8977@1und1.de> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Subject: [Qemu-devel] [PATCH] Fix for commit 3f9cb1c14dc368f41447db5f78d6248c4f100ad4 List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: =?ISO-8859-1?Q?Reimar_D=F6ffinger?= , qemu-devel@nongnu.org Here's a patch to fix the issue introduced by me, as Reimar D=F6ffinger p= ointed out, Reimar D=F6ffinger wrote: > On Thu, Aug 13, 2009 at 03:01:20PM +0300, Naphtali Sprei wrote: >> Bug fix for segfault when run as i82551 HW: >> Use Extended TBD only when HW supports it (i82558 and up). >> >> Added assertions to guard from such buffer overflow >> Introduce the MAX_TCB_BYTE_COUNT macro >> Allocate buf big enough as HW needs (MAX_ETH_FRAME_SIZE -> MAX_TCB_BYT= E_COUNT) >> >> >> I don't feel 100% OK with the "s->device >=3D i82558B" condition >> since it relies on the numeric (hex) value of those defines, which cur= rently >> is correct, but changes (which I don't forsee now) might break it. >=20 > It seems this was applied. Unfortunately this breaks things on FreeBSD. > There seem to be multiple issues. > First, the intel document says the 82551, 82550, 82559 models are all > supersets of the 82558. Or in other words: they all support this > feature. > Only the 82557 does not. > But then even for that the FreeBSD driver will fail. > The reason for that is this line: > eeprom_contents[0xa] =3D 0x4000; > the value here must be 0x01000 for all 82557 models it seems. Correct the logic of determining devices that supports extended TxCB: only the 82557 do not support it. Signed-off-by: Naphtali Sprei --- hw/eepro100.c | 7 ++++++- 1 files changed, 6 insertions(+), 1 deletions(-) diff --git a/hw/eepro100.c b/hw/eepro100.c index c374931..287b462 100644 --- a/hw/eepro100.c +++ b/hw/eepro100.c @@ -575,6 +575,11 @@ static uint16_t eepro100_read_command(EEPRO100State = * s) } #endif =20 +static bool device_supports_eTxCB(EEPRO100State * s) +{ + return (s->device !=3D i82557B && s->device !=3D i82557C); +} + /* Commands that can be put in a command list entry. */ enum commands { CmdNOp =3D 0, @@ -717,7 +722,7 @@ static void eepro100_cu_command(EEPRO100State * s, ui= nt8_t val) } else { /* Flexible mode. */ uint8_t tbd_count =3D 0; - if ((s->device >=3D i82558B) && !(s->configuration[6] & = BIT(4))) { + if (device_supports_eTxCB(s) && !(s->configuration[6] & = BIT(4))) { /* Extended Flexible TCB. */ assert(tcb_bytes =3D=3D 0); for (; tbd_count < 2; tbd_count++) { --=20 1.6.3.3