From owner-cvs-all Thu Aug 19 8: 7:29 1999 Delivered-To: cvs-all@freebsd.org Received: from freefall.freebsd.org (freefall.FreeBSD.ORG [204.216.27.21]) by hub.freebsd.org (Postfix) with ESMTP id C68AA150B0; Thu, 19 Aug 1999 08:07:26 -0700 (PDT) (envelope-from peter@FreeBSD.org) Received: (from peter@localhost) by freefall.freebsd.org (8.9.3/8.9.2) id IAA45287; Thu, 19 Aug 1999 08:07:22 -0700 (PDT) (envelope-from peter@FreeBSD.org) Message-Id: <199908191507.IAA45287@freefall.freebsd.org> From: Peter Wemm Date: Thu, 19 Aug 1999 08:07:22 -0700 (PDT) To: cvs-committers@FreeBSD.org, cvs-all@FreeBSD.org Subject: cvs commit: src/sys/pci if_de.c Sender: owner-cvs-all@FreeBSD.ORG Precedence: bulk peter 1999/08/19 08:07:22 PDT Modified files: sys/pci if_de.c Log: Replace the tulip_delay_300ns() with a DELAY(1). Hammering the PCI bus to achieve a delay is pretty mean. Andrew reports: "The tulip_delay_300ns() is, well, bloody stupid on machines with a heavily loaded PCI bus. It tries to do a delay by assuming PCI reads will take a certain amount of time & issues a large amount of (expensive, 5% CPU when your PCI bus is heavily loaded) pci reads. Locally, we've replaced the calls to tulip_delay_300ns(sc) in the EMIT macros with a simple DELAY(1) and not seen any problems. Plus we've gained about 50Mb/sec throughput on our gigabit network cards because of the added PCI bus bandwidth available." Also, I do not understand why, but this change appears to stop the Transmit Fifo underrun on one of my systems (but not the Alpha PC164SX). This shouldn't make that much of a difference since the mii bus isn't touched all that often, but perhaps when it does get accessed and hence hammers the register, it was causing the chip to get upset. Submitted by: Andrew Gallatin Revision Changes Path 1.118 +3 -12 src/sys/pci/if_de.c To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe cvs-all" in the body of the message