From nobody@FreeBSD.org  Thu Aug 14 05:37:36 2008
Return-Path: <nobody@FreeBSD.org>
Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34])
	by hub.freebsd.org (Postfix) with ESMTP id 333D0106566B
	for <freebsd-gnats-submit@FreeBSD.org>; Thu, 14 Aug 2008 05:37:36 +0000 (UTC)
	(envelope-from nobody@FreeBSD.org)
Received: from www.freebsd.org (www.freebsd.org [IPv6:2001:4f8:fff6::21])
	by mx1.freebsd.org (Postfix) with ESMTP id 1F74F8FC16
	for <freebsd-gnats-submit@FreeBSD.org>; Thu, 14 Aug 2008 05:37:36 +0000 (UTC)
	(envelope-from nobody@FreeBSD.org)
Received: from www.freebsd.org (localhost [127.0.0.1])
	by www.freebsd.org (8.14.2/8.14.2) with ESMTP id m7E5bZPT081793
	for <freebsd-gnats-submit@FreeBSD.org>; Thu, 14 Aug 2008 05:37:35 GMT
	(envelope-from nobody@www.freebsd.org)
Received: (from nobody@localhost)
	by www.freebsd.org (8.14.2/8.14.1/Submit) id m7E5bZt3081791;
	Thu, 14 Aug 2008 05:37:35 GMT
	(envelope-from nobody)
Message-Id: <200808140537.m7E5bZt3081791@www.freebsd.org>
Date: Thu, 14 Aug 2008 05:37:35 GMT
From: Arthur Hartwig <arthur.hartwig@nokia.com>
To: freebsd-gnats-submit@FreeBSD.org
Subject: Extended PCI Configuration register (>= 0x100) not enabled on some Intel 915 based platforms
X-Send-Pr-Version: www-3.1
X-GNATS-Notify:

>Number:         126525
>Category:       kern
>Synopsis:       [pci] [patch] Extended PCI Configuration register (>= 0x100) not enabled on some Intel 915 based platforms
>Confidential:   no
>Severity:       non-critical
>Priority:       medium
>Responsible:    jhb
>State:          closed
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Thu Aug 14 05:40:01 UTC 2008
>Closed-Date:    Wed May 06 15:11:02 UTC 2009
>Last-Modified:  Wed May 06 15:11:02 UTC 2009
>Originator:     Arthur Hartwig
>Release:        7.0
>Organization:
Nokia
>Environment:
>Description:
Access to extended PCI Configuration registers (0x100 and above on PCI
Express devices) is not enabled on some platforms based on the Intel 915
chipset nor on platforms based on the Intel 5000 chipsets.



>How-To-Repeat:

>Fix:
In sys/i386/pci/pci_cfgreg.c change pci_cfgregopen to read:

/* 
 * Initialise access to PCI configuration space 
 */
int
pci_cfgregopen(void)
{
	static int		opened = 0;
	u_int16_t		vid, did;
	u_int16_t		v;

	if (opened)
		return(1);

	if (pcireg_cfgopen() == 0)
		return(0);

	v = pcibios_get_version();
	if (v > 0)
		PRVERB(("pcibios: BIOS version %x.%02x\n", (v & 0xff00) >> 8,
		    v & 0xff));
	mtx_init(&pcicfg_mtx, "pcicfg", NULL, MTX_SPIN);
	opened = 1;

	/* $PIR requires PCI BIOS 2.10 or greater. */
	if (v >= 0x0210)
		pci_pir_open();

	/*
	 * Grope around in the PCI config space to see if this is a
	 * chipset that is capable of doing memory-mapped config cycles.
	 * This also implies that it can do PCIe extended config cycles.
	 */

	vid = pci_cfgregread(0, 0, 0, PCIR_VENDOR, 2);
	did = pci_cfgregread(0, 0, 0, PCIR_DEVICE, 2);
	if (vid == 0x8086) {
		switch (did) {
		case 0x3590:
		case 0x3592:
			/* Intel 7520 or 7320 */
			pciebar = pci_cfgregread(0, 0, 0, 0xce, 2) << 16;
			pciereg_cfgopen();
			break;

		case 0x2580:
		case 0x2584:
		case 0x2590:
			/* Intel 915, 925, 915GM/PM/GMS/GME or 910GML/GMLE */
			pciebar = pci_cfgregread(0, 0, 0, 0x48, 4);
			pciereg_cfgopen();
			break;
		
		case 0x25d8:
		case 0x25d0: 
		case 0x25d4:
			/* Intel 5000P/Z/V */
			pciebar = pci_cfgregread(0, 16, 0, 0x64, 4);
#ifndef PAE
			if (pciebar >= 0x10000) {
				printf("%s: Memory mapped PCI configuration "
				       "area base 0x%08x too high\n", 
				       __FUNCTION__, pciebar
);
				pciebar = 0;
				break;
			}
#endif
			pciebar = pciebar << 16;
			pciereg_cfgopen();
			break;
		}
	}

	return(1);
}




