public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Brian Somers <brian.somers@sun.com>
To: "David S. Miller" <davem@redhat.com>
Cc: Mike Waychison <Michael.Waychison@sun.com>, linux-kernel@vger.kernel.org
Subject: Re: TG3 doesn't work in kernel 2.4.27 (David S. Miller)
Date: Thu, 26 Aug 2004 11:49:57 +0100	[thread overview]
Message-ID: <412DC055.4070401@sun.com> (raw)
In-Reply-To: <20040825175805.6807014c.davem@redhat.com>

Hi,

David S. Miller wrote:
> On Wed, 25 Aug 2004 16:04:57 -0400
> Mike Waychison <Michael.Waychison@Sun.COM> wrote:
> 
> 
>>If I understand it correctly, the problem we were seeing is that the
>>chip was getting framing errors in high-traffic scenarios.  Setting it
>>to use hardware autoneg made these errors disappear.  It's possible we
>>need some other work-around.. :\
> 
> 
> So what rev 5704 chips were in Sun's Opteron boxes where you
> saw the problem?  A0/A1 chips?

First, forgive the lack of specifics here, I haven't got access to any
of the hardware in question right now...

The issue was actually seen in Sun's x86 blades - the B200x boxes.  They
were using A3 parts (2 of them per box == 4 interfaces), although a
comment was added with one of the last modifications (unrelated to the
autoneg stuff) that said it was tested on an A2 part, so I guess there
were a number of them about too.  The machine had a PCI-X bus running at
64bits and either 66 or 133MHz (I think it was 133MHz, but I may be
wrong!).

The issue was that the frame error count was being bumped and we were
losing traffic under load.  From what I can remember it averaged
something like one in 30000 packets being dropped, but it may have
been slighly less frequent than that.

After the hardware guys here had ruled out any cross-talk possibilities,
I talked to Broadcom about it and they suggested that we enable
hardware autoneg.  The reasoning was that when hw autoneg is enabled,
the chip has a completely different code path for incoming traffic
where it doesn't have to look inside every packet to see if it's a
negotiation frame.  This increased throughput enough to defeat the
framing errors we were seeing.

The changes I made were reviewed by Broadcom and they seemed happy
that hw autoneg was enabled for all 5704 silicon revisions...


It's a bit strange that it stopped working only with the latest 2.4
version of tg3 - I wonder if the driver's actually coming back with
``HW autoneg failed'' in this scenario?  Perhaps there's a compat
issue between the switch and the Broadcom hw autoneg engine?

Can we get this guy to try running an older version of tg3 to see
what change introduce the issue?

Another interesting point was that the guy who wrote the bcm driver
for Solaris had problems enabling hw autoneg.  AFAIR he said that
when he enabled it, MAC_STATUS_PCS_SYNCED never turned up again.  I
don't know if this issue was ever resolved, and he no longer works
for Sun.  I never saw this issue under Linux.

-- 
Brian Somers                                            Sun Microsystems
                                             Sparc House, Guillemont Park
Software Engineer - LSE                          Minley Road, Blackwater
Tel: +44 1252 421 263   Ext: 21263                    Camberley GU17 9QG


  reply	other threads:[~2004-08-26 10:50 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20040816110000.1120.31256.Mailman@lists.us.dell.com>
2004-08-16 11:51 ` TG3 doesn't work in kernel 2.4.27 (David S. Miller) Tetsuo Handa
2004-08-16 21:38   ` David S. Miller
2004-08-25 17:48     ` Mike Waychison
2004-08-25 19:08       ` David S. Miller
2004-08-25 20:04         ` Mike Waychison
2004-08-26  0:58           ` David S. Miller
2004-08-26 10:49             ` Brian Somers [this message]
2004-08-26 19:37               ` David S. Miller
2004-08-29  9:56                 ` Pekka Pietikainen
2004-09-10 12:35                 ` Brian Somers
2004-09-10 19:40                   ` Roland Dreier
2004-09-10 20:53                   ` David S. Miller
2004-09-10 21:05                     ` Roland Dreier
2004-09-10 21:45                       ` David S. Miller
2004-09-10 22:14                     ` Brian Somers
2004-08-30 23:11               ` David S. Miller
2004-09-03 19:12                 ` Paul Larson
2004-09-03 19:19                   ` Mike Waychison
2004-09-03 20:18                     ` Roland Dreier
2004-09-03 20:30                       ` David S. Miller
2004-09-03 20:40                         ` Roland Dreier
2004-09-03 23:24                         ` Roland Dreier
2004-09-07 18:33                           ` Jake Moilanen
2004-09-07 19:52                             ` Roland Dreier
2004-09-08 12:34                               ` Jake Moilanen
2004-09-08 13:07                                 ` Anton Blanchard
2004-09-13 22:48                                   ` David S. Miller
2004-09-14 22:20                                     ` Mike Waychison
2004-09-14 22:36                                       ` David S. Miller
2004-09-14 22:58                                       ` Jake Moilanen
2004-09-15  0:34                                       ` Roland Dreier
2004-09-08 13:55                                 ` Paul Larson
2004-09-10 16:00                                   ` Paul Larson
2004-09-03 20:08                   ` David S. Miller

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=412DC055.4070401@sun.com \
    --to=brian.somers@sun.com \
    --cc=Michael.Waychison@sun.com \
    --cc=davem@redhat.com \
    --cc=linux-kernel@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