In article <20030701223050.GA19402@neo.rr.com>,
Adam Belay <firstname.lastname@example.org> 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
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
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to email@example.com
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Mon Jul 07 2003 - 22:00:16 EST