[PATCH] PCI bus number management
John Baldwin
jhb at freebsd.org
Fri Feb 7 20:47:31 UTC 2014
On Thursday, February 06, 2014 8:58:42 pm David Shane Holden wrote:
> On 02/06/14 14:37, John Baldwin wrote:
> > I have a patch to teach the PCI bus code and PCI-PCI bridge driver to
> > manage PCI bus numbers. The approach is somewhat similar to how
> > NEW_PCIB manages I/O windows for briges. Each bridge creates an rman
> > to manage the bus numbers for all buses and bridges that live below
> > it. Each bus allocates a bus resource from its parent bridge, and
> > child bridges allocate their ranges from their parent devices. At the
> > "top" of the PCI tree, the Host-PCI bridges allocate their respective
> > bus ranges from their PCI domain/segment. There isn't really a
> > device node for PCI domains, so I created a helper API that basically
> > auto- creates a PCI bus rman for each domain on first use and then
> > sub-allocates from that for Host-PCI bridges.
> >
> > The current patch (with some extra debugging) is at
> > http://people.FreeBSD.org/~jhb/patches/pci_bus_rman.3.patch
> >
> > I would like to commit this to HEAD soon but thought I would post it
> > for some pre-commit testing for the brave. :) If you are really
> > brave, try booting with 'hw.pci.clear_buses=1' which will force the
> > kernel to renumber all buses in the system. If you are really,
> > really brave, try booting with 'hw.pci.clear_bars=1',
> > 'hw.pci.clear_buses=1', and 'hw.pci.clear_pcib=1'. (My laptop
> > survives with all those set)
> >
> > Note that the patch only enables bus number management on amd64 and
> > i386. I believe ia64 just needs to define PCI_RES_BUS for this to
> > work since it mandates ACPI. Porting this to other platforms
> > requires handling PCI_RES_BUS rseources for Host-PCI bridges in
> > bus_alloc_resource(), bus_adjust_resource(), and
> > bus_release_resource().
> >
>
> Setting all 3 on an Atom D510MO works fine. On a Lenovo W520 though
> hw.pci.clear_bars=1 causes a lockup during boot. The last few lines
> with a normal boot are:
>
> pcib0: <ACPI Host-PCI bridge> port 0xcf8-0xcff on acpi0
> pcib0: decoding 5 range 0-0xfe
> pci0: <ACPI PCI bus> on pcib0
> secbus=1, subbus=1
> pci0:0:1:0: allocated initial secbus range
>
> While a verbose boot produces:
>
> pcib0: allocated type 3 (0xc0000400-0xc00007ff) for rid 10 of pci:0:0:26:0
> pcib0: matched entry for 0x26.INTA
> pcib0: slot 26 INTA hardwired to IRQ 26
>
> And it ends there. Setting the other 2 are fine though.
Ok, I think this may be a bit of a known issue in that some video cards
really don't like having their framebuffer disabled, even temporarily. Thanks
for testing!
--
John Baldwin
More information about the freebsd-current
mailing list