netdev - Re: tg3 issues

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <46A5AB2E.4070401@imperialnet.org>
Date:	Tue, 24 Jul 2007 09:33:02 +0200
From:	patric <pakar@...erialnet.org>
To:	Michael Chan <mchan@...adcom.com>
CC:	netdev <netdev@...r.kernel.org>, mcarlson@...adcom.com
Subject: Re: tg3 issues

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 majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html