From owner-svn-src-all@FreeBSD.ORG Wed Oct 14 20:59:40 2009 Return-Path: Delivered-To: svn-src-all@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 53FC31065696; Wed, 14 Oct 2009 20:59:40 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 23B248FC3F; Wed, 14 Oct 2009 20:59:40 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id B133A46B0C; Wed, 14 Oct 2009 16:59:39 -0400 (EDT) Received: from jhbbsd.hudson-trading.com (unknown [209.249.190.8]) by bigwig.baldwin.cx (Postfix) with ESMTPA id CAB348A01B; Wed, 14 Oct 2009 16:59:38 -0400 (EDT) From: John Baldwin To: Marcel Moolenaar Date: Wed, 14 Oct 2009 16:45:25 -0400 User-Agent: KMail/1.9.7 References: <20091014.113945.74724941.imp@bsdimp.com> <2D55EFED-675A-4CC7-AF39-DE83961552F0@mac.com> In-Reply-To: <2D55EFED-675A-4CC7-AF39-DE83961552F0@mac.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200910141645.26010.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (bigwig.baldwin.cx); Wed, 14 Oct 2009 16:59:38 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.95.1 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-2.5 required=4.2 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on bigwig.baldwin.cx 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-all@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Oct 2009 20:59:40 -0000 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 PCI-ISA bridge. -- John Baldwin