From owner-freebsd-current Sat Dec 25 21: 9:38 1999 Delivered-To: freebsd-current@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by hub.freebsd.org (Postfix) with ESMTP id 13BF514D44 for ; Sat, 25 Dec 1999 21:09:36 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id VAA21773; Sat, 25 Dec 1999 21:09:28 -0800 (PST) (envelope-from dillon) Date: Sat, 25 Dec 1999 21:09:28 -0800 (PST) From: Matthew Dillon Message-Id: <199912260509.VAA21773@apollo.backplane.com> To: "Rodney W. Grimes" Cc: wpaul@skynet.ctr.columbia.edu (Bill Paul), julian@whistle.com, scottm@cs.ucla.edu, jlemon@americantv.com, brad@shub-internet.org, jabley@patho.gen.nz, phk@critter.freebsd.dk, wollman@khavrinen.lcs.mit.edu, current@FreeBSD.ORG Subject: Re: Woa! May have found something - 'rl' driver and small packets (was Re: Odd TCP glitches in new currents) References: <199912242038.MAA58725@gndrsh.dnsmgr.net> Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :... :> I'm pretty sure that the box was getiting receive interrupts because :> every time I sent a packet to it from the outside systat -vm showed :> a PCI interrupt for the network device. However 'netstat -in 1' did :> not show the statistics for the received packets until 64 had :> accumulated. It could be that the statistics are not being accumulated :> on a per-reception basis and that the receive packets are actually :> getting through, and that its the transmit side which is broken. I don't :> know the code well enough yet to make the determination. : :If things are done in these drives as they are in the if_de driver then :what you are seeing is the fact that if_opackets and are only :updated when the tx ring is reclaimed by an interrupt, not Next time this bug rears its ugly head I'll get a tcpdump going to try to figure out what is actually going on. Ooh, and I just had a thought -- a profiled kernel might help track down the problem as well by enabling it to see which routines get hit (and which don't). I don't see anything specific in the code so far, other then there being a lot of memory mapped (apparently shared with the device) objects that haven't been volatilized. So far I can't tie that into anything though. -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message