Date: Wed, 14 Oct 2009 14:20:38 -0700 From: Marcel Moolenaar <xcllnt@mac.com> To: John Baldwin <jhb@freebsd.org> Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org, Warner Losh <imp@bsdimp.com> Subject: Re: svn commit: r197969 - head/sys/conf Message-ID: <6B860A3C-C1F0-42A0-8ECB-3D41DA698EE2@mac.com> In-Reply-To: <200910141645.26010.jhb@freebsd.org> References: <EC2B1366-67F5-4021-A5A0-040D035ADD6C@mac.com> <20091014.113945.74724941.imp@bsdimp.com> <2D55EFED-675A-4CC7-AF39-DE83961552F0@mac.com> <200910141645.26010.jhb@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Oct 14, 2009, at 1:45 PM, John Baldwin wrote: > 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. The key here being requests that reach the PCI-ISA bridge. It's entirely platform specific which I/O memory addresses generated by the CPU gets decoded and forwarded in such a way that it's visible to the PCI-ISA bridge. This is what needs to be obtained from the parent in the newbus hierarchy. Rather than hardcoding [0xC0000 .. 0x100000> as the ISA option ROM memory range, it should be something like [isa_mem_base+0xC0000 .. isa_mem_base + 0x100000> or even [isa_rom_base .. isa_rom_base + 0x40000>. -- Marcel Moolenaar xcllnt@mac.com
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?6B860A3C-C1F0-42A0-8ECB-3D41DA698EE2>