Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/18/84; site ulysses.UUCP
Path: utzoo!watmath!clyde!cbosgd!ihnp4!ucbvax!ulysses!smb
From: smb@ulysses.UUCP (Steven Bellovin)
Newsgroups: net.unix-wizards
Subject: Re: deuna driver problems in 4.[23]
Message-ID: <1117@ulysses.UUCP>
Date: Mon, 7-Oct-85 14:02:19 EDT
Article-I.D.: ulysses.1117
Posted: Mon Oct  7 14:02:19 1985
Date-Received: Tue, 8-Oct-85 04:17:34 EDT
References: <1810@brl-tgr.ARPA>
Organization: AT&T Bell Laboratories, Murray Hill
Lines: 28

> 
> On several of my deuna machines,  I get the following message
> de0:buffer unavailable
> This is unrelated to the load on the machine (as far as I can tell,
> I get them on idle machines and on buisy machines).
> 
> There is another problem that sometimes rears it's ugly head.
> 
> the machine becomes unable to transmit,  even though it is able to
> receive.
> The only toggle I have for this condition is a program that sends a
> large umber of udp packets in a lump.

We have similar problems on our 750s with 3Com boards.  Sometimes, for no
apparent reason, the board will stop transmitting packets.  A (modified)
netstat -i shows 50 packets queued for output, with lots of drops indicated.
Ruptime on the afffected machine will show everyone else up, indicating
packets are being received.  This has never happened with our DEUNAs, or
on our 780s.  One possible clue:  on one machine, we have the 3Com board
on the same UBA as a KMC with line unit (for RJE); when the 3Com board hangs,
the KMC hangs as well.  But a DEUNA and a DMR-11 on the same UNIBUS remain
alive and well.

Suggestions, anyone?  I'm contemplating a sanity timer on the transmit interrupt
to reinitialize the board when a transmission has taken too long.


		--Steve Bellovin