Path: utzoo!utgpu!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!mailrus!cornell!uw-beaver!rice!sun-spots-request
From: slevy@uf.msc.umn.edu (Stuart Levy)
Newsgroups: comp.sys.sun
Subject: Re: ie1 problems on Sun 4/280 solved
Message-ID: <2370@kalliope.rice.edu>
Date: 19 Dec 88 22:16:01 GMT
Sender: usenet@rice.edu
Organization: Sun-Spots
Lines: 27
Approved: Sun-Spots@rice.edu
Original-Date: Fri, 9 Dec 88 10:40:41 CDT
X-Sun-Spots-Digest: Volume 7, Issue 61, message 11 of 12

We have seen (and, likewise, had to uncover ourselves) a similar problem.
We don't have a Sun-4, but do have an MCP card in a Sun-3.  This is a
smart serial card (does synchronous mode, DMA, etc) which Sun supports as
a network interface; we're using it as an HDH interface to ARPAnet.

We encountered the same symptoms -- the IP input queue counter would
gradually increase over time until reaching ifq_maxlen (50) at which point
no more input packets would be accepted even though the queues themselves
were empty.

It turns out the MCP interrupts at priority 4, while all other interfaces
use priority 3, so we get the same effect as you do.  

It's too bad I didn't see your earlier message.

The funny thing was, I actually tried changing the drivers to raise
priority around the IF_ENQUEUE's as well as (effectively) around
IF_DEQUEUE in ipintr() (did that by just making splimp raise to priority 4
rather than 3).  The problem didn't go away, though, I still don't
understand why.

Anyway, maybe Sun will take two such reports more seriously than one,
though it might not be as seriously as we'd like.  They haven't admitted
to us that they've done anything wrong, so far.

	Stuart Levy, Minnesota Supercomputer Center
	slevy@uc.msc.umn.edu