Re: [PATCH] PCI bus number management

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