On Sat, 24 Apr 2004, David Burns wrote:
Hello all,
It appears that quite a few of the "el cheapo" hardware Fast Ethernet drivers (at least rl, sis, ste, vr, wb - these are just the ones I found in /usr/src/sys/pci) have added DELAY(1) statements around MII serial clock ops which will result in a max Management Data Clock (MDC) frequency of 500kHz for the serial management interface. Which means that a mii_readreg (or writereg) operation will take a minimum of 128?s (64?s for mii_sync + 64?s for data read/write). During which time the driver is locked.
This is an old problem, most of us leave it alone because hardware can break in strange ways. :)
I was afraid someone would say that... :-)
We should still implement this where testing succeeds on at least a few hardware platforms.
Alternatively implement a driver.mii_phy_fast tunable which allows the DELAY to be disabled.
NB this assumes that a DELAY(1) is really a delay of 1?s! Which I don't think it is ... :-(
Correct, DELAY takes far longer than it should.
If you're really interested in fixing the problem and not inadvertantly breaking older cards, what you should do is implement a nanodelay function that actually delays for the time it's supposed to and then delay the rated amount. Removing all delays will probably break something somewhere.
We could probably build a driver specific nanodelay function based on dummy PCI operations. Some will say this sucks but then I'd argue it's better than the current DELAY implementation.
Of course just sending one bit of data on the MDIO will take us about 600 nanoseconds - resulting in a 1.6MHz clock.
Probably need input from the guys who originally cut these drivers years ago (eg wpaul) to help identify the pathological PHYs out there...
David _______________________________________________ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
