Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!seismo!rutgers!ames!sdcsvax!ucbvax!decvax!dartvax!steve
From: steve@dartvax.UUCP (Steve Campbell)
Newsgroups: comp.unix.wizards
Subject: Re: de0: buffer unavailable
Message-ID: <6880@dartvax.UUCP>
Date: Sun, 16-Aug-87 13:00:28 EDT
Article-I.D.: dartvax.6880
Posted: Sun Aug 16 13:00:28 1987
Date-Received: Mon, 17-Aug-87 00:37:01 EDT
References: <8776@brl-adm.ARPA>
Reply-To: steve@dartvax.UUCP (Steve Campbell)
Organization: Dartmouth College, Hanover, NH
Lines: 31

In article <8776@brl-adm.ARPA> mullen@nrl-css.arpa (Preston Mullen) writes:
>A Vax 750 running Ultrix 1.1 (groan) started to give off zillions of
>	de0: buffer unavailable
>messages on the console (one or two every few seconds)....

Precisely the same thing happened here.  Ultrix support people suggested
changing the value of NRCV (the number of receive buffers) from 4 to 8
in /sys/data/if_de_data.c and making a new kernel.  Even binary licensees
can do this.  It was an intelligent suggestion, but by itself it didn't
solve the problem.  But I left it in anyway.  [4.3BSD has a value of 7.]

Running "netstat 10" on the effected 750 showed that once a minute
there was a burst of broadcast packets, roughly equal in number to the
number of TCP/IP hosts on the ethernet.  We then went to a Sun that's
on the wire and ran the etherfind(8C) program, which watches all
packets on the ethernet and prints out their type, source, destination,
etc.  [This is a VERY handy tool.  Does anyone have something
comparable for VAXen under BSD??]  The cause of the problem jumped out
at us: one host (not the 750) was using 0xFF as the host part of the
broadcast packet it was sending out for rwho.  That is, it was using
the new 4.3 broadcast address, while everyone else, including the 750,
is still using the old address (0x0).  See "Installing & Operating" in
your BSD documentation for details.  And as soon as that host blurted
out that "bad" broadcast packet, every other host on the wire answered
with a broadcast packet of its own.  I do not know exactly what those
packets where supposed to be doing; maybe someone else can explain.
But once we fixed that one errant host, everything went back to normal,
and the 750 even shut up.

						Steve Campbell
						Dartmouth College