From owner-cvs-src@FreeBSD.ORG Mon Feb 4 23:00:36 2008 Return-Path: Delivered-To: cvs-src@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DEE5816A41A; Mon, 4 Feb 2008 23:00:36 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from speedfactory.net (mail.speedfactory.net [66.23.216.219]) by mx1.freebsd.org (Postfix) with ESMTP id 395AD13C465; Mon, 4 Feb 2008 23:00:35 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (unverified [66.23.211.162]) by speedfactory.net (SurgeMail 3.8s) with ESMTP id 230849977-1834499 for multiple; Mon, 04 Feb 2008 18:00:21 -0500 Received: from localhost.corp.yahoo.com (john@localhost [127.0.0.1]) (authenticated bits=0) by server.baldwin.cx (8.14.2/8.14.2) with ESMTP id m14N0Ft5072274; Mon, 4 Feb 2008 18:00:16 -0500 (EST) (envelope-from jhb@freebsd.org) From: John Baldwin To: Scott Long Date: Mon, 4 Feb 2008 14:30:11 -0500 User-Agent: KMail/1.9.7 References: <200802012031.m11KV9NZ095246@repoman.freebsd.org> <200802040947.59712.jhb@freebsd.org> <47A73071.5080101@samsco.org> In-Reply-To: <47A73071.5080101@samsco.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200802041430.11691.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (server.baldwin.cx [127.0.0.1]); Mon, 04 Feb 2008 18:00:16 -0500 (EST) X-Virus-Scanned: ClamAV 0.91.2/5686/Mon Feb 4 16:13:58 2008 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-4.1 required=4.2 tests=ALL_TRUSTED,AWL,BAYES_00, DATE_IN_PAST_03_06 autolearn=ham version=3.1.3 X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on server.baldwin.cx Cc: cvs-src@freebsd.org, src-committers@freebsd.org, cvs-all@freebsd.org Subject: Re: cvs commit: src/sys/dev/pci pci.c X-BeenThere: cvs-src@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: CVS commit messages for the src tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Feb 2008 23:00:37 -0000 On Monday 04 February 2008 10:34:09 am Scott Long wrote: > John Baldwin wrote: > > On Friday 01 February 2008 09:18:38 pm Scott Long wrote: > >> John Baldwin wrote: > >>> jhb 2008-02-01 20:31:09 UTC > >>> > >>> FreeBSD src repository > >>> > >>> Modified files: > >>> sys/dev/pci pci.c > >>> Log: > >>> Relax the check for a PCI-express chipset by assuming the system is a > >>> PCI-express chipset (and thus has functional MSI) if there are any > >>> PCI-express devices in the system, not requiring a root port device. > >>> > >>> With PCI-X the chipset detection has to be very conservative because there > >>> are known systems with PCI-X devices that do not appear to have PCI-X > >>> chipsets. However, with PCI-express I'm not sure it is possible to have > >>> a PCI-express device in a system with a non-PCI-express chipset. If we > >>> assume that is the case then this change is valid. It is also required > >>> for at least some PCI-express systems that don't have any devices with > >>> a root port capability (some ICH9 systems). > >>> > >>> MFC after: 1 week > >>> Reported by: jfv > >>> > >>> Revision Changes Path > >>> 1.357 +2 -5 src/sys/dev/pci/pci.c > >> It's certainly possible for a PCI-X device to be plugged into a PCI-only > >> system; PCI-X is backwards compatible at an electrical an protocol level > >> with 3.3V PCI. So yes, you will see PCI-X extcaps on PCI-X cards even > >> if there is no PCI-X bridge. > >> > >> I'm sure there are fun, interesting, and highly obtuse ways to get a > >> PCI-E device onto a system with no PCI-E root complex. I do agree with > >> your implicit statement to not worry about such an edge case, at least > >> not until such an edge case becomes a demonstrated reality. What does > >> worry me is that Intel would release PCI-E chipsets without an > >> advertised root complex. That would seem to blatantly violate the spec. > >> Does Jack have confirmation that this is really the case? If so, what > >> else is being played fast-and-loose with that we should know about? > > > > It's not that it isn't advertising a root complex but isn't advertising a > > root _port_ unless there is a PCI-e expansion card plugged in. I guess > > internal PCI-e devices aren't connected via a port? It does seem > > inconsistent as my laptop with no external PCI-e slots has root ports > > capabilities on PCI-PCI bridges off of bus 0 that service internal devices. > > > > Ok, funky. So there are onboard PCIe devices, but it only advertises a > port if there are external devices. I'm not clear on the technical > distinction there either. Correct, I find it quite odd myself and had assumed that you would always have root ports. I was quite surprised to learn otherwise. :-/ -- John Baldwin