Skip site navigation (1)Skip section navigation (2)
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>