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
nate at root.org
Fri Mar 18 11:50:24 PST 2005
Warner Losh wrote:
> From: Nate Lawson <nate at 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
> 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.
More information about the cvs-all