On Tue, 15 Feb 2000, Craig Kulesa wrote:
> Summary: The 8390 driver (as tested by the 3c503 module, among others)
> doesn't work for me on any tested ethernet cards that require it.
Here's the followup...
NEW Summary: The stock 2.3.45 code works fine, but only if you specify the
3c503 module options in modprobe (i.e. xcvr) explicitly.
It's no longer a really good idea, it's the LAW! :)
Details:
Here's a followup to my previous posting that may prove useful if there
are others puzzling over their "broken" 3c503 cards since 2.3.43.
After some additional testing, my "fix" to the 8390 driver tends to cause
too many unnecessary calls to the timeout code, leading to slower
performance. However, it still seemed apparent that a few initial timeout
calls were necessary to "wake" the card from its slumber. A closer
inspection of the code showed the problem... initiated by David Miller
convincing me that referencing &dev->state was in fact correct, and all
references to &dev->flags by other net drivers in this context were wrong.
By default, these 486's were configured with no options passed to the
3c503 module. In the past, the if(dev->tbusy) check forced the 8390 code
into the timeout loop, where it stayed until the adopted interface was
switched from internal transceiver (module default) to the desired
external transceiver (AUI). After this brief initial delay, the driver
worked correctly.
With the new networking changes, a bad assumption about the xcvr will not
lead one into that "sanity-checking" timeout loop, since
"test_bit(LINK_STATE_XOFF, &dev->state)" happily stays at 0 and that code
is never executed. Explicitly setting the xcvr to 1 as a module option
was the fix! And while at it, one may as well set the "io=" option
explicitly as well... :)
So my posted "fix" seemed to do the right thing as it forced the 8390 to
go into the timeout loop on occasion, thereby intercepting the code to
change transceiver type. But it doesn't really do the "right" thing.
Perhaps that transceiver switching code is no longer necessary in that
timeout loop? This might be worth checking on other 8390-dependent cards.
Moral of the story: module options are your friends.
Craig Kulesa
ckulesa@as.arizona.edu
========================================================================
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Wed Feb 23 2000 - 21:00:19 EST