>Release-Note:
>Audit-Trail:

From: Arthur Hartwig <Arthur.Hartwig@nokia.com>
To: bug-followup@FreeBSD.org, arthur.hartwig@nokia.com
Cc:  
Subject: Re: i386/126525: Extended PCI Configuration register (&gt;= 0x100)
 not enabled on some Intel 915 based platforms
Date: Thu, 14 Aug 2008 16:43:08 +1000

 The same change should probably be made to sys/amd64/pci/pci_cfgreg.c
 
 

From: Gavin Atkinson <gavin@FreeBSD.org>
To: bug-followup@FreeBSD.org
Cc:  
Subject: Re: i386/126525: Extended PCI Configuration register (>= 0x100) not
 enabled
Date: Fri, 15 Aug 2008 14:03:49 +0100 (BST)

 Patch follows.
 
 Index: src/sys/i386/pci/pci_cfgreg.c
 ===================================================================
 RCS file: /home/ncvs/src/sys/i386/pci/pci_cfgreg.c,v
 retrieving revision 1.126
 diff -u -r1.126 pci_cfgreg.c
 --- src/sys/i386/pci/pci_cfgreg.c	28 Nov 2007 22:22:05 -0000	1.126
 +++ src/sys/i386/pci/pci_cfgreg.c	15 Aug 2008 11:38:42 -0000
 @@ -163,14 +163,37 @@
   	vid = pci_cfgregread(0, 0, 0, PCIR_VENDOR, 2);
   	did = pci_cfgregread(0, 0, 0, PCIR_DEVICE, 2);
   	if (vid == 0x8086) {
 -		if (did == 0x3590 || did == 0x3592) {
 +		switch (did) {
 +		case 0x3590:
 +		case 0x3592:
   			/* Intel 7520 or 7320 */
   			pciebar = pci_cfgregread(0, 0, 0, 0xce, 2) << 16;
   			pciereg_cfgopen();
 -		} else if (did == 0x2580 || did == 0x2584) {
 -			/* Intel 915 or 925 */
 +			break;
 +		case 0x2580:
 +		case 0x2584:
 +		case 0x2590:
 +			/* Intel 915, 925, 915GM/PM/GMS/GME or 910GML/GMLE */
   			pciebar = pci_cfgregread(0, 0, 0, 0x48, 4);
   			pciereg_cfgopen();
 +			break;
 +		case 0x25d8:
 +		case 0x25d0:
 +		case 0x25d4:
 +			/* Intel 5000P/Z/V */
 +			pciebar = pci_cfgregread(0, 16, 0, 0x64, 4);
 +#ifndef PAE
 +			if (pciebar >= 0x10000) {
 +				printf("%s: Memory mapped PCI configuration "
 +				    "area base 0x%08x too high\n",
 +				    __FUNCTION__, pciebar);
 +				pciebar = 0;
 +				break;
 +			}
 +#endif
 +			pciebar = pciebar << 16;
 +			pciereg_cfgopen();
 +			break;
   		}
   	}
 
Responsible-Changed-From-To: freebsd-i386->jhb 
Responsible-Changed-By: linimon 
Responsible-Changed-When: Mon Aug 18 01:03:01 UTC 2008 
Responsible-Changed-Why:  
John, it looks like you are the best person to evaluate this. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=126525 

From: dfilter@FreeBSD.ORG (dfilter service)
To: bug-followup@FreeBSD.org
Cc:  
Subject: Re: kern/126525: commit references a PR
Date: Wed, 20 Aug 2008 18:18:34 +0000 (UTC)

 jhb         2008-08-20 18:18:17 UTC
 
   FreeBSD src repository
 
   Modified files:
     sys/i386/pci         pci_cfgreg.c 
   Log:
   SVN rev 181933 on 2008-08-20 18:18:17Z by jhb
   
   - Add support for memory mapped PCI config space access on Intel 915GM
     and 5000P/V/Z chipsets.
   - If the base address of the config space BAR is above 4GB for some reason
     and this isn't a PAE kernel, then warn about this (under bootverbose)
     and don't use the BAR.
   
   PR:             kern/126525
   Submitted by:   Arthur Hartwig @ Nokia
   MFC after:      2 weeks
   
   Revision  Changes    Path
   1.129     +23 -3     src/sys/i386/pci/pci_cfgreg.c
 _______________________________________________
 cvs-all@freebsd.org mailing list
 http://lists.freebsd.org/mailman/listinfo/cvs-all
 To unsubscribe, send any mail to "cvs-all-unsubscribe@freebsd.org"
 
State-Changed-From-To: open->patched 
State-Changed-By: jhb 
State-Changed-When: Wed Aug 20 18:33:39 UTC 2008 
State-Changed-Why:  
A variant of this was committed to HEAD. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=126525 

From: John Baldwin <jhb@FreeBSD.org>
To: bug-followup@FreeBSD.org, arthur.hartwig@nokia.com
Cc:  
Subject: Re: kern/126525: [pci] [patch] Extended PCI Configuration register (&gt;= 0x100) not enabled on some Intel 915 based platforms
Date: Wed, 20 Aug 2008 14:19:37 -0400

 I've committed a variant of this.  I moved the PAE check into 
 pciereg_cfgopen() as it is may be relevant for other chipsets as well.  PCIe 
 is not currently supported on amd64, but it should be trivial since the 
 direct map can be used there.  I may attempt to do that next.
 
 -- 
 John Baldwin

From: Arthur Hartwig <Arthur.Hartwig@nokia.com>
To: ext John Baldwin <jhb@FreeBSD.org>
Cc: bug-followup@FreeBSD.org
Subject: Re: kern/126525: [pci] [patch] Extended PCI Configuration register
 (&gt;= 0x100) not enabled on some Intel 915 based platforms
Date: Thu, 21 Aug 2008 11:26:06 +1000

 ext John Baldwin wrote:
 > I've committed a variant of this.  I moved the PAE check into 
 > pciereg_cfgopen() as it is may be relevant for other chipsets as well.  PCIe 
 > is not currently supported on amd64, but it should be trivial since the 
 > direct map can be used there.  I may attempt to do that next.
 By "PCIe is not currently supported on amd64" did you mean "Access to 
 PCI extended configuration registers is not supported on amd64"? (PCI 
 Express device and chipsets are claimed supported.)
 
 We access the extended PCI configuration registers in the 5000 series 
 chipsets to get error counts. We currently run the CPUs in 32 bit mode 
 but use of 64 bit mode is under some discussion.
 
 Arthur

