From owner-freebsd-current@FreeBSD.ORG Mon Nov 8 00:06:45 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7880D106564A for ; Mon, 8 Nov 2010 00:06:45 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from esa-jnhn.mail.uoguelph.ca (esa-jnhn.mail.uoguelph.ca [131.104.91.44]) by mx1.freebsd.org (Postfix) with ESMTP id 2D9A08FC14 for ; Mon, 8 Nov 2010 00:06:44 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvQEAC/O1kyDaFvO/2dsb2JhbACDMJBWjnCpBJAtgSKDM3MEhFiFfQ X-IronPort-AV: E=Sophos;i="4.58,311,1286164800"; d="scan'208";a="99922751" Received: from erie.cs.uoguelph.ca (HELO zcs3.mail.uoguelph.ca) ([131.104.91.206]) by esa-jnhn-pri.mail.uoguelph.ca with ESMTP; 07 Nov 2010 19:06:43 -0500 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id 06D85B3EB4; Sun, 7 Nov 2010 19:06:44 -0500 (EST) Date: Sun, 7 Nov 2010 19:06:44 -0500 (EST) From: Rick Macklem To: pyunyh@gmail.com Message-ID: <2066420582.220038.1289174803955.JavaMail.root@erie.cs.uoguelph.ca> In-Reply-To: <20101106023345.GC22715@michelle.cdnetworks.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [99.225.56.115] X-Mailer: Zimbra 6.0.7_GA_2476.RHEL4 (ZimbraWebClient - IE8 (Win)/6.0.7_GA_2473.RHEL4_64) Cc: alc@freebsd.org, freebsd-current@freebsd.org Subject: Re: re(4) driver dropping packets when reading NFS files X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Nov 2010 00:06:45 -0000 > > I highly doubt it could be hardware issue. > Looks like the hardware guys may be off the hook. See below. > > It's job of bus_dma(9) and I don't think barrier instructions would > be helpful here as I don't see out-of-order execution in RX > handler. > My current hunch is that something that changed between June 7 and June 15 in head/sys has caused the chip to have difficulties doing DMA, resulting in the Fifo overflows and approx. 10% "missed frames". > > Let's kill driver bug. No one reported this kind of issue so far > and I guess most users took it granted for the poor performance > because they are using low end consumer grade controller. > I think your driver is off the hook, too. > > > re0 statistics: > > Transmit good frames : 101346 > > Receive good frames : 133390 > > Tx errors : 0 > > Rx errors : 0 > > Rx missed frames : 14394 > > Rx frame alignment errs : 0 > > Tx single collisions : 0 > > Tx multiple collisions : 0 > > Rx unicast frames : 133378 > > Rx broadcast frames : 0 > > Rx multicast frames : 12 > > Tx aborts : 0 > > Tx underruns : 0 > > rxe did 0: 14359 > Seeing that someone thought it had worked ok a while back, I decided to try some old kernels I had lying about from head/-current. I found that the one I svn`d on June 7 works well (about 7Mbytes per sec read rate) whereas one svn`d on June 15 had the problem (about 500Kbytes per sec read rate). So what is different between these kernels: - if_re.c is identical - subr_dma.c has a simple change and porting the June 7 one over didn`t make the June 15 one work better - amd64`s busdma_machdep.c is identical so it must be something else. There are a bunch of changes to amd64`s pmap.c, which is why I`ve cc`d Alan, in case he might know if those changes could affect PCIe DMA or similar. Other than that, maybe someone else familiar with the PCIe DMA could look and see if a change done to head between June 7 and 15 might explain it. (and it could be something else, a DMA problem for the chip is just a guess) rick ps: Unfortunately I`ll be on the road for the next month, so I won`t be able to test patches until early Dec.