[comp.unix.aux] ethernet overflow errors

oberst@phoenix.Princeton.EDU (Daniel J. Oberst) (01/10/89)

answered.  Several times when I have left A/UX running unattended
overnight (I usually run my MacII with MacOS during the day) I have
come in to see the following error messages:

	ae0:overflow NIC reset failed
	ae6_intr:Receive overflow warning
	ku_fastsend: if_output failed: error=70, sendpck=0, am=0

Has anyone else seen this?  Any idea what is causing it?  I am still
awaiting an upgrade to my (older) Ethertalk board.  Could it be the
source of the problem?

kucharsk@uts.amdahl.com (William Kucharski) (01/11/89)

In article <5262@phoenix.Princeton.EDU>, oberst@phoenix.Princeton.EDU (Daniel J. Oberst) writes:
> answered.  Several times when I have left A/UX running unattended
> overnight (I usually run my MacII with MacOS during the day) I have
> come in to see the following error messages:
> 
> 	ae0:overflow NIC reset failed
> 	ae6_intr:Receive overflow warning
> 	ku_fastsend: if_output failed: error=70, sendpck=0, am=0

We've had a similar problem at our site.  Basically, it seems A/UX can't
deal with much Ethernet traffic.  If your Ethernet is at all heavily used,
the system will print the first two messages and bring the Ethernet card
off-line.  Perhaps that is the source of your third message.  I don't know
how to fix it, I'm just waiting for a fix from Apple.  (From what I hear
A/UX 1.1 fixes this, but when that will be out is another question...)

-- 
					William Kucharski

ARPA: kucharsk@uts.amdahl.com
UUCP: ...!{ames,decwrl,sun,uunet}!amdahl!kucharsk

Disclaimer:  The opinions expressed above are my own, and may not agree with
	     those of any other sentient being, not to mention those of my 
	     employer.  So there.

king@orion.arc.nasa.gov (Frank S. King) (01/11/89)

	Daniel J. Oberst writes:

answered.  Several times when I have left A/UX running unattended
overnight (I usually run my MacII with MacOS during the day) I have
come in to see the following error messages:

	ae0:overflow NIC reset failed
	ae6_intr:Receive overflow warning
	ku_fastsend: if_output failed: error=70, sendpck=0, am=0

Has anyone else seen this?  Any idea what is causing it?  I am still
awaiting an upgrade to my (older) Ethertalk board.  Could it be the
source of the problem?
=====================================================================
I used to have the same problem with my machine. Some time ago some
one posted a good suggestion that seemed to have cured the overflow 
problem. Try 
		kconfig -n /unix
		NMBUFS=800
		^d
		sync
		sync
		reboot
This will allocate 300 more buffers for networking, the default is 500.
you can read the manpages on kconfig to get the details on NMBUFS.

	Best of luck
		ANTHONY INTRAVAIA
		NASA AMES RESEARCH CENTER
		Space Life Sciences Payloads Office

liam@cs.qmc.ac.uk (William Roberts) (01/11/89)

In article <ecXu9c3TV410102tQOg@amdahl.uts.amdahl.com> kucharsk@uts.amdahl.com (William Kucharski) writes:
>>      ku_fastsend: if_output failed: error=70, sendpck=0, am=0
>
>We've had a similar problem at our site.  Basically, it seems A/UX can't
>deal with much Ethernet traffic.  If your Ethernet is at all heavily used,
>the system will print the first two messages and bring the Ethernet card
>off-line.

We never see this problem, and our Ethernet is fairly well
loaded (130+ machines inc Macs/Suns, lots of EtherTalk, lots of
TCP/IP, a few diskless Suns, 45 machines mounting virtually
everything from file servers via NFS, etc., etc.).
However, we are using the Kinetics EtherPort II cards,
so this may be a difference at that level (hardware/driver).

For what it's worth, ku_fastsend is probably associated with NFS
and the error=70 is a standard errno message, namely ENETDOWN,
which is what you'd expect if the driver has just turned its
toes to the sky...
-- 

William Roberts         ARPA: liam@cs.qmc.ac.uk  (gw: cs.ucl.edu)
Queen Mary College      UUCP: liam@qmc-cs.UUCP
LONDON, UK              Tel:  01-975 5250

mmeyer@mcdurb.Urbana.Gould.COM (01/12/89)

I don't have a MAC-II, but the ku_fastsend you see is a procedure 
inside of NFS that takes NFS data/requests/etc adds a UDP and IP header,
and calls (*ifp->if_output)(...) .  Heavy NFS traffic could possibly 
be the cause of the Ethernet hang.

		--morris

Morris Meyer   mmeyer@urbana.mcd.mot.com   uunet!uiucdcs!mcdurb!mmeyer
   Motorola Microcomputer Division, Champaign-Urbana Design Center
	   1101 E. University, Urbana, Illinois 61801, USA.
   
My opinions are my own, and are not the opinions of my employer, or
any other organisation.