From: John Baldwin <jhb@freebsd.org>
To: Arthur Hartwig <Arthur.Hartwig@nokia.com>
Cc: bug-followup@freebsd.org
Subject: Re: kern/126525: [pci] [patch] Extended PCI Configuration register (&gt;= 0x100) not enabled on some Intel 915 based platforms
Date: Thu, 21 Aug 2008 15:13:29 -0400

 On Wednesday 20 August 2008 09:26:06 pm Arthur Hartwig wrote:
 > ext John Baldwin wrote:
 > > I've committed a variant of this.  I moved the PAE check into 
 > > pciereg_cfgopen() as it is may be relevant for other chipsets as well.  
 PCIe 
 > > is not currently supported on amd64, but it should be trivial since the 
 > > direct map can be used there.  I may attempt to do that next.
 > By "PCIe is not currently supported on amd64" did you mean "Access to 
 > PCI extended configuration registers is not supported on amd64"? (PCI 
 > Express device and chipsets are claimed supported.)
 > 
 > We access the extended PCI configuration registers in the 5000 series 
 > chipsets to get error counts. We currently run the CPUs in 32 bit mode 
 > but use of 64 bit mode is under some discussion.
 
 Correct.  However, I fixed this last night (and also fixed the kernel to use 
 the ACPI MCFG table so we don't need more chipset-specific hacks in the 
 future).  I need to test it on i386 and then I will commit it today.  I 
 should be able to merge it back to 6.x and 7.x.  BTW, can you check to see if 
 any of the chipsets you added support for in your patch have an MCFG table in 
 their 'acpidump -t' output?  If so, I'll probably remove them from the manual 
 hack list.
 
 -- 
 John Baldwin

