Re: pci-3.14 resource alloc

Re: pci-3.14 resource alloc

[Yinghai Lu]

Hi, Steven,

I just rebased all my pci patches (busn_alloc and resource allocation)
on top Linus
tree and Bjorn's pci/next.

Please check them at
git://git.kernel.org/pub/scm/linux/kernel/git/yinghai/linux-yinghai.git
for-pci-3.15

Let me know if it still works for your setup.

Thanks

Yinghai

Yinghai Lu (28):
  PCI: Try best to allocate pref mmio 64bit above 4g
  PCI, EDAC: fix ordering assign resource and bus_add
  PCI, sysfs: Clean up rescan with schedule_callback
  PCI: Rescan bus using callback method too
  PCI, sysfs: Clean up rescan with schedule_callback
  resources: Split out __allocate_resource()
  resources: Add resource_shrink_parents_top()
  resources: Add probe_resource()
  resources: Replace registered resource in tree.
  PCI: Add pci_bus_extend/shrink_top()
  PCI: Probe safe range that we can use for unassigned bridge.
  PCI: Add pci_bus_replace_busn_res()
  PCI: Allocate bus range instead of use max blindly
  PCI: Strict checking of valid range for bridge
  PCI: Kill pci_fixup_parent_subordinate_busnr()
  PCI: Seperate child bus scanning to two passes overall
  pcmcia: Remove workaround for fixing pci parent bus subordinate
  PCI, pciehp: Remove not needed bus number range checking
  PCI: More strict checking of valid range for bridge
  PCI: Don't shrink too much for hotplug bridge
  PCI: Keep more big bus range for sriov
  PCI: Allocate resource with big size at first when alignment is the same
  resource: Make find_resource could return just fit resource
  resource: Add allocate_resource_fit()
  PCI: Don't allocate small resource in big empty space.
  resource: Only return range with needed align
  PCI: Sort unassigned resources with correct alignment
  PCI, x86: Add pci=assign_pref_bars to realloc pref bars

 arch/x86/include/asm/pci_x86.h |   1 +
 arch/x86/pci/common.c          |   3 +
 arch/x86/pci/i386.c            |  21 ++-
 drivers/edac/i82875p_edac.c    |   3 +-
 drivers/pci/bus.c              |  33 +++--
 drivers/pci/hotplug-pci.c      |  12 +-
 drivers/pci/pci-sysfs.c        |  41 ++++--
 drivers/pci/probe.c            | 321 ++++++++++++++++++++++++++++++-----------
 drivers/pci/remove.c           |  35 +++++
 drivers/pci/setup-bus.c        | 190 ++++++++++++++++--------
 drivers/pci/setup-res.c        |  48 ++++--
 drivers/pcmcia/yenta_socket.c  |  75 ----------
 include/linux/ioport.h         |  15 ++
 include/linux/pci.h            |  11 ++
 kernel/resource.c              | 300 ++++++++++++++++++++++++++++++++++++--
 15 files changed, 828 insertions(+), 281 deletions(-)

Re: pci-3.14 resource alloc

[Yinghai Lu]

On Fri, Feb 14, 2014 at 7:46 AM, Steven Newbury <steve@snewbury.org.uk> wrote:
>>
>> Oh, never mind! I didn't notice pref_bar has been renamed to
>> assign_pref_bars. It's working now! :)
>
> There's no pci bridge/bus hotplug though. Docking doesn't reveal the
> pci-e->pci bridge or the (radeon) devices on the other side.

oh, no. could be other regression in linus tree or pci/next.

Can you check if linus tree could reveal pci-e->pci bridge?

or do you use iommu/dmar with the system?

Thanks

Yinghai

Re: pci-3.14 resource alloc

[Steven Newbury]

On Fri, 2014-02-14 at 11:11 -0800, Yinghai Lu wrote:
> On Fri, Feb 14, 2014 at 7:46 AM, Steven Newbury <steve@snewbury.org.uk> wrote:
> >>
> >> Oh, never mind! I didn't notice pref_bar has been renamed to
> >> assign_pref_bars. It's working now! :)
> >
> > There's no pci bridge/bus hotplug though. Docking doesn't reveal the
> > pci-e->pci bridge or the (radeon) devices on the other side.
> 
> oh, no. could be other regression in linus tree or pci/next.
> 

Sorry about taking a while to get back to you.

Previously I needed the busn work to get it working, this was included
in the resource-alloc branch.  It never worked on mainline, the bridge
used to show up but never get scanned.  Now it's not showing up at all
on hotplug.  It could be a dock driver regression.

> Can you check if linus tree could reveal pci-e->pci bridge?
> 
I'll give it a go.

> or do you use iommu/dmar with the system?
> 
No, the only unusual option is I use pci=nocrs since the bios is
completely ignorant of support for 64bit BARs.   
> Thanks
> 
> Yinghai

