[openib-general] [discuss] Re: 2.6.19-rc4: known unfixed regressions (v3)
torvalds at osdl.org
Wed Nov 8 11:25:40 PST 2006
On Wed, 8 Nov 2006, Aaron Durbin wrote:
> For instance, if the MCFG region is being reported in ACPI land as 256
> buses and the e820 has a reservation at the MCFG base address of 18MB
> that does not necessarily mean the MCFG region allows for PCI config
> access on 18 buses. It could be that it only allows 16 buses w/ another
> piece of hardware on that last 2MB.
Oh, I agree. You'd _hope_ that the BIOS reports that as a separate region,
and we could use that as a hint, but it's never going to be fool-proof.
It's just much much better to try to figure out what the hardware itself
thinks it is doing, rather than relying on a firmware engineer filling out
the table to match what he _thinks_ the hardware is doing (or, more
accurately, randomly scribbling values until Windows boots, at which point
it's not his problem any more, and people ship the crap).
Some misguided people used to think that we shouldn't do our own PCI
probing, but use ACPI instead. This is the same thing, except on a smaller
scale. MAYBE the scale ends up being so small that we can figure out some
reliable way without actually asking the hardware itself, but I kind of
doubt it. Especially judging by the current situation.
> So what is the proper scenario? One needs to know the actual upper limit of
> MCFG region. Otherwise when detecting unreachable devices one could be poking
> something else in the process of trying to discover these unreachable devices.
> I am open to ideas and am willing to rework some of the code, but I do like
> the idea of having the region being reported in the resource table.
Absolutely. I'd _love_ to have the region reported in the resource table.
It's just that right now it doesn't seem practical, since the downsides
are bigger than the upsides (and the upsides aren't _that_ big, since we
require the thing to be marked reserved in the e820 tables anyway, so the
resource tables do know about it, about as well as they currently can).
In the absense of a way to actually ask the hardware, we could perhaps
modify the thing so that it does request the regions in the resource
table, but _only_ if the e820 entries aren't there (ie the "config type 1
didn't even work" case).
Alternatively, we might choose to request just the known smallest region,
because that should be relatively "safer". It's better than not reporting
the regions at all, and while it's not perfect, it at least shouldn't have
huge potential downsides from getting the size totally wrong...
More information about the general