Hi,

We have an Supermicro MBD-X8DTH-6 mainboard here.  It has an
additional PCI bus behind the pchb0 host bridge.  This diff from
mikeb@ makes OpenBSD detect the pci1 bus.

bluhm


Index: arch/i386/pci/pchb.c
===================================================================
RCS file: /mount/cvsdev/cvs/openbsd/src/sys/arch/i386/pci/pchb.c,v
retrieving revision 1.85
diff -u -p -r1.85 pchb.c
--- arch/i386/pci/pchb.c	31 Aug 2010 17:13:46 -0000	1.85
+++ arch/i386/pci/pchb.c	1 Dec 2010 22:15:14 -0000
@@ -113,6 +113,9 @@

 #define AMD64HT_LDT_SEC_BUS_NUM(reg)	(((reg) >> 8) & 0xff)

+#define I825520_HB_IOHMISCSS		0x09c
+#define  I825520_HB_IOHMISCSS_DUALIOH	(1<<25)
+
 struct pchb_softc {
 	struct device sc_dev;

@@ -300,6 +303,19 @@ pchbattach(struct device *parent, struct
 			}
 			if (pbnum != 0)
 				doattach = 1;
+			break;
+		case PCI_PRODUCT_INTEL_825520_HB:
+			tag = pci_make_tag(pa->pa_pc, 0, 20, 0);
+			if (pci_conf_read(pa->pa_pc, tag, I825520_HB_IOHMISCSS)
+			    & I825520_HB_IOHMISCSS_DUALIOH) {
+				/*
+				 * Intel doesn't properly document a way to
+				 * figure out the bus number, so we hardcode
+				 * it for now.
+				 */
+				pbnum = 0x80;
+				doattach = 1;
+			}
 			break;
 		/* RNG */
 		case PCI_PRODUCT_INTEL_82810_HB:


OpenBSD 4.8-current (GENERIC.MP) #2: Wed Dec  1 23:15:34 CET 2010
    bluhm@g711.genua.de:/usr/src/sys/arch/i386/compile/GENERIC.MP
cpu0: Intel(R) Xeon(R) CPU X5570 @ 2.93GHz ("GenuineIntel" 686-class) 2.94
GHz
cpu0:
FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUS
H,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,SBF,SSE3,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3
,CX16,xTPR,PDCM,DCA,SSE4.1,SSE4.2,POPCNT
real mem  = 3211845632 (3063MB)
avail mem = 3149238272 (3003MB)
mainbus0 at root
bios0 at mainbus0: AT/286+ BIOS, date 03/04/10, BIOS32 rev. 0 @ 0xf0010,
SMBIOS rev. 2.6 @ 0x99c00 (88 entries)
bios0: vendor American Megatrends Inc. version "1.1b" date 03/04/2010
bios0: Supermicro X8DTH-i/6/iF/6F
acpi0 at ...
[ message continues ]

I've discussed this diff before with mikeb@ before.  The reason this
wasn't committed is that there is a chance that there is a potential
for regressions on some machines.  Perhaps it is good to discuss these

That comment isn't true.  The method is documented, but requires
reading values from PCIe extended config space.  This is currently

(I'd prefer if a decimal value was used here, since that is how we
usually print PCI bus numbers).

The hardcoded value here is the hardware default value.  It is a
sensible value, that basically divides config space into equal parts
divided over both IOHs.  I expect most vendors to stick with this default.

However, if the BIOS changes the default value and the machine uses
this bus number on stuff behind the primary IOH, we get into deep
shit, attaching the bus and all devices on it twice.  That isn't going
to end well.

Now dual-IOH machines seem to be rare, so this may be an acceptable
risk.  But I just thought of a way to eliminate that risk, by adding a
check that the device sitting at bus 128, device 0 function 0 is
indeed:

ppb0 at pci1 dev 0 function 0 vendor "Intel", unknown product 0x3420 rev 0x13

How does that sound?

[ message continues ]