Re: pci-3.14 resource alloc

[Bjorn Helgaas]

On Tue, Feb 18, 2014 at 3:08 AM, Steven Newbury <steve@snewbury.org.uk> wrote:
> On Fri, 2014-02-14 at 11:11 -0800, Yinghai Lu wrote:
>> On Fri, Feb 14, 2014 at 7:46 AM, Steven Newbury <steve@snewbury.org.uk> wrote:
>> >>
>> >> Oh, never mind! I didn't notice pref_bar has been renamed to
>> >> assign_pref_bars. It's working now! :)
>> >
>> > There's no pci bridge/bus hotplug though. Docking doesn't reveal the
>> > pci-e->pci bridge or the (radeon) devices on the other side.
>>
>> oh, no. could be other regression in linus tree or pci/next.
>>
>
> Sorry about taking a while to get back to you.
>
> Previously I needed the busn work to get it working, this was included
> in the resource-alloc branch.  It never worked on mainline, the bridge
> used to show up but never get scanned.  Now it's not showing up at all
> on hotplug.  It could be a dock driver regression.
>
>> Can you check if linus tree could reveal pci-e->pci bridge?
>>
> I'll give it a go.
>
>> or do you use iommu/dmar with the system?
>>
> No, the only unusual option is I use pci=nocrs since the bios is
> completely ignorant of support for 64bit BARs.

