Date: Mon, 09 Sep 2002 23:59:08 +1000 From: Stephen McKay <smckay@internode.on.net> To: Martin Blapp <mb@imp.ch> Cc: current@freebsd.org, Stephen McKay <smckay@internode.on.net> Subject: Re: Uncommitted dc0 fixes ... Message-ID: <200209091359.g89Dx8t12523@dungeon.home> In-Reply-To: <20020904165819.R31964-100000@levais.imp.ch> from Martin Blapp at "Wed, 04 Sep 2002 15:07:48 %2B0000" References: <20020904165819.R31964-100000@levais.imp.ch>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wednesday, 4th September 2002, Martin Blapp wrote:
>And this patch here together with patch III made the annoying messages (dc0:
>failed to force tx and rx to idle mode) go away. And I can use now my card
>without to replug the cable over again)
I've been meaning to remove the annoying message for ages. Sorry about that.
>+ if (DC_IS_INTEL(sc)) {
>+ for (i = 0; i < DC_TIMEOUT; i++) {
>+ isr = CSR_READ_4(sc, DC_ISR);
>+ if (isr & DC_ISR_TX_IDLE &&
>+ (isr & DC_ISR_RX_STATE)
>+ == DC_RXSTATE_STOPPED)
>+ break;
>+ DELAY(10);
>+ }
>+ }
Conditionalising on DC_IS_INTEL() means most cards no longer wait until
the TX and RX are idle. I don't have enough different if_dc cards to
know if this is safe.
On the other hand, every test I've done on my Intel and Macronix cards
shows zero calls to DELAY() in this loop. The loop may as well not be
there for those card types.
Indeed, it isn't there at all in if_de and in a Linux driver I looked
at. From this I'm guessing that no 21143 (real or clone) needs this check,
though I've got no real proof.
Out of all this fuzzy evidence, I guess the most sensible option is the
patch you've proposed. If nobody else is interested, I'll commit this part
of your patch cluster on the weekend. I suppose I could do the ADMtek
auto tx underrun recover patch too, as it seems harmless to other cards.
The other stuff I can't test at all.
This driver represents a counterintuitive state of affairs. I was impressed
when Bill Paul managed to support so many clone cards with one driver. But
now nobody has enough hardware on hand to test any change properly. There's
some sort of lesson to be learnt here.
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?200209091359.g89Dx8t12523>