Re: Regression: bug 85491: radeon 0000:01:00.0: Fatal error during GPU init

[Bjorn Helgaas <bhelgaas@google.com>]

On Mon, Dec 08, 2014 at 04:21:34PM -0800, Yinghai Lu wrote:
> On Mon, Dec 8, 2014 at 3:38 PM, Gavin Shan <gwshan@linux.vnet.ibm.com> wrote:
> > On Mon, Dec 08, 2014 at 02:46:00PM -0700, Bjorn Helgaas wrote:
> >>Yeah, I didn't word that very clearly.  I meant that after
> >>5b28541552ef, that 64-bit window is wasted unless there's a 64-bit BAR
> >>below it; we can't even place the window below 4GB and use it for
> >>32-bit prefetchable BARs.
> >
> > Yes, I agree. It's why I suggested to return error from pbus_size_mem()
> > to indicate the case: 64-bits prefetchable window isn't used and it's
> > still available to be used by child 32-bits prefetchable BARs. Please
> > take a look on the attached draft patch, which helps to explain the idea
> > only.
> 
> That would not help. The 00:01.0 on Zermond's system support hotplug. so mem
> pref will be used for 64bit pref.

Maybe it doesn't work as-is, but I think the idea is worth pursuing.  We
can tell whether there are existing children, and we can tell whether there
are any 64-bit prefetchable BARs.

If there is already a device below a hotplug bridge, and it has no 64-bit
BARs, I think we should use the prefetchable window for that device.

It seems silly to reserve the prefetchable window for a possible future
hot-added device.  That means we penalize the device we already know about
because it can't have any prefetchable space.  And we've consumed some
64-bit space that is unused.  We only benefit if we hot-remove the existing
device and hot-add a new device with 64-bit BARs that happen to fit inside
the 2MB (DEFAULT_HOTPLUG_MEM_SIZE) we allocated for it.  That seems pretty
unlikely.

I don't see any patches that resolve the regression (bug 85491) yet.  If we
don't figure something out, I'm going to have to revert 5b28541552ef.

Bjorn