From: Arthur Hartwig <Arthur.Hartwig@nokia.com>
To: ext John Baldwin <jhb@freebsd.org>
Cc: bug-followup@freebsd.org
Subject: Re: kern/126525: [pci] [patch] Extended PCI Configuration register
 (&gt;= 0x100) not enabled on some Intel 915 based platforms
Date: Fri, 22 Aug 2008 09:39:07 +1000

 This is a multi-part message in MIME format.
 --------------040905070607040902030900
 Content-Type: text/plain; charset=ISO-8859-1; format=flowed
 Content-Transfer-Encoding: 7bit
 
 ext John Baldwin wrote:
 > On Wednesday 20 August 2008 09:26:06 pm Arthur Hartwig wrote:
 >   
 >> ext John Baldwin wrote:
 >>     
 >>> I've committed a variant of this.  I moved the PAE check into 
 >>> pciereg_cfgopen() as it is may be relevant for other chipsets as well.  
 >>>       
 > PCIe 
 >   
 >>> is not currently supported on amd64, but it should be trivial since the 
 >>> direct map can be used there.  I may attempt to do that next.
 >>>       
 >> By "PCIe is not currently supported on amd64" did you mean "Access to 
 >> PCI extended configuration registers is not supported on amd64"? (PCI 
 >> Express device and chipsets are claimed supported.)
 >>
 >> We access the extended PCI configuration registers in the 5000 series 
 >> chipsets to get error counts. We currently run the CPUs in 32 bit mode 
 >> but use of 64 bit mode is under some discussion.
 >>     
 >
 > Correct.  However, I fixed this last night (and also fixed the kernel to use 
 > the ACPI MCFG table so we don't need more chipset-specific hacks in the 
 > future).  I need to test it on i386 and then I will commit it today.  I 
 > should be able to merge it back to 6.x and 7.x.  BTW, can you check to see if 
 > any of the chipsets you added support for in your patch have an MCFG table in 
 > their 'acpidump -t' output?  If so, I'll probably remove them from the manual 
 > hack list.
 >   
 G'day John,
     Thanks for your prompt reply. Most of our systems are embedded 
 systems. In at least one case the BIOS did not include ACPI support 
 because it wouldn't fit.
     Our 915 based system uses MPTABLES, not ACPI.
     Three out of four of our 7520 based systems don't have ACPI data.
     The 5000 based system does have ACPI data - here's its MCFG entry:
 /*
   MCFG: Length=60, Revision=1, Checksum=17,
         OEMID=INTEL, OEM Table ID=TIANO, OEM Revision=0x1,
         Creator ID=MSFT, Creator Revision=0x1000013
 
         Base Address= 0x00000000d0000000
         Segment Group= 0x0000
         Start Bus= 0
         End Bus= 255
  */
      The base address in this MCFG segment matches what is in pciebar in 
 the running system.
 
 I hope all our future systems will include ACPI. However for the 
 embedded systems users it may be worth leaving at least a couple of 
 chipsets there as examples for those who might have to "roll their own" 
 due to lack of ACPI.
 
 Arthur
 
 
 
 
 
 --------------040905070607040902030900
 Content-Type: text/html; charset=ISO-8859-1
 Content-Transfer-Encoding: 7bit
 
 <!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
 <html>
 <head>
   <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
 </head>
 <body bgcolor="#ffffff" text="#000000">
 ext John Baldwin wrote:
 <blockquote cite="mid200808211513.29200.jhb@freebsd.org" type="cite">
   <pre wrap="">On Wednesday 20 August 2008 09:26:06 pm Arthur Hartwig wrote:
   </pre>
   <blockquote type="cite">
     <pre wrap="">ext John Baldwin wrote:
     </pre>
     <blockquote type="cite">
       <pre wrap="">I've committed a variant of this.  I moved the PAE check into 
 pciereg_cfgopen() as it is may be relevant for other chipsets as well.  
       </pre>
     </blockquote>
   </blockquote>
   <pre wrap=""><!---->PCIe 
   </pre>
   <blockquote type="cite">
     <blockquote type="cite">
       <pre wrap="">is not currently supported on amd64, but it should be trivial since the 
 direct map can be used there.  I may attempt to do that next.
       </pre>
     </blockquote>
     <pre wrap="">By "PCIe is not currently supported on amd64" did you mean "Access to 
 PCI extended configuration registers is not supported on amd64"? (PCI 
 Express device and chipsets are claimed supported.)
 
 We access the extended PCI configuration registers in the 5000 series 
 chipsets to get error counts. We currently run the CPUs in 32 bit mode 
 but use of 64 bit mode is under some discussion.
     </pre>
   </blockquote>
   <pre wrap=""><!---->
 Correct.  However, I fixed this last night (and also fixed the kernel to use 
 the ACPI MCFG table so we don't need more chipset-specific hacks in the 
 future).  I need to test it on i386 and then I will commit it today.  I 
 should be able to merge it back to 6.x and 7.x.  BTW, can you check to see if 
 any of the chipsets you added support for in your patch have an MCFG table in 
 their 'acpidump -t' output?  If so, I'll probably remove them from the manual 
 hack list.
   </pre>
 </blockquote>
 G'day John,<br>
 &nbsp;&nbsp;&nbsp; Thanks for your prompt reply. Most of our systems are embedded
 systems. In at least one case the BIOS did not include ACPI support
 because it wouldn't fit.<br>
 &nbsp;&nbsp;&nbsp; Our 915 based system uses MPTABLES, not ACPI.<br>
 &nbsp;&nbsp;&nbsp; Three out of four of our 7520 based systems don't have ACPI data.<br>
 &nbsp;&nbsp;&nbsp; The 5000 based system does have ACPI data - here's its MCFG entry:<br>
 /*<br>
 &nbsp; MCFG: Length=60, Revision=1, Checksum=17,<br>
 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; OEMID=INTEL, OEM Table ID=TIANO, OEM Revision=0x1,<br>
 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Creator ID=MSFT, Creator Revision=0x1000013<br>
 <br>
 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Base Address= 0x00000000d0000000<br>
 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Segment Group= 0x0000<br>
 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Start Bus= 0<br>
 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; End Bus= 255<br>
 &nbsp;*/<br>
 &nbsp;&nbsp;&nbsp;&nbsp; The base address in this MCFG segment matches what is in pciebar
 in the running system.<br>
 <br>
 I hope all our future systems will include ACPI. However for the
 embedded systems users it may be worth leaving at least a couple of
 chipsets there as examples for those who might have to "roll their own"
 due to lack of ACPI.<br>
 <br>
 Arthur<br>
 <br>
 <br>
 <br>
 <br>
 </body>
 </html>
 
 --------------040905070607040902030900--

