From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43)
	id 1MhSV8-0001oc-37
	for qemu-devel@nongnu.org; Sat, 29 Aug 2009 14:18:10 -0400
Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43)
	id 1MhSV3-0001nS-D9
	for qemu-devel@nongnu.org; Sat, 29 Aug 2009 14:18:09 -0400
Received: from [199.232.76.173] (port=37756 helo=monty-python.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1MhSV1-0001nH-V1
	for qemu-devel@nongnu.org; Sat, 29 Aug 2009 14:18:03 -0400
Received: from mail.gmx.net ([213.165.64.20]:55417)
	by monty-python.gnu.org with smtp (Exim 4.60)
	(envelope-from <Reimar.Doeffinger@gmx.de>) id 1MhSV1-0003xr-B2
	for qemu-devel@nongnu.org; Sat, 29 Aug 2009 14:18:03 -0400
Date: Sat, 29 Aug 2009 20:17:55 +0200
From: Reimar =?iso-8859-1?Q?D=F6ffinger?= <Reimar.Doeffinger@gmx.de>
Subject: Re: [Qemu-devel] [PATCH] hw/eepro100.c: Use extended TBD only
	where applicable
Message-ID: <20090829181755.GA8977@1und1.de>
References: <4A840090.8050304@redhat.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
In-Reply-To: <4A840090.8050304@redhat.com>
List-Id: qemu-devel.nongnu.org
List-Unsubscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.gnu.org/pipermail/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: Naphtali Sprei <nsprei@redhat.com>
Cc: qemu-devel@nongnu.org

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_BYTE_COUNT)
> 
> 
> I don't feel 100% OK with the "s->device >= i82558B" condition
> since it relies on the numeric (hex) value of those defines, which currently
> is correct, but changes (which I don't forsee now) might break it.

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] = 0x4000;
the value here must be 0x01000 for all 82557 models it seems.