From owner-cvs-src@FreeBSD.ORG Thu Apr 26 16:02:41 2007 Return-Path: X-Original-To: cvs-src@freebsd.org Delivered-To: cvs-src@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id BF10716A421; Thu, 26 Apr 2007 16:02:41 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (66-23-211-162.clients.speedfactory.net [66.23.211.162]) by mx1.freebsd.org (Postfix) with ESMTP id 527D413C4AE; Thu, 26 Apr 2007 16:02:41 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from localhost.corp.yahoo.com (john@localhost [127.0.0.1]) (authenticated bits=0) by server.baldwin.cx (8.13.8/8.13.8) with ESMTP id l3QG2al2076186; Thu, 26 Apr 2007 12:02:36 -0400 (EDT) (envelope-from jhb@freebsd.org) From: John Baldwin To: Nate Lawson Date: Thu, 26 Apr 2007 11:48:22 -0400 User-Agent: KMail/1.9.6 References: <20070425162233.8CCFC16A59E@hub.freebsd.org> <200704251356.35785.jhb@freebsd.org> <462FCEB9.40406@root.org> In-Reply-To: <462FCEB9.40406@root.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200704261148.23501.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (server.baldwin.cx [127.0.0.1]); Thu, 26 Apr 2007 12:02:36 -0400 (EDT) X-Virus-Scanned: ClamAV 0.88.3/3165/Thu Apr 26 09:03:24 2007 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=4.2 tests=ALL_TRUSTED,BAYES_00 autolearn=ham version=3.1.3 X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on server.baldwin.cx Cc: cvs-src@freebsd.org, src-committers@freebsd.org, cvs-all@freebsd.org Subject: Re: cvs commit: src/sys/dev/acpica acpi.c X-BeenThere: cvs-src@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: CVS commit messages for the src tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Apr 2007 16:02:41 -0000 On Wednesday 25 April 2007 05:57:13 pm Nate Lawson wrote: > John Baldwin wrote: > > On Wednesday 25 April 2007 12:48:50 pm Nate Lawson wrote: > >> John Baldwin wrote: > >>> jhb 2007-04-25 16:22:18 UTC > >>> > >>> FreeBSD src repository > >>> > >>> Modified files: > >>> sys/dev/acpica acpi.c > >>> Log: > >>> Use a tighter check to see if a resource allocation request is for a > >>> specific request and thus should first try to be allocated from the > >>> sys_resource pool. This avoids using the sys_resource pool for wildcard > >>> requests that have bounded ranges coming from cbb(4) and Host-PCI > > pcib(4) > >>> drivers. > >>> > >>> Tested by: Andrea Bittau > >>> Sleuthing by: Andrea Bittau as well > >>> > >>> Revision Changes Path > >>> 1.235 +1 -1 src/sys/dev/acpica/acpi.c > >>> > >>> > >>> Index: src/sys/dev/acpica/acpi.c > >>> diff -u src/sys/dev/acpica/acpi.c:1.234 src/sys/dev/acpica/acpi.c:1.235 > >>> --- src/sys/dev/acpica/acpi.c:1.234 Thu Mar 22 18:16:40 2007 > >>> +++ src/sys/dev/acpica/acpi.c Wed Apr 25 16:22:18 2007 > >>> @@ -1034,7 +1034,7 @@ > >>> * the request from our system resource regions. If we can't, pass > > the > >>> * request up to the parent. > >>> */ > >>> - if (!(start == 0UL && end == ~0UL) && rm != NULL) > >>> + if (start + count - 1 == end && rm != NULL) > >>> res = rman_reserve_resource(rm, start, end, count, flags & ~RF_ACTIVE, > >>> child); > >>> if (res == NULL) { > >> I think I'll test this to see if it helps my via 8235 ata survive boot. > > > > I wonder if in fact the algorithm shouldn't be changed to always try to alloc > > the resource from the parent first, and only fall back to the sys_resource > > rmans if that fails? In theory any resource requests that should be done via > > sys_resource will fail the request in the parent, yes? > > > > Yes, that should be ok but why not do local first and then push up tree > if it fails? Semantically, a child of your bus requested the resource > so most of the time you should be able to handle it. Very few resources should really be alloc'd from sysresource though. No PCI device should be alloc'ing from that for example. It's really only for special drivers like IPMI (when it's not enumerated as an ACPI device, but only via SMBIOS tables) where a system resource is reserving it because it is in use and needs to keep another device (like on PCI where resources aren't fixed) from using it. Thus, really only a specific allocation of a resource in sys_resource should ever alloc from that, and all those specific allocations will fail up in nexus since sys_resource has already claimed those regions. -- John Baldwin