Date: Thu, 19 Aug 1999 08:07:22 -0700 (PDT) From: Peter Wemm <peter@FreeBSD.org> To: cvs-committers@FreeBSD.org, cvs-all@FreeBSD.org Subject: cvs commit: src/sys/pci if_de.c Message-ID: <199908191507.IAA45287@freefall.freebsd.org>
next in thread | raw e-mail | index | archive | help
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 <gallatin@cs.duke.edu>
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199908191507.IAA45287>