I was experiencing many copies of this message on a 4/390 running
SunOS 4.0.3 (I neglected to mention the OS version in my original
posting.....sorry).
This turns out to be a well known bug which manifests itself in
different ways on different architectures. Fortunately, 4/390
machines only report it as an error....some machines actually panic
when this happens.
Patch is the same as the patch for "le0: Transmission stopped",
bug id numbers 1029247, 1019513, 1029316 and 1021518. This
patch is available from the Sun support folks. I'll include a
copy of the README from the patch at the end of this message.
As for why this is happening, I'll let Hal Stern of Sun Consulting
take over:
----------
the message is one of a few (along with "le0:transmission stopped")
that is cured by the patch for the "transmission stopped" message.
the official patch name is "le0:transmission_stopped" and it is
available from 1-800-USA4SUN.
the RINT consistency check that produces this message causes
a panic in 4.0.3c, but just a console message in other 4.x
releases. as far as i can tell, the RINT and "own" bits
indicate whether the lance chip or driver owns the buffer,
and whether or not the lance chip has interrupted (and had
the interrupt acknowledged) for the buffer. flurries of
packets, particuarly packets that arrive while another is being
handed off from chip to driver, can cause the inconsistency
that produces the "RINT but buffer owned by LANCE" message.
the patch to if_le.c modifies the algorithms that prevent
race conditions and generally clean this code up; 4.1 has
a very nice lance driver in it (with all of these patches included).
you didn't say whether you're running 4.0.3 or 4.1; if it's
4.1 then i'm worried.....
there may be a physical reason why the lance chip is giving
the driver so much grief. take a look at the input error rate
with netstat -i and see if you're getting flooded with bad
packets (high ierrs count). if so, then the transceiver
cable may be giving you problems. i've had a number of cables
that just won't work with the lance driver on a 4/390 or 4/490;
using a different cable sometimes helps (i think the real difference
is in Type 2 vs strict 802.3 cabling and the different grounding
used by each).
----------
It is 4.0.3, so I expect this problem to be "fixed in 4.1".
I'm sure I'll get more messages as the day goes on, but for now
thanks to:
Tom Leach <leach@oce.orst.edu>
del@mlb.semi.harris.com (Don Lewis)
John Valdes <valdes@geosun.uchicago.edu>
d3e101@pnl.gov (Bill Eggers)
bond!pawan@bellcore.bellcore.com (Pawan Misra)
bit!markm@cse.ogi.edu (Mark Morrissey)
halstern@Sun.COM (Hal Stern)
"Timothy G. Smith" <timsmith@sun.com>
kam@titan.tsd.arlut.utexas.edu (Katherine Minister Hosch)
creagh@forestbear.Corp.Sun.COM (Creagh Yates)
William LeFebvre
Computing Facilities Manager and Analyst
Department of Electrical Engineering and Computer Science
Northwestern University
<phil@eecs.nwu.edu>
Here is the README from the patch (sent to me by several people):
This tape contains new versions of the Unix kernel object
file if_le.o for SunOS 4.0.3.
This patch contains a slightly modified 4.0.3[c] lance ethernet
driver (if_le.c) and object files for sun3x (hydra), sun4 (stingray),
and sun4c (SPARCstation1) as an effective patch for 4.0.3[c] lance
xmit memory underflow ("transmission stopped").
1. Increase LANCE_MIN_TU from 100 to 102, this effectively
eliminates UFLO (!)
2. Minimize leintr lance slave register accesses -
this is also a factor in UFLO.
3. Never print "Transmission stopped" or "memory underflow"
error messages.
This patch also fixes the panic: le0: RINT: Buffer owned by chip
problem.
Architecture:
Sun-3x, Sun-4, Sun-4c
Release:
4.0.3
Bug Report Id:
1029247, 1019513, 1029316 and 1021518
Installation Instructions:
This tape is a tar archive. To extract the archive:
# cd /usr/tmp
# tar xvf <tape-device>
where <tape-device> is /dev/rst0 or /dev/rmt8
This tape should have the following files:
README
if_le.sun3x
if_le.sun4
if_le.sun4c
Be sure to save the original file as something like
if_le.o.old, i.e.:
# cd /sys/`arch`/OBJ
# mv if_le.o if_le.o.old
Move the new file to the correct location:
# mv /usr/tmp/if_le.'arch' /sys/'arch'/OBJ/if_le.o
Set the modes and ownership of the new file, i.e.:
# chmod 444 if_le.o
# chown root if_le.o
You will then need to rebuild and boot a new kernel.
--------------------
This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:05:58 CDT