From owner-freebsd-stable Mon Jul 10 10:43:17 2000 Delivered-To: freebsd-stable@freebsd.org Received: from mout1.freenet.de (mout1.freenet.de [194.97.50.132]) by hub.freebsd.org (Postfix) with ESMTP id A3D6A37B591; Mon, 10 Jul 2000 10:43:12 -0700 (PDT) (envelope-from se@freebsd.org) Received: from [194.97.50.138] (helo=mx0.freenet.de) by mout1.freenet.de with esmtp (Exim 3.15 #1) id 13BhaG-00057g-00; Mon, 10 Jul 2000 19:43:08 +0200 Received: from a630d.pppool.de ([213.6.99.13] helo=StefanEsser.FreeBSD.org) by mx0.freenet.de with esmtp (Exim 3.15 #1) id 13BhaF-0005mV-00; Mon, 10 Jul 2000 19:43:08 +0200 Received: by StefanEsser.FreeBSD.org (Postfix, from userid 200) id AC0B4DBA; Mon, 10 Jul 2000 19:40:17 +0200 (CEST) Date: Mon, 10 Jul 2000 19:40:17 +0200 From: Stefan Esser To: Stephen McKay Cc: Alan Edmonds , Bill Paul , Chris Wasser , freebsd-stable@freebsd.org, Stefan Esser Subject: Re: Strangeness with 4.0-S Message-ID: <20000710194017.A33002@StefanEsser.FreeBSD.org> Reply-To: Stefan Esser References: <200007030749.RAA13446@dungeon.home> <20000704140131.A1734@StefanEsser.FreeBSD.org> <200007041411.AAA18590@dungeon.home> <20000708221341.B2104@StefanEsser.FreeBSD.org> <200007091052.UAA09724@dungeon.home> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: <200007091052.UAA09724@dungeon.home>; from mckay@thehub.com.au on Sun, Jul 09, 2000 at 08:52:16PM +1000 Sender: owner-freebsd-stable@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On 2000-07-09 20:52 +1000, Stephen McKay wrote: > 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, the DE Driver (DEC 21x4x) has (relevant lines marked ***): if (csr & TULIP_STS_ABNRMLINTR) { u_int32_t tmp = csr & sc->tulip_intrmask & ~(TULIP_STS_NORMALINTR|TULIP_STS_ABNRMLINTR); *** if (csr & TULIP_STS_TXUNDERFLOW) { *** if ((sc->tulip_cmdmode & TULIP_CMD_THRESHOLDCTL) != TULIP_CMD_THRSHLD160) { *** sc->tulip_cmdmode += TULIP_CMD_THRSHLD96; *** sc->tulip_flags |= TULIP_NEWTXTHRESH; } else if (sc->tulip_features & TULIP_HAVE_STOREFWD) { sc->tulip_cmdmode |= TULIP_CMD_STOREFWD; sc->tulip_flags |= TULIP_NEWTXTHRESH; } } if (sc->tulip_flags & TULIP_NOMESSAGES) { sc->tulip_statusbits |= tmp; } else { tulip_print_abnormal_interrupt(sc, tmp); sc->tulip_flags |= TULIP_NOMESSAGES; } *** TULIP_CSR_WRITE(sc, csr_command, sc->tulip_cmdmode); and later: if (sc->tulip_flags & TULIP_NEEDRESET) { tulip_reset(sc); tulip_init(sc); } But since TULIP_NEEDRESET has not been set in tulip_cmdmode, no chip reset is performed. I did not know, that the DC driver is different, but the specific test on Davicom and Intel chips seems to indicate, that Bill Paul knows what he is doing ... ;-) I agree, that for chips that need to be completely re-initialized, the default might be store-and-forward ... > >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. There are so many DEC 21x4x clones, all slightly different, and it seems that at least a few need the chip reset. > 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. Guess it will show up if you measure latencies (or your application is doing lots of RPCs). But as soon as there is a cheap 100baseT switch in the path to the destination, there will be store-and-forward at work ;-) Regards, STefan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message