From owner-cvs-all@FreeBSD.ORG Fri Mar 18 19:50:24 2005 Return-Path: Delivered-To: cvs-all@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8918816A4CE; Fri, 18 Mar 2005 19:50:24 +0000 (GMT) Received: from ylpvm15.prodigy.net (ylpvm15-ext.prodigy.net [207.115.57.46]) by mx1.FreeBSD.org (Postfix) with ESMTP id 07D0C43D2F; Fri, 18 Mar 2005 19:50:24 +0000 (GMT) (envelope-from nate@root.org) Received: from [10.0.0.34] (adsl-67-119-74-222.dsl.sntc01.pacbell.net [67.119.74.222])j2IJkGba010743; Fri, 18 Mar 2005 14:46:17 -0500 Message-ID: <423B30FA.9080508@root.org> Date: Fri, 18 Mar 2005 11:50:18 -0800 From: Nate Lawson User-Agent: Mozilla Thunderbird 1.0RC1 (X11/20041205) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Warner Losh References: <20050318051958.3E89916A53A@hub.freebsd.org> <423B2B40.6080600@root.org> <20050318.123638.71154949.imp@bsdimp.com> In-Reply-To: <20050318.123638.71154949.imp@bsdimp.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit cc: cvs-src@FreeBSD.org cc: src-committers@FreeBSD.org cc: cvs-all@FreeBSD.org Subject: Re: cvs commit: src/sys/dev/cardbus cardbus.c src/sys/dev/pccard isa_common.c src/sys/kern subr_bus.c src/sys/sys bus.h X-BeenThere: cvs-all@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: CVS commit messages for the entire tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Mar 2005 19:50:24 -0000 Warner Losh wrote: > From: Nate Lawson >>Great change. One nit: the reverse order helped expose bugs in some >>resource allocation routines. > > It did? Which ones? The rids weren't affected by the change, just > the order that they were stored on the list. And so far as I could > tell, nobody depends on the order in the list for anything: everybody > searches the list for the rigth rid to use. I've not seen any > evidence of this being the case, but maybe I'm forgetting something. The acpi sysres code uses a list and walks through it to handle bad resources specified by the BIOS (i.e., overlapping in weird ways), see acpi_sysres_attach(). It's the only real user of rman. The current code there depends on the order in one way: when resources are wholly contained in each other, the first one allocated wins. This should not have an effect in what we allocate but is an order dependency. >>It might be nice to have some DEBUG >>option that inserted it at the head. The backwards behavior actually >>triggered the bug you fixed in rman on various systems and might have >>lead us to it earlier if someone had run it down. (Thanks for fixing >>that too.) > > No. The bug I fixed was due to the time through the fdc > allocation doing the wrong thing and gobbling up too many ioports. > It would be there independent of this change. Recall that the rid of > the resource is in the struct resource_list_entry and that the > standard subr_bus.c routines all search for a rid by value, rather > than by list location. The acpi sysres code did trigger this bug when users had a device which allocated a resource that overlapped rman and acpi. -- Nate