From owner-svn-src-head@FreeBSD.ORG Wed Oct 14 21:21:14 2009 Return-Path: Delivered-To: svn-src-head@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CC20D1065670; Wed, 14 Oct 2009 21:21:14 +0000 (UTC) (envelope-from xcllnt@mac.com) Received: from asmtpout030.mac.com (asmtpout030.mac.com [17.148.16.105]) by mx1.freebsd.org (Postfix) with ESMTP id B3BCA8FC20; Wed, 14 Oct 2009 21:21:14 +0000 (UTC) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=us-ascii; format=flowed; delsp=yes Received: from [172.24.241.207] (natint3.juniper.net [66.129.224.36]) by asmtp030.mac.com (Sun Java(tm) System Messaging Server 6.3-8.01 (built Dec 16 2008; 32bit)) with ESMTPSA id <0KRI0072KWMFMY40@asmtp030.mac.com>; Wed, 14 Oct 2009 14:20:41 -0700 (PDT) From: Marcel Moolenaar In-reply-to: <200910141645.26010.jhb@freebsd.org> Date: Wed, 14 Oct 2009 14:20:38 -0700 Message-id: <6B860A3C-C1F0-42A0-8ECB-3D41DA698EE2@mac.com> References: <20091014.113945.74724941.imp@bsdimp.com> <2D55EFED-675A-4CC7-AF39-DE83961552F0@mac.com> <200910141645.26010.jhb@freebsd.org> To: John Baldwin X-Mailer: Apple Mail (2.1076) Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org, Warner Losh Subject: Re: svn commit: r197969 - head/sys/conf X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Oct 2009 21:21:14 -0000 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