Michael Chan wrote:
Last update on this.
"udelay( 100 + net_random % 300 )" seems to work much better and i have
not had a single problem getting the link up within 10 seconds of a cold
or warm-boot, and most often the link comes up directly without any sort
of delay instead like before when it could hang for 30 seconds before
getting a link, if you even got a link.
We'll have to do some testing to see if we can find a better solution.
Adding up to 400 usec of busy wait is not ideal. Are you connecting two
5701 fiber cards directly to each other in your setup?
Hi,
Yea, it's and ugly hack, but it's a workaround that at least works for me.
Have done some additional tests and to me it seems that the driver just
needs to wait a bit longer to detect the link + some random time to get
around the issues it might have when chasing the other systems state.
Don't have the numbers in front of me, but i did some tests to get the
'optimum' delay to wait and it seems like the larger the wait time (even
up to around 40-50ms!) causes the autoneg to go much smoother and
faster. And remember that the link can be reported up, but no traffic
can be passed via the link before the autoneg is complete and both cards
reports back that flowcontrol is enabled so you need to verify the link
by trying to send some data and not just look at the link-status.
Hope my conclusions might help, or atleast point you in the right direction.
I have 2
01:08.0 Ethernet controller: Broadcom Corporation NetXtreme BCM5701
Gigabit Ethernet (rev 15) ( 14e4:1645 )
connected via a single FC cable.
And the two systems are one single-core and one dual-core AMD system.
Regards,
Patric
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
