Return to BSD News archive
Path: sserve!newshost.anu.edu.au!harbinger.cc.monash.edu.au!bunyip.cc.uq.oz.au!munnari.oz.au!news.Hawaii.Edu!ames!pacbell.com!ihnp4.ucsd.edu!news.cerf.net!mvb.saic.com!MathWorks.Com!europa.eng.gtefsd.com!news.umbc.edu!haven.umd.edu!umd5.umd.edu!mark
From: mark@elea.umd.edu (Mark Sienkiewicz)
Newsgroups: comp.os.386bsd.questions
Subject: Re: Strange network stuff
Date: 11 May 1994 21:36:58 GMT
Organization: Zeno, IPST, University of Maryland
Lines: 57
Message-ID: <2qrj5q$2h8@umd5.umd.edu>
References: <2qpr6c$dsh@agate.berkeley.edu>
NNTP-Posting-Host: elea.umd.edu
In article <2qpr6c$dsh@agate.berkeley.edu>,
James C. Hong <jhong@po.EECS.Berkeley.EDU> wrote:
>Hi,
>I just installed NetBSD 0.9 on a machine with a
>NE2000-clone ethernet card, which is using the
>ne0 driver. I noticed that when I Pinged another
>machine, I would get back 2 replys for every
>echo request ping thought it sent out.
Hey - me too. I get somewhere between 1 and 3 copies of each
packet transmitted. Usually it is 3. This makes it pretty painful
to use the machine over long-haul networks.
> Is this a configuration
>problem?
It appears to be a timing problem in neintr().
I instrumented sys/net/if_ethersubr.c and verified that it is only
queueing one packet to be transmitted.
Then (since I have an ne2000 clone in this particular machine), I
instrumented sys/arch/i386/isa/if_ne.c as follows:
Near the top of neintr()...
neintr(unit)
{
register struct ne_softc *ns = &ne_softc[unit];
u_char cmd,isr;
register nec = ns->ns_port;
--> printf("neintr "); /* mark */
/* Save cmd, clear interrupt */
cmd = inb (nec+ds_cmd);
loop:
isr = inb (nec+ds0_isr);
--> printf("- isr %x\n",isr); /* mark */
outb(nec+ds_cmd,DSCM_NODMA|DSCM_START);
near the end of neintr()...
/* Still more to do? */
isr = inb (nec+ds0_isr);
--> if (isr) printf("again\n"); /* mark */
if(isr) goto loop;
}
Oddly enough, now pinging the machine gets me 1 response for each ping
sent instead of 3. It doesn't matter if the printing causes the screen
to scroll or not.
I haven't found anything further than this. I wonder if it is because
a fast 386 with cache can poke at the chip faster than the chip can
get it's status registers updated, but I'm just guessing at this point.
Mark S.