PNP used to have a fixed-size pnp_resource_table for tracking the
resources used by a device.  This table often overflowed, so we've
had to increase the table size, which wastes memory because most
devices have very few resources.

This patch replaces the table with a linked list of resources where
the entries are allocated on demand.

This removes messages like these:

    pnpacpi: exceeded the max number of IO resources
    00:01: too many I/O port resources

References:

    http://bugzilla.kernel.org/show_bug.cgi?id=9535
    http://bugzilla.kernel.org/show_bug.cgi?id=9740
    http://lkml.org/lkml/2007/11/30/110

This patch also changes the way PNP uses the IORESOURCE_UNSET,
IORESOURCE_AUTO, and IORESOURCE_DISABLED flags.

Prior to this patch, the pnp_resource_table entries used the flags
like this:

    IORESOURCE_UNSET
	This table entry is unused and available for use.  When this flag
	is set, we shouldn't look at anything else in the resource structure.
	This flag is set when a resource table entry is initialized.

    IORESOURCE_AUTO
	This resource was assigned automatically by pnp_assign_{io,mem,etc}().

	This flag is set when a resource table entry is initialized and
	cleared whenever we discover a resource setting by reading an ISAPNP
	config register, parsing a PNPBIOS resource data stream, parsing an
	ACPI _CRS list, or interpreting a sysfs "set" command.

	Resources marked IORESOURCE_AUTO are reinitialized and marked as
	IORESOURCE_UNSET by pnp_clean_resource_table() in these cases:

	    - before we attempt to assign resources automatically,
	    - if we fail to assign resources automatically,
	    - after disabling a device

    IORESOURCE_DISABLED
	Set by pnp_assign_{io,mem,etc}() when automatic assignment fails.
	Also set by PNPBIOS and PNPACPI for:

	    - invalid IRQs or GSI registration failures
	    - invalid DMA channels
	    - I/O ports above 0x10000
	    - mem ranges with negative length

After this patch, there is no ...
[ message continues ]

This patch kills my prehistoric dual PIII.

http://userweb.kernel.org/~akpm/p5135912.jpg
http://userweb.kernel.org/~akpm/config-vmm.txt
http://userweb.kernel.org/~akpm/dmesg-vmm.txt
--

[ message continues ]

Thanks for the report.  I think I've fixed the problem.  You had
to remove the following three patches:

  pnp-replace-pnp_resource_table-with-dynamically-allocated-resources.patch
  pnp-remove-ratelimit-on-add-resource-failures.patch
  pnp-dont-sort-by-type-in-sys-resources.patch

I'll post a new set of four patches (I added one patch to fix this
problem) to replace those.  They should go at the same point in the
series as the three you removed.

Bjorn
--

[ message continues ]

I saw it was PnPBIOS by the way. PnPBIOS appears to be obsolete these 
days; do you have machines to test it on yourself? I do (plenty), so 
although I'm not being fast with testing anyway, would you want me to 
switch those from PnPACPI to PnPBIOS?

Rene.
--

[ message continues ]

All of my machines have ACPI, but in this case, I was able to
reproduce the null pointer dereference Andrew by booting with
"pnpacpi=off".

PNPBIOS testing is pretty scarce, though, so anything you
do along those lines would be much appreciated.

Bjorn
--

[ message continues ]