Re: simple pnp bios io resources bug makes system unusable

From: Linus Torvalds (
Date: Wed Jul 02 2003 - 12:20:21 EST

In article <>,
Adam Belay <> wrote:
>The pnpbios is reserving the complete range of every possible
>io port. This causes device activation to fail for every device
>that needs an io port because that resource will always appear

No, I don't think that's what it is doing at all. Quite the reverse, in


>On Mon, Jun 30, 2003 at 11:38:17PM -0400, CarlosRomero wrote:
>> cat /sys/devices/pnp0/00\:0c/resources
>> io 0x00000000-0xffffffff

This means that "io" was zero, but more importantly, it means that "len"
was zero too.

>> fixup: check for null io base, other devices are now able to initialize.
>Unfortunatly it's not quite that simple.

It _is_ that simple, but the code should check for "len" being zero, ie
the fix looks like it should be just a simple

        if (!len)

and that should fix it.

>Below are two examples that both use a base of 0 in a valid way.

Yes, and clearly they don't have "len == 0".

>Currently I'm leaning toward this logic...
>if we have any of the following situations
>- 0x00000000 for base and 0xffffffff for end
>- 0x00000000 for base and 0x00000000 for end
>- 0xffffffff for base and 0xffffffff for end
>then the resource range can be considered disabled.

I would suggest:

 - "len == 0" => obviously disabled (both IO and memory)
 - "end < base" => obviously disabled due to overflow crap
 - "end >= 0x10003" => IO disabled (yeah, non-x86 can have IO above
                            that range in PCI, but I think it's undefined

all three should be cases of "obviously we can't validly have such a
resource", and the "len == 0" case should trivially fix the case that
CarlosRomero saw.

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

This archive was generated by hypermail 2b29 : Mon Jul 07 2003 - 22:00:16 EST