[1501] in linux-net channel archive
Re: again: eth0: Bus master arbitration failure, status 88f2.
daemon@ATHENA.MIT.EDU (Michael Alan Dorman)
Thu Dec 7 18:40:13 1995
Date: Wed, 6 Dec 1995 08:39:19 -0500 (EST)
From: Michael Alan Dorman <mdorman@lot49.med.miami.edu>
To: Carlos Carvalho <carlos@snfep1.if.usp.br>
cc: linux-kernel@vger.rutgers.edu, linux-net@vger.rutgers.edu
In-Reply-To: <199512051954.RAA02869@snfep1.if.usp.br>
On Tue, 5 Dec 1995, Carlos Carvalho wrote:
> As I reported before, I'm getting these msgs. I have a PC/net PCI card
> on a Triton motherboard. Some gurus pointed out that this could be
> caused by a too large latency of the PCI bus. However, I have changed it in the
> BIOS from 16 to 136 ISA clocks without success, so I doubt this is the
> problem. It happens with 1.3.41 and 1.3.45. I can't go back because I
> have an Adapted 2940UW, and support for it has appeared in 1.3.41
> only.
You may not have gotten a response because---as I understand it--it's
reporting a condition about which the kernel can't do much because it's a
hardware issue. It's possible that the driver could handle it better, but
don't hold your breath (from lance.c):
/* The LANCE has been halted for one reason or another (busmaster memory
arbitration error, Tx FIFO underflow, driver stopped it to reconfigure,
etc.). Modern LANCE variants always reload their ring-buffer
configuration when restarted, so we must reinitialize our ring
context before restarting. As part of this reinitialization,
find all packets still on the Tx ring and pretend that they had been
sent (in effect, drop the packets on the floor) - the higher-level
protocols will time out and retransmit. It'd be better to shuffle
these skbs to a temp list and then actually re-Tx them after
restarting the chip, but I'm too lazy to do so right now. dplatt@3do.com
*/
I for one would just be content to see the error messages go away so they
don't fill my logs quite as quickly.
Mike.
--
"I'm a dinosaur. Somebody's digging my bones."
