netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: patric <pakar@imperialnet.org>
To: Michael Chan <mchan@broadcom.com>
Cc: netdev <netdev@vger.kernel.org>, mcarlson@broadcom.com
Subject: Re: tg3 issues
Date: Tue, 24 Jul 2007 09:33:02 +0200	[thread overview]
Message-ID: <46A5AB2E.4070401@imperialnet.org> (raw)
In-Reply-To: <1185226496.7922.33.camel@dell>

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


      reply	other threads:[~2007-07-24  7:33 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <469E78A2.80904@imperialnet.org>
2007-07-19 11:19 ` tg3 issues pradeep singh
2007-07-19 11:37   ` Neil Horman
2007-07-19 13:24     ` patric
2007-07-19 17:34       ` Michael Chan
2007-07-20 16:59         ` patric
2007-07-20 19:34           ` Michael Chan
2007-07-20 19:57             ` patric
2007-07-22 11:43               ` patric
2007-07-23 21:34                 ` Michael Chan
2007-07-24  7:33                   ` patric [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=46A5AB2E.4070401@imperialnet.org \
    --to=pakar@imperialnet.org \
    --cc=mcarlson@broadcom.com \
    --cc=mchan@broadcom.com \
    --cc=netdev@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).