Return to BSD News archive
Path: sserve!newshost.anu.edu.au!harbinger.cc.monash.edu.au!msuinfo!agate!library.ucla.edu!csulb.edu!nic-nac.CSU.net!charnel.ecst.csuchico.edu!xmission!u.cc.utah.edu!cs.weber.edu!terry From: terry@cs.weber.edu (Terry Lambert) Newsgroups: comp.os.386bsd.development Subject: Re: FreeBSD 1.1.5 on PCI (was: NetBSD-1.0 - WHEN?) Date: 24 Sep 1994 08:23:31 GMT Organization: Weber State University, Ogden, UT Lines: 65 Message-ID: <360nm3$l92@u.cc.utah.edu> References: <VIXIE.94Sep22005733@gw.home.vix.com> <35t468INN16tr@rs1.rrz.Uni-Koeln.DE> <CwM0D1.F9L@rex.uokhsc.edu> NNTP-Posting-Host: cs.weber.edu In article <CwM0D1.F9L@rex.uokhsc.edu> benjamin-goldsteen@uokhsc.edu writes: ] se@fileserv1.MI.Uni-Koeln.DE (Stefan Esser) writes: ] >In article <VIXIE.94Sep22005733@gw.home.vix.com>, vixie@gw.home.vix.com (Paul A Vixie) writes: ] >|> PCI is not ready for prime time. It does video OK but that's all. ] >|> Show me a motherboard and disk controller that work together, and ] >|> I'll show you ten that don't. If you aren't convinced I'll show ] >|> you ten more that don't. If you still aren't convinced, next week ] >|> there will be ten new ones that don't. ] ] >Well, I guess there is nothing wrong with PCI, but PCI ] >in an ISA PC is calling for trouble ... ] ] >In my experience, there was no problem at all, if it was ] >not for the interrupt mapping (PIC IntA -> ISA IRQ #). ] ] What about a PCI/EISA system? I have recently become more confident in my knowledge of PCI (and my sources, like Rod) after receiving and reading the PCI specifications up to and includign 2.1 (revised 26 Aug 94). IMO, the biggest thing that keeps PCI "not ready for prime time" is the inclusion of ISA, EISA, and VLB busses in the same machine. PCI "plug-n-play" depneds on having full registration information for all the devices on the bus, and these other bus architectures (yes, even EISA) don't provide the necessary information for it to "do its thing". There was some known problems with PCI 1.x conformant boards. Mainly, there was a potential address range overlap for devices with multiple addresses defined (and the conflict was mosly with EISA or ISA disk controllers plugged into the same machine). There was also a problem with the Intel bus interface chip design such that bus mastering DMA from a PCI controller would not result in cache update of the new information. Intel Saturn, Neptune, and Mercury chipsets manufacured afte 10 Feb 94 should not have this defect. Recent manufacture board, especially those from Intel, and notably the Intel Plato with AMI PCI rev 2,0C (or better) BIOS, seem to function correctly, Gateway, Dell, and several other companies are OEM'ing this board. The current problems are: 1) The manufacturer has worked around the Intel bus interface chipset bugs in hardware, only you don't have a buggy chip installed since the chip is new but the board design was not unhacked. 2) You get a third party chipset which may have it's own problems (I don't know about them yet, so I can't tell you). Both of these are generally the result of buying from dealer/warehouse inventory. If you explicitly specify revisions, you shouldn't have a problem. Terry Lambert terry@cs.weber.edu --- Any opinions in this posting are my own and not those of my present or previous employers.