From: John Baldwin <jhb@freebsd.org>
To: Arthur Hartwig <Arthur.Hartwig@nokia.com>
Cc: bug-followup@freebsd.org
Subject: Re: kern/126525: [pci] [patch] Extended PCI Configuration register (&gt;= 0x100) not enabled on some Intel 915 based platforms
Date: Thu, 21 Aug 2008 20:39:13 -0400

 On Thursday 21 August 2008 07:39:07 pm Arthur Hartwig wrote:
 > ext John Baldwin wrote:
 > > On Wednesday 20 August 2008 09:26:06 pm Arthur Hartwig wrote:
 > >   
 > >> ext John Baldwin wrote:
 > >>     
 > >>> I've committed a variant of this.  I moved the PAE check into 
 > >>> pciereg_cfgopen() as it is may be relevant for other chipsets as well.  
 > >>>       
 > > PCIe 
 > >   
 > >>> is not currently supported on amd64, but it should be trivial since the 
 > >>> direct map can be used there.  I may attempt to do that next.
 > >>>       
 > >> By "PCIe is not currently supported on amd64" did you mean "Access to 
 > >> PCI extended configuration registers is not supported on amd64"? (PCI 
 > >> Express device and chipsets are claimed supported.)
 > >>
 > >> We access the extended PCI configuration registers in the 5000 series 
 > >> chipsets to get error counts. We currently run the CPUs in 32 bit mode 
 > >> but use of 64 bit mode is under some discussion.
 > >>     
 > >
 > > Correct.  However, I fixed this last night (and also fixed the kernel to 
 use 
 > > the ACPI MCFG table so we don't need more chipset-specific hacks in the 
 > > future).  I need to test it on i386 and then I will commit it today.  I 
 > > should be able to merge it back to 6.x and 7.x.  BTW, can you check to see 
 if 
 > > any of the chipsets you added support for in your patch have an MCFG table 
 in 
 > > their 'acpidump -t' output?  If so, I'll probably remove them from the 
 manual 
 > > hack list.
 > >   
 > G'day John,
 >     Thanks for your prompt reply. Most of our systems are embedded 
 > systems. In at least one case the BIOS did not include ACPI support 
 > because it wouldn't fit.
 >     Our 915 based system uses MPTABLES, not ACPI.
 >     Three out of four of our 7520 based systems don't have ACPI data.
 >     The 5000 based system does have ACPI data - here's its MCFG entry:
 > /*
 >   MCFG: Length=60, Revision=1, Checksum=17,
 >         OEMID=INTEL, OEM Table ID=TIANO, OEM Revision=0x1,
 >         Creator ID=MSFT, Creator Revision=0x1000013
 > 
 >         Base Address= 0x00000000d0000000
 >         Segment Group= 0x0000
 >         Start Bus= 0
 >         End Bus= 255
 >  */
 >      The base address in this MCFG segment matches what is in pciebar in 
 > the running system.
 > 
 > I hope all our future systems will include ACPI. However for the 
 > embedded systems users it may be worth leaving at least a couple of 
 > chipsets there as examples for those who might have to "roll their own" 
 > due to lack of ACPI.
 
 I think what I shall probably do is just remove the 5000P/V/Z section then but 
 leave the others, how does that sound?
 
 -- 
 John Baldwin

From: Arthur Hartwig <Arthur.Hartwig@nokia.com>
To: ext John Baldwin <jhb@freebsd.org>
Cc: bug-followup@freebsd.org
Subject: Re: kern/126525: [pci] [patch] Extended PCI Configuration register
 (&gt;= 0x100) not enabled on some Intel 915 based platforms
Date: Fri, 22 Aug 2008 11:35:01 +1000

 This is a multi-part message in MIME format.
 --------------050909050106010404080603
 Content-Type: text/plain; charset=ISO-8859-15; format=flowed
 Content-Transfer-Encoding: 7bit
 
 ext John Baldwin wrote:
 > On Thursday 21 August 2008 07:39:07 pm Arthur Hartwig wrote:
 >   
 >> ext John Baldwin wrote:
 >>     
 >>> On Wednesday 20 August 2008 09:26:06 pm Arthur Hartwig wrote:
 >>>   
 >>>       
 >>>> ext John Baldwin wrote:
 >>>>     
 >>>>         
 >>>>> I've committed a variant of this.  I moved the PAE check into 
 >>>>> pciereg_cfgopen() as it is may be relevant for other chipsets as well.  
 >>>>>       
 >>>>>           
 >>> PCIe 
 >>>   
 >>>       
 >>>>> is not currently supported on amd64, but it should be trivial since the 
 >>>>> direct map can be used there.  I may attempt to do that next.
 >>>>>       
 >>>>>           
 >>>> By "PCIe is not currently supported on amd64" did you mean "Access to 
 >>>> PCI extended configuration registers is not supported on amd64"? (PCI 
 >>>> Express device and chipsets are claimed supported.)
 >>>>
 >>>> We access the extended PCI configuration registers in the 5000 series 
 >>>> chipsets to get error counts. We currently run the CPUs in 32 bit mode 
 >>>> but use of 64 bit mode is under some discussion.
 >>>>     
 >>>>         
 >>> Correct.  However, I fixed this last night (and also fixed the kernel to 
 >>>       
 > use 
 >   
 >>> the ACPI MCFG table so we don't need more chipset-specific hacks in the 
 >>> future).  I need to test it on i386 and then I will commit it today.  I 
 >>> should be able to merge it back to 6.x and 7.x.  BTW, can you check to see 
 >>>       
 > if 
 >   
 >>> any of the chipsets you added support for in your patch have an MCFG table 
 >>>       
 > in 
 >   
 >>> their 'acpidump -t' output?  If so, I'll probably remove them from the 
 >>>       
 > manual 
 >   
 >>> hack list.
 >>>   
 >>>       
 >> G'day John,
 >>     Thanks for your prompt reply. Most of our systems are embedded 
 >> systems. In at least one case the BIOS did not include ACPI support 
 >> because it wouldn't fit.
 >>     Our 915 based system uses MPTABLES, not ACPI.
 >>     Three out of four of our 7520 based systems don't have ACPI data.
 >>     The 5000 based system does have ACPI data - here's its MCFG entry:
 >> /*
 >>   MCFG: Length=60, Revision=1, Checksum=17,
 >>         OEMID=INTEL, OEM Table ID=TIANO, OEM Revision=0x1,
 >>         Creator ID=MSFT, Creator Revision=0x1000013
 >>
 >>         Base Address= 0x00000000d0000000
 >>         Segment Group= 0x0000
 >>         Start Bus= 0
 >>         End Bus= 255
 >>  */
 >>      The base address in this MCFG segment matches what is in pciebar in 
 >> the running system.
 >>
 >> I hope all our future systems will include ACPI. However for the 
 >> embedded systems users it may be worth leaving at least a couple of 
 >> chipsets there as examples for those who might have to "roll their own" 
 >> due to lack of ACPI.
 >>     
 >
 > I think what I shall probably do is just remove the 5000P/V/Z section then but 
 > leave the others, how does that sound?
 >   
 Sounds good to me.
 
 Arthur
 
 
 --------------050909050106010404080603
 Content-Type: text/html; charset=ISO-8859-15
 Content-Transfer-Encoding: 7bit
 
 <!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
 <html>
 <head>
   <meta content="text/html;charset=ISO-8859-15"
  http-equiv="Content-Type">
   <title></title>
 </head>
 <body bgcolor="#ffffff" text="#000000">
 ext John Baldwin wrote:
 <blockquote cite="mid200808212039.14499.jhb@freebsd.org" type="cite">
   <pre wrap="">On Thursday 21 August 2008 07:39:07 pm Arthur Hartwig wrote:
   </pre>
   <blockquote type="cite">
     <pre wrap="">ext John Baldwin wrote:
     </pre>
     <blockquote type="cite">
       <pre wrap="">On Wednesday 20 August 2008 09:26:06 pm Arthur Hartwig wrote:
   
       </pre>
       <blockquote type="cite">
         <pre wrap="">ext John Baldwin wrote:
     
         </pre>
         <blockquote type="cite">
           <pre wrap="">I've committed a variant of this.  I moved the PAE check into 
 pciereg_cfgopen() as it is may be relevant for other chipsets as well.  
       
           </pre>
         </blockquote>
       </blockquote>
       <pre wrap="">PCIe 
   
       </pre>
       <blockquote type="cite">
         <blockquote type="cite">
           <pre wrap="">is not currently supported on amd64, but it should be trivial since the 
 direct map can be used there.  I may attempt to do that next.
       
           </pre>
         </blockquote>
         <pre wrap="">By "PCIe is not currently supported on amd64" did you mean "Access to 
 PCI extended configuration registers is not supported on amd64"? (PCI 
 Express device and chipsets are claimed supported.)
 
 We access the extended PCI configuration registers in the 5000 series 
 chipsets to get error counts. We currently run the CPUs in 32 bit mode 
 but use of 64 bit mode is under some discussion.
     
         </pre>
       </blockquote>
       <pre wrap="">Correct.  However, I fixed this last night (and also fixed the kernel to 
       </pre>
     </blockquote>
   </blockquote>
   <pre wrap=""><!---->use 
   </pre>
   <blockquote type="cite">
     <blockquote type="cite">
       <pre wrap="">the ACPI MCFG table so we don't need more chipset-specific hacks in the 
 future).  I need to test it on i386 and then I will commit it today.  I 
 should be able to merge it back to 6.x and 7.x.  BTW, can you check to see 
       </pre>
     </blockquote>
   </blockquote>
   <pre wrap=""><!---->if 
   </pre>
   <blockquote type="cite">
     <blockquote type="cite">
       <pre wrap="">any of the chipsets you added support for in your patch have an MCFG table 
       </pre>
     </blockquote>
   </blockquote>
   <pre wrap=""><!---->in 
   </pre>
   <blockquote type="cite">
     <blockquote type="cite">
       <pre wrap="">their 'acpidump -t' output?  If so, I'll probably remove them from the 
       </pre>
     </blockquote>
   </blockquote>
   <pre wrap=""><!---->manual 
   </pre>
   <blockquote type="cite">
     <blockquote type="cite">
       <pre wrap="">hack list.
   
       </pre>
     </blockquote>
     <pre wrap="">G'day John,
     Thanks for your prompt reply. Most of our systems are embedded 
 systems. In at least one case the BIOS did not include ACPI support 
 because it wouldn't fit.
     Our 915 based system uses MPTABLES, not ACPI.
     Three out of four of our 7520 based systems don't have ACPI data.
     The 5000 based system does have ACPI data - here's its MCFG entry:
 /*
   MCFG: Length=60, Revision=1, Checksum=17,
         OEMID=INTEL, OEM Table ID=TIANO, OEM Revision=0x1,
         Creator ID=MSFT, Creator Revision=0x1000013
 
         Base Address= 0x00000000d0000000
         Segment Group= 0x0000
         Start Bus= 0
         End Bus= 255
  */
      The base address in this MCFG segment matches what is in pciebar in 
 the running system.
 
 I hope all our future systems will include ACPI. However for the 
 embedded systems users it may be worth leaving at least a couple of 
 chipsets there as examples for those who might have to "roll their own" 
 due to lack of ACPI.
     </pre>
   </blockquote>
   <pre wrap=""><!---->
 I think what I shall probably do is just remove the 5000P/V/Z section then but 
 leave the others, how does that sound?
   </pre>
 </blockquote>
 Sounds good to me.<br>
 <br>
 Arthur<br>
 <br>
 </body>
 </html>
 
 --------------050909050106010404080603--
State-Changed-From-To: patched->closed 
State-Changed-By: jhb 
State-Changed-When: Wed May 6 15:07:11 UTC 2009 
State-Changed-Why:  
I just merged this to 7.  I will not merge it to 6.x due to lack of test 
machines running 6.x.  Note that in 7 it is currently disabled by default 
but can be enabled via the hw.pci.mcfg tunable. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=126525 
>Unformatted:
