All of lore.kernel.org
 help / color / mirror / Atom feed
From: Roger Luethi <rl@hellgate.ch>
To: Urban Widmark <urban@teststation.com>
Cc: "Ivan G." <ivangurdiev@linuxfreemail.com>,
	Jeff Garzik <jgarzik@mandrakesoft.com>,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH] VIA Rhine stalls: TxAbort handling
Date: Thu, 16 May 2002 02:51:57 +0200	[thread overview]
Message-ID: <20020516005157.GB13388@k3.hellgate.ch> (raw)
In-Reply-To: <20020514035318.GA20088@k3.hellgate.ch> <Pine.LNX.4.33.0205141928410.20379-100000@cola.enlightnet.local>

On Tue, 14 May 2002 19:47:02 +0200, Urban Widmark wrote:
> The backoff algorithm bits have different names (and possibly different
> meaning) for the vt86c100a.

Not according to my data sheet. You may have been confused by the names I
picked: BackAMD should really be MBA. My upcoming patch will change the
names, i.e. AMD becomes MBA.

> My vt86c100a eeprom sets all backoff bits to 0000, but my vt6102 sets it
> to 0010. Since the eeprom is reloaded when the driver opens, why force it
> to "amd"?

You just answered your question. I did it because on my system that is the
way to trigger aborts and I suspected some cards might come up with a
different default value. VIA is clearing that bit in their driver so I
wouldn't be too surprised if even some newer cards did it, too.

> A module parameter would be nice for testing.

For testing the current solution should do. A parameter would make sense if
we come to the conclusion that it would be beneficial for regular users to
make a selection. It just might be. Maybe somebody who is more opinionated
that me would like to step forward and make that call!?

> Ivan, have you tried playing with these bits?

Have _you_?

> Donalds suggestion is that the TxAborts is simply too much collisions.
> Perhaps the eeprom selection of backoff algorithm isn't working well in
> your environment.

No, it works just great. The problem is that the unmodified driver breaks
down as soon as a TxAbort happens. From my limited experience, MBA seems to
be rather aggressive which is a good thing in some situations (e.g. if
nobody cares that you're monopolizing the network).

Roger

      reply	other threads:[~2002-05-16  0:52 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-05-14  3:53 [PATCH] VIA Rhine stalls: TxAbort handling Roger Luethi
2002-05-13 23:51 ` Ivan G.
2002-05-14 17:28   ` Urban Widmark
2002-05-16  0:49   ` Roger Luethi
2002-05-15 21:52     ` Ivan G.
2002-05-16 14:19       ` Roger Luethi
2002-05-14  0:03 ` Ivan G.
2002-05-14 14:11 ` Jeff Garzik
2002-05-14 15:08   ` Roger Luethi
2002-05-14 17:47 ` Urban Widmark
2002-05-16  0:51   ` Roger Luethi [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=20020516005157.GB13388@k3.hellgate.ch \
    --to=rl@hellgate.ch \
    --cc=ivangurdiev@linuxfreemail.com \
    --cc=jgarzik@mandrakesoft.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=urban@teststation.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.