From owner-freebsd-stable Sun Jul 9 3:50:55 2000 Delivered-To: freebsd-stable@freebsd.org Received: from smople.thehub.com.au (smople.thehub.com.au [203.143.240.10]) by hub.freebsd.org (Postfix) with ESMTP id 4667C37B5E6; Sun, 9 Jul 2000 03:50:43 -0700 (PDT) (envelope-from mckay@thehub.com.au) Received: from dungeon.home (ppp55.dyn250.pacific.net.au [203.143.250.55]) by smople.thehub.com.au (8.9.3/8.9.1) with ESMTP id UAA74230; Sun, 9 Jul 2000 20:50:27 +1000 (EST) Received: from dungeon.home (localhost [127.0.0.1]) by dungeon.home (8.9.3/8.9.3) with ESMTP id UAA09724; Sun, 9 Jul 2000 20:52:17 +1000 (EST) (envelope-from mckay) Message-Id: <200007091052.UAA09724@dungeon.home> To: Stefan Esser Cc: Stephen McKay , Alan Edmonds , Bill Paul , Chris Wasser , freebsd-stable@freebsd.org Subject: Re: Strangeness with 4.0-S References: <200007030749.RAA13446@dungeon.home> <20000704140131.A1734@StefanEsser.FreeBSD.org> <200007041411.AAA18590@dungeon.home> <20000708221341.B2104@StefanEsser.FreeBSD.org> In-Reply-To: <20000708221341.B2104@StefanEsser.FreeBSD.org> from Stefan Esser at "Sat, 08 Jul 2000 22:13:41 +0200" Date: Sun, 09 Jul 2000 20:52:16 +1000 From: Stephen McKay Sender: owner-freebsd-stable@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Saturday, 8th July 2000, Stefan Esser wrote: >Oh, there are renegotiations after each overrun ??? >They should not be required at all. The Ethernet chip probably supports >writing a new prefetch limit into the register while fully active ... >I have looked at a number of Ethernet controller data sheets. There never >was a warning that the chip must be quiescent when the "early send" limit >is modified. The code at the point that an underrun is detected is: printf("dc%d: TX underrun -- ", sc->dc_unit); if (DC_IS_DAVICOM(sc) || DC_IS_INTEL(sc)) dc_init(sc); After that, it sets the new threshold, or store and forward mode. That conditional (which resets the DE-500 style cards I own), looks deliberate since it is so specific. Either that, or Bill was being conservative. When I get a chance, I will experiment with removing it. >Well, I'd rather have the driver changed to not require a re-negotiation >of the transmission parameters. I haven't read the data sheet yet (downloading now). Then we should know what limitations we have to live with. >But as long as this is not the case, store-and-forward will at least >hide that there is a problem ;-) It hides the problem very well for me. I really can't see the tiniest of performance loss with store and forward. Maybe it's something that only shows up on benchmarks. Stephen. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message