svn commit: r197969 - head/sys/conf
jhb at freebsd.org
Wed Oct 14 20:59:40 UTC 2009
On Wednesday 14 October 2009 2:35:16 pm Marcel Moolenaar wrote:
> On Oct 14, 2009, at 10:39 AM, Warner Losh wrote:
> > I can't be more clear than this. You keep ignoring me, and it is very
> > frustrating.
> I'm not ignoring you. I'm still talking. You simply haven't convinced
> me. While it's possible (likely?) that I don't understand the issues,
> all you've achieved so far is that I'm more convinced that limiting
> orm(4) to i386 and amd64 is the right thing, because the alternative
> is not at all appealing.
> > The problem is that the
> > powerpc and itanium isa modules allow memory ranges that shouldn't be
> > allowed. That's the platform specific code that needs to be fixed.
> isa_set_resource() is MI code and it happily adds whatever resources
> a driver wants. The only chance MD code has is to fail the allocation,
> but since the whole ISA code bypasses the newbus hierarchy, there's
> no way we know in the isa MD code what is valid and what isn't unless
> we add kluges to platform code.
> If you want to fix it for real, does that mean fix it for real or
> does that mean add kluges to platform code?
> Shouldn't we have ISA bridges obtain the set of valid resources
> from their parent in the newbus hierarchy?
Hmm, can we even know that? PCI-ISA bridges in x86 at least don't have any
I/O limit registers like PCI-PCI bridges, instead they are subtractively
decoded, i.e. they "eat" any memory request that no one else claims. I'm not
sure if other platforms have a way of knowing this however. Are you aware of
something in OFW to communicate this? ACPI does this for Host-PCI bridges
via ResourceProvider() resource entries, but I've never seen ACPI do it for a
More information about the svn-src-all