Hi Steven, this is a tangent, but can you collect the complete dmesg
log with "pci=nocrs" and let me know what happens when you *don't* use
"pci=nocrs" (a complete dmesg log there would be useful too, but I
don't know if you can boot without it)?  I think Linux *should* be
able to handle 64bit BARs even if the BIOS doesn't.

Please post these as a separate thread so we don't muddle this
conversation with Yinghai.

Bjorn

Re: pci-3.14 resource alloc

[Bjorn Helgaas]

On Tue, Feb 18, 2014 at 6:59 AM, Bjorn Helgaas <bhelgaas@google.com> wrote:
> On Tue, Feb 18, 2014 at 3:08 AM, Steven Newbury <steve@snewbury.org.uk> wrote:

>> No, the only unusual option is I use pci=nocrs since the bios is
>> completely ignorant of support for 64bit BARs.
>
> Hi Steven, this is a tangent, but can you collect the complete dmesg
> log with "pci=nocrs" and let me know what happens when you *don't* use
> "pci=nocrs" (a complete dmesg log there would be useful too, but I
> don't know if you can boot without it)?  I think Linux *should* be
> able to handle 64bit BARs even if the BIOS doesn't.
>
> Please post these as a separate thread so we don't muddle this
> conversation with Yinghai.

Oh, never mind.  I think I remember now.  I think the problem is not
so much that the BIOS doesn't handle 64bit *BARs*, but that your BIOS
doesn't report 64bit host bridge *apertures*, and you want to use
space above 4G for a graphics card or something.

That's not really anything we can fix in PCI because PCI doesn't
discover those apertures.  Host bridge drivers like the generic ACPI
pci_root.c or the native amd_bus.c discover them.  If those drivers
don't discover them, PCI can't just make them up.

It might be nice if we had cleaner kernel options to say "assume a
host bridge window here" and "put this device here," so you didn't
have to use the big hammer of "pci=nocrs".  It's sort of a pain to
figure out how to attach info like that to the correct device (there
might be several host bridges, so how do you specify which one you
care about?), but maybe it could be done.

Bjorn

Re: pci-3.14 resource alloc

[Steven Newbury]

On Tue, 2014-02-18 at 07:37 -0700, Bjorn Helgaas wrote:
> On Tue, Feb 18, 2014 at 6:59 AM, Bjorn Helgaas <bhelgaas@google.com> wrote:
> > On Tue, Feb 18, 2014 at 3:08 AM, Steven Newbury <steve@snewbury.org.uk> wrote:
> 
> >> No, the only unusual option is I use pci=nocrs since the bios is
> >> completely ignorant of support for 64bit BARs.
> >
> > Hi Steven, this is a tangent, but can you collect the complete dmesg
> > log with "pci=nocrs" and let me know what happens when you *don't* use
> > "pci=nocrs" (a complete dmesg log there would be useful too, but I
> > don't know if you can boot without it)?  I think Linux *should* be
> > able to handle 64bit BARs even if the BIOS doesn't.
> >
> > Please post these as a separate thread so we don't muddle this
> > conversation with Yinghai.
> 
> Oh, never mind.  I think I remember now.  I think the problem is not
> so much that the BIOS doesn't handle 64bit *BARs*, but that your BIOS
> doesn't report 64bit host bridge *apertures*, and you want to use
> space above 4G for a graphics card or something.
> 
Yes, exactly. I should have stated it better.  I need to push the
on-board i965 up above 4G to make room for a radeon which is accessed
through a 32 bit only bridge.  The BIOS doesn't provide any
functionality like this.  The intel devs seemed a little surprised that
the i965 actually worked stably in this configuration given known
errata, but I've actually had no problems with this side of things. 

> That's not really anything we can fix in PCI because PCI doesn't
> discover those apertures.  Host bridge drivers like the generic ACPI
> pci_root.c or the native amd_bus.c discover them.  If those drivers
> don't discover them, PCI can't just make them up.

32 bit only bridges must be getting pretty rare by now, and I presume
any new hardware out there with a dockable PCI bus would provide 64 bit
resource allocation for host bridge apertures when booting to a 64 bit
OS?  Maybe not?
> 
> It might be nice if we had cleaner kernel options to say "assume a
> host bridge window here" and "put this device here," so you didn't
> have to use the big hammer of "pci=nocrs".  It's sort of a pain to
> figure out how to attach info like that to the correct device (there
> might be several host bridges, so how do you specify which one you
> care about?), but maybe it could be done.
> 
That would be much better, even if it's only some way to say "ignore crs
for *this* host bridge (and parents)", or "for host bridges to which
*this* device is attached".

Re: pci-3.14 resource alloc

[Yinghai Lu]

On Tue, Feb 18, 2014 at 2:08 AM, Steven Newbury <steve@snewbury.org.uk> wrote:
>> >
>> > There's no pci bridge/bus hotplug though. Docking doesn't reveal the
>> > pci-e->pci bridge or the (radeon) devices on the other side.
>>
>> oh, no. could be other regression in linus tree or pci/next.
>>
>
> Previously I needed the busn work to get it working, this was included
> in the resource-alloc branch.  It never worked on mainline, the bridge
> used to show up but never get scanned.  Now it's not showing up at all
> on hotplug.  It could be a dock driver regression.

I had the busn_res_alloc patches in the branch.

There is some changes about acpi dock driver from Rafael in recent
kernels. Maybe Rafael could suggest which commit could cause problem,
then you could try revert them on top of branch.

Thanks

Yinghai

Re: pci-3.14 resource alloc

[Rafael J. Wysocki]

On Tuesday, February 18, 2014 10:52:54 AM Yinghai Lu wrote:
> On Tue, Feb 18, 2014 at 2:08 AM, Steven Newbury <steve@snewbury.org.uk> wrote:
> >> >
> >> > There's no pci bridge/bus hotplug though. Docking doesn't reveal the
> >> > pci-e->pci bridge or the (radeon) devices on the other side.
> >>
> >> oh, no. could be other regression in linus tree or pci/next.
> >>
> >
> > Previously I needed the busn work to get it working, this was included
> > in the resource-alloc branch.  It never worked on mainline, the bridge
> > used to show up but never get scanned.  Now it's not showing up at all
> > on hotplug.  It could be a dock driver regression.
> 
> I had the busn_res_alloc patches in the branch.
> 
> There is some changes about acpi dock driver from Rafael in recent
> kernels. Maybe Rafael could suggest which commit could cause problem,
> then you could try revert them on top of branch.

I kind of suspect what might have caused them, but that particular thing
would not be easy to revert.

Steven, what was the last kernel in which the bridge showed up?

Did you test 3.14-rc3?

Rafael

Re: pci-3.14 resource alloc

[Steven Newbury]

On Tue, 2014-02-18 at 23:29 +0100, Rafael J. Wysocki wrote:
> On Tuesday, February 18, 2014 10:52:54 AM Yinghai Lu wrote:
> > On Tue, Feb 18, 2014 at 2:08 AM, Steven Newbury <steve@snewbury.org.uk> wrote:
> > >> >
> > >> > There's no pci bridge/bus hotplug though. Docking doesn't reveal the
> > >> > pci-e->pci bridge or the (radeon) devices on the other side.
> > >>
> > >> oh, no. could be other regression in linus tree or pci/next.
> > >>
> > >
> > > Previously I needed the busn work to get it working, this was included
> > > in the resource-alloc branch.  It never worked on mainline, the bridge
> > > used to show up but never get scanned.  Now it's not showing up at all
> > > on hotplug.  It could be a dock driver regression.
> > 
> > I had the busn_res_alloc patches in the branch.
> > 
> > There is some changes about acpi dock driver from Rafael in recent
> > kernels. Maybe Rafael could suggest which commit could cause problem,
> > then you could try revert them on top of branch.
> 
> I kind of suspect what might have caused them, but that particular thing
> would not be easy to revert.
> 
> Steven, what was the last kernel in which the bridge showed up?
> 
> Did you test 3.14-rc3?
> 
> Rafael
> 

I'll try a few different kernels today and see when it last worked.  I
hadn't updated the machine since some 3.12-rc + my local patches so I've
no idea at the moment when it stopped working...