> Date: Thu, 2 Dec 2010 00:48:00 +0100
> From: Alexander Bluhm <[email protected]>
>
> 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.
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
issues in piblic, so here we go:
> 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
> @@ -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.
> + */
That comment isn't true. The method is documented, but requires
reading values from PCIe extended config space. This is currently
only supported in OpenBSD/sparc64.
> + pbnum = 0x80;
(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?
