From owner-cvs-all@FreeBSD.ORG Tue Aug 1 17:18:26 2006 Return-Path: X-Original-To: cvs-all@FreeBSD.org Delivered-To: cvs-all@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8A01B16A4DA; Tue, 1 Aug 2006 17:18:26 +0000 (UTC) (envelope-from wpaul@FreeBSD.org) Received: from repoman.freebsd.org (repoman.freebsd.org [216.136.204.115]) by mx1.FreeBSD.org (Postfix) with ESMTP id C2BD643D78; Tue, 1 Aug 2006 17:18:25 +0000 (GMT) (envelope-from wpaul@FreeBSD.org) Received: from repoman.freebsd.org (localhost [127.0.0.1]) by repoman.freebsd.org (8.13.6/8.13.6) with ESMTP id k71HIP96018879; Tue, 1 Aug 2006 17:18:25 GMT (envelope-from wpaul@repoman.freebsd.org) Received: (from wpaul@localhost) by repoman.freebsd.org (8.13.6/8.13.4/Submit) id k71HIP4M018878; Tue, 1 Aug 2006 17:18:25 GMT (envelope-from wpaul) Message-Id: <200608011718.k71HIP4M018878@repoman.freebsd.org> From: Bill Paul Date: Tue, 1 Aug 2006 17:18:25 +0000 (UTC) To: src-committers@FreeBSD.org, cvs-src@FreeBSD.org, cvs-all@FreeBSD.org X-FreeBSD-CVS-Branch: HEAD Cc: Subject: cvs commit: src/sys/dev/re if_re.c src/sys/pci if_rlreg.h X-BeenThere: cvs-all@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: CVS commit messages for the entire tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Aug 2006 17:18:26 -0000 wpaul 2006-08-01 17:18:25 UTC FreeBSD src repository Modified files: sys/dev/re if_re.c sys/pci if_rlreg.h Log: Another small update to the re(4) driver: - Change the workaround for the autopad/checksum offload bug so that instead of lying about the map size, we actually create a properly padded mbuf and map it as usual. The other trick works, but is ugly. This approach also gives us a chance to zero the pad space to avoid possibly leaking data. - With the PCIe devices, it looks issuing a TX command while there's already a transmission in progress doesn't have any effect. In other words, if you send two packets in rapid succession, the second one may end up sitting in the TX DMA ring until another transmit command is issued later in the future. Basically, if re_txeof() sees that there are still descriptors outstanding, it needs to manually resume the TX DMA channel by issuing another TX command to make sure all transmissions are flushed out. (The PCI devices seem to keep the TX channel moving until all descriptors have been consumed. I'm not sure why the PCIe devices behave differently.) (You can see this issue if you do the following test: plug an re(4) interface into another host via crossover cable, and from the other host do 'ping -c 2 ' to prime the ARP cache, then do 'ping -c 1 -s 1473 '. You're supposed to see two packets sent in response, but you may only see one. If you do 'ping -c 1 -s 1473 ' again, you'll see two packets, but one will be the missing fragment from the last ping, followed by one of the fragments from this ping.) - Add the PCI ID for the US Robotics 997902 NIC, which is based on the RTL8169S. - Add a tsleep() of 1 second in re_detach() after the interrupt handler is disconnected. This should allow any tasks queued up by the ISR to drain. Now, I know you're supposed to use taskqueue_drain() for this, but something about the way taskqueue_drain() works with taskqueue_fast queues doesn't seem quite right, and I refuse to be tricked into fixing it. Revision Changes Path 1.71 +52 -23 src/sys/dev/re/if_re.c 1.60 +8 -0 src/sys/pci/if_rlreg.h