Date: Mon, 10 Jul 2000 19:40:17 +0200 From: Stefan Esser <se@freebsd.org> To: Stephen McKay <mckay@thehub.com.au> Cc: Alan Edmonds <aedmonds@digitalconvergence.com>, Bill Paul <wpaul@freebsd.org>, Chris Wasser <cwasser@v-wave.com>, freebsd-stable@freebsd.org, Stefan Esser <se@freebsd.org> Subject: Re: Strangeness with 4.0-S Message-ID: <20000710194017.A33002@StefanEsser.FreeBSD.org> In-Reply-To: <200007091052.UAA09724@dungeon.home>; from mckay@thehub.com.au on Sun, Jul 09, 2000 at 08:52:16PM %2B1000 References: <200007030749.RAA13446@dungeon.home> <20000704140131.A1734@StefanEsser.FreeBSD.org> <200007041411.AAA18590@dungeon.home> <20000708221341.B2104@StefanEsser.FreeBSD.org> <200007091052.UAA09724@dungeon.home>
next in thread | previous in thread | raw e-mail | index | archive | help
On 2000-07-09 20:52 +1000, Stephen McKay <mckay@thehub.com.au> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20000710194017.A33002>