Date: Thu, 13 Jul 2000 22:46:10 +1000 From: Stephen McKay <mckay@thehub.com.au> To: Stefan Esser <se@freebsd.org> Cc: Stephen McKay <mckay@thehub.com.au>, Bill Paul <wpaul@freebsd.org>, freebsd-current@freebsd.org Subject: dc driver and underruns (was: Strangeness with 4.0-S) Message-ID: <200007131246.WAA05918@dungeon.home> In-Reply-To: <20000710194017.A33002@StefanEsser.FreeBSD.org> from Stefan Esser at "Mon, 10 Jul 2000 19:40:17 %2B0200" References: <200007030749.RAA13446@dungeon.home> <20000704140131.A1734@StefanEsser.FreeBSD.org> <200007041411.AAA18590@dungeon.home> <20000708221341.B2104@StefanEsser.FreeBSD.org> <200007091052.UAA09724@dungeon.home> <20000710194017.A33002@StefanEsser.FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Monday, 10th July 2000, Stefan Esser wrote:
>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 ???
>> 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 ***):
>
> [SNIP: code showing de driver does not reset chip]
I've now read the 21143 chip manual from Intel. What the de driver does
is illegal (the transmitter must be idle when the threshold is changed).
I don't know if it works in practice, the de driver didn't work well for
me. What the dc driver does is overkill. I will implement some changes,
based on the documentation, and see what happens.
Of course, Bill, if you have direct experience that contradicts the
documentation (as if I've never seen incorrect doco...) then I'm all
ears. I also have a very limited range of test hardware.
>I agree, that for chips that need to be completely re-initialized, the
>default might be store-and-forward ...
>There are so many DEC 21x4x clones, all slightly different, and it seems
>that at least a few need the chip reset.
There is already a convenient store-and-forward-only flag that is set
for one of the supported chips. I propose that this flag be set on all
hardware that cannot have the threshold changed without a 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 ;-)
Does anyone here actually measure these latencies? I know for a fact
that nothing I've ever done would or could be affected by extra latencies
that are as small as the ones we are discussing. Does anybody at all
depend on the start-transmitting-before-DMA-completed feature we are
discussing?
Lastly, some people really want to keep the messages. Is hiding them
behind bootverbose enough? Or do I have to add a flag/hint? No, I
haven't looked at the new hint system, so I don't know if I should
be afraid or not. :-)
Stephen.
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200007131246.WAA05918>