Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 18 Mar 2005 11:50:18 -0800
From:      Nate Lawson <nate@root.org>
To:        Warner Losh <imp@bsdimp.com>
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
Message-ID:  <423B30FA.9080508@root.org>
In-Reply-To: <20050318.123638.71154949.imp@bsdimp.com>
References:  <20050318051958.3E89916A53A@hub.freebsd.org> <423B2B40.6080600@root.org> <20050318.123638.71154949.imp@bsdimp.com>

next in thread | previous in thread | raw e-mail | index | archive | help
Warner Losh wrote:
> From: Nate Lawson <nate@root.org>
>>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 <second> 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



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?423B30FA.9080508>