Date: Mon, 4 Dec 1995 20:49:32 +0100 From: se@zpr.uni-koeln.de (Stefan Esser) To: Jerry.Kendall@vmicls.com (Jerry Kendall) Cc: hackers@freebsd.org Subject: Re: PCI probe problems. Message-ID: <199512041949.AA00437@Sysiphos> In-Reply-To: Jerry.Kendall@vmicls.com (Jerry Kendall) "Re: PCI probe problems." (Dec 4, 11:15)
next in thread | raw e-mail | index | archive | help
On Dec 4, 11:15, Jerry Kendall wrote: } Subject: Re: PCI probe problems. } > There are too many systems with non-compliant chipsets (Compaq being } > the worst, IMHO), and the PCI bus probe code contains many special } I have been using FreeBSD 2.0.5R with a Pentium 75 board based on the } Triton Chipset, Will this PCI problem prevent me from upgrading to } 2.1.0R ???? No. The code in both 2.1R and -current runs on just about every hardware. There are a few very exotic chip sets, that violate may ever smaller expectations on compliance to the PCI-2.0 configuration register access rules. Your Triton will work! The problem is, that the PCI specs define a behaviour, that makes it easy to test for the presence of a PCI chip set without risk of damage done to a non-PCI system. But there are so many violations to these part of the specs, that it is in fact not possible to distinguish between PCI and EISA chip sets, which possibly have registers at the same port addresses. The code in 2.1R contains several additional tests to make sure an EISA system doesn't get taken for a PCI system (which would most likely make it crash when the kernel attempts to scan the assumed PCI bus), but since the PCI rules are not always followed by the chip sets, it is possible that a PCI system is not recognized as such without special coding. } BTW: What does IMHO(mentioned above) meaan ???? Compaq has a long tradition of needing special case code in the kernel. When I asked about the lack of compliance to the PCI rules in the PCI-SIG mailing list, some Compaq employee replied, that they in fact didn't bother to implement the hardware according to the spec on which my probe code relied. They didn't consider this a problem, since DOS/Windows use the information supplied by the BIOS, and the BIOS knows all the details about their hardware configuration. This is not a general solution, though. It's not easily possible to detect a Compaq as such (at least not before the PCI bus has been successfully probed), and there are many old PCI BIOS versions, which crash when 32bit accesses are tried. Since this would pose the risk of even MORE hardware not being supported by FreeBSD, I did not yet try to solve the problem by BIOS accesses. These will fail on many old systems, and it is easier to compensate for broken chip sets, than for broken BIOS code ... I have been considering to just scan for a PCI BIOS signature, but to not do any actual PCI BIOS calls. The existance of a PCI BIOS ought to guarantee that there actually IS a PCI bus in that system, and the probe code need not be worried to corrupt some unrelated chip set registers when do the PCI bus scan. But for now, I really want to get a verbose boot message log for all systems that make the PCI bus detection code fail under 2.1R or -current, and I'll put in further special cases to work around the hardware deficiencies ... PCI is a very good idea, but what did you expect to be the result if it gets into contact with PC compatible systems ? :( Regards, STefan -- Stefan Esser, Zentrum fuer Paralleles Rechnen Tel: +49 221 4706021 Universitaet zu Koeln, Weyertal 80, 50931 Koeln FAX: +49 221 4705160 ============================================================================== http://www.zpr.uni-koeln.de/~se <se@ZPR.Uni-Koeln.DE>
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199512041949.AA00437>