public inbox for linux-kernel@vger.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox