public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Roger Luethi <rl@hellgate.ch>
To: linux-kernel@vger.kernel.org
Subject: [PATCH] fix VIA Rhine time outs (some)
Date: Sat, 1 Jun 2002 12:57:45 +0200	[thread overview]
Message-ID: <20020601105745.GA2726@k3.hellgate.ch> (raw)

[-- Attachment #1: Type: text/plain, Size: 1339 bytes --]

If you experience time outs with via-rhine (typically while copying large
files over the network), this patch is for you.

The problem with at least some of the Rhine chips is that they are skipping
one frame when they stop the Tx engine. This means that every time an abort
(due to excessive collisions) occurs, the driver will stall and need a
reset via netdev timeout [1]. The patch addresses that by setting the Tx
ring buffer pointer to where the driver thinks the chip should continue.

Note: this fix is not sufficient for all time out cases, but it should
improve the situation without having negative side effects for anyone. I
have a more comprehensive solution in my development tree, for now I am
curious how many of the time outs people keep reporting persist after this
one is fixed.

Patch is against Jeff's via-rhine.c LK 1.1.14. It should work with the
older version in 2.4.19-pre9 as well.

Roger

[1] The same problem will likely happen with any other Tx error (e.g.
    underrun), abort is just the one I can easily produce here.

    It also seems that the interrupt status is not always reliable. I
    have one report of very mysterious behavior with a VT86C100A which
    seems to produce all kinds of obviously bogus errors. That's
    unrelated though and easier to study once the restart problems
    are fixed.

[-- Attachment #2: via-rhine.c.7.patch --]
[-- Type: text/plain, Size: 663 bytes --]

--- via-rhine.c.org	Sat Jun  1 11:23:33 2002
+++ via-rhine.c	Sat Jun  1 12:19:18 2002
@@ -1502,7 +1502,12 @@ static void via_rhine_error(struct net_d
 		clear_tally_counters(ioaddr);
 	}
 	if (intr_status & IntrTxAbort) {
-		/* Stats counted in Tx-done handler, just restart Tx. */
+		if (debug > 1)
+			printk(KERN_INFO "%s: Abort %4.4x, frame dropped.\n",
+				   dev->name, intr_status);
+		/* We know better than the chip where it should continue */
+		writel(virt_to_bus(&np->tx_ring[np->dirty_tx % TX_RING_SIZE]),
+			   dev->base_addr + TxRingPtr);
 		writew(CmdTxDemand | np->chip_cmd, dev->base_addr + ChipCmd);
 	}
 	if (intr_status & IntrTxUnderrun) {

             reply	other threads:[~2002-06-01 11:16 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-06-01 10:57 Roger Luethi [this message]
2002-06-01 11:55 ` [PATCH] fix VIA Rhine time outs (some) Urban Widmark
2002-06-01 12:52   ` Roger Luethi

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=20020601105745.GA2726@k3.hellgate.ch \
    --to=rl@hellgate.ch \
    --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