Re: simple pnp bios io resources bug makes system unusable

Re: simple pnp bios io resources bug makes system unusable

[CarlosRomero]

my one line patch just skips an io registration with a simple sanity check.
never once have i heard a device with an ioport of 0x0.
question is why it happens and only once.
tested with

ISA Plug and Play:
U.S. Robotics Sportster 33600 FAX/Voice Int
Creative ViBRA16C PnP
Crystal Codec

Host/PCI Bridge:
VIA Technologies, In VT82C585VP [Apollo V
VIA Technologies, In VT82C586/A/B PCI-to-
VIA Technologies, In VT82C586/B/686A/B PI
VIA Technologies, In USB
VIA Technologies, In VT82C586B ACPI

(also noticing cutoff in /sys/devices/pci0/*/name)

>Yes, I also ran into this problem, Adam is was also working on a fix
>although I wonder if it's the same fix?

>Shawn S.

>>List:     linux-kernel
>>Subject:  simple pnp bios io resources bug makes  system unusable
>>From:     CarlosRomero <caberome () bellsouth ! net>
>>Date:     2003-07-01 3:38:17

>>cat /sys/devices/pnp0/00\:0c/name
>>Reserved Motherboard Resources

>>cat /sys/devices/pnp0/00\:0c/resources
>>state = active
>>io 0x4d0-0x4d1
>>io 0xcf8-0xcff
>>io 0x3f7-0x3f7
>>io 0x401-0x407
>>io 0x298-0x298
>>io 0x00000000-0xffffffff
>>mem 0xfffe0000-0xffffffff
>>mem 0x100000-0x7ffffff

>>fixup: check for null io base, other devices are now able to initialize.

Re: simple pnp bios io resources bug makes system unusable

[Adam Belay]

On Tue, Jul 01, 2003 at 01:54:10AM -0400, CarlosRomero wrote:
> my one line patch just skips an io registration with a simple sanity check.
> never once have i heard a device with an ioport of 0x0.

AT DMA controller as stated in my other message, is one example.

> question is why it happens and only once.

It only happens once because in 99% of cases the entire device is disabled,
not just an individual range.

> (also noticing cutoff in /sys/devices/pci0/*/name)

There is a hard limit for device name length, see include/linux/device.h.
That is probably the cause.

Thanks,
Adam

Re: simple pnp bios io resources bug makes system unusable

[Shawn Starr]

The problem I experienced was when I disable parport in the IBM BIOS, PnP
gets invalid values it set io 0x0 -> 0xfffffffffff and some other misc
values for IRQ and DMA.

This might fix that issue.

isapnp: Card 'Crystal Audio'
isapnp: Card 'Creative SB32 PnP'
isapnp: Card 'U.S. Robotics Sportster 33600 FAX/Voice Int'
isapnp: 3 Plug & Play cards detected total

There some other issues though that are being worked on.

Shawn S.

>my one line patch just skips an io registration with a simple sanity
>check.
>never once have i heard a device with an ioport of 0x0.
>question is why it happens and only once.
>tested with

>ISA Plug and Play:
>U.S. Robotics Sportster 33600 FAX/Voice Int
>Creative ViBRA16C PnP
>Crystal Codec

>Host/PCI Bridge:
>VIA Technologies, In VT82C585VP [Apollo V
>VIA Technologies, In VT82C586/A/B PCI-to-
>VIA Technologies, In VT82C586/B/686A/B PI
>VIA Technologies, In USB
>VIA Technologies, In VT82C586B ACPI

>(also noticing cutoff in /sys/devices/pci0/*/name)

Re: simple pnp bios io resources bug makes system unusable

[Shawn Starr]

Yes, I also ran into this problem, Adam is was also working on a fix
although I wonder if it's the same fix?

Shawn S.

>List:     linux-kernel
>Subject:  simple pnp bios io resources bug makes  system unusable
>From:     CarlosRomero <caberome () bellsouth ! net>
>Date:     2003-07-01 3:38:17

>cat /sys/devices/pnp0/00\:0c/name
>Reserved Motherboard Resources

>cat /sys/devices/pnp0/00\:0c/resources
>state = active
>io 0x4d0-0x4d1
>io 0xcf8-0xcff
>io 0x3f7-0x3f7
>io 0x401-0x407
>io 0x298-0x298
>io 0x00000000-0xffffffff
>mem 0xfffe0000-0xffffffff
>mem 0x100000-0x7ffffff

>fixup: check for null io base, other devices are now able to initialize.

simple pnp bios io resources bug makes system unusable

[CarlosRomero]

cat /sys/devices/pnp0/00\:0c/name
Reserved Motherboard Resources

cat /sys/devices/pnp0/00\:0c/resources
state = active
io 0x4d0-0x4d1
io 0xcf8-0xcff
io 0x3f7-0x3f7
io 0x401-0x407
io 0x298-0x298
io 0x00000000-0xffffffff
mem 0xfffe0000-0xffffffff
mem 0x100000-0x7ffffff

fixup: check for null io base, other devices are now able to initialize.

static void current_ioresource(struct pnp_resource_table * res, int io, 
int len)
{
        int i = 0;
 
+      if (!io) return;
        while ((res->port_resource[i].flags & IORESOURCE_IO) && i < 
PNP_MAX_PORT) i++;
        if (i < PNP_MAX_PORT) {
                res->port_resource[i].start = (unsigned long) io;
                res->port_resource[i].end = (unsigned long)(io + len - 1);
                res->port_resource[i].flags = IORESOURCE_IO;  // Also 
clears _UNSET flag
        }
}

Re: simple pnp bios io resources bug makes system unusable

[Adam Belay]

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
busy.

On Mon, Jun 30, 2003 at 11:38:17PM -0400, CarlosRomero wrote:
> cat /sys/devices/pnp0/00\:0c/name
> Reserved Motherboard Resources
> 
> cat /sys/devices/pnp0/00\:0c/resources
> state = active
> io 0x4d0-0x4d1
> io 0xcf8-0xcff
> io 0x3f7-0x3f7
> io 0x401-0x407
> io 0x298-0x298
> io 0x00000000-0xffffffff
> mem 0xfffe0000-0xffffffff
> mem 0x100000-0x7ffffff
> 
> fixup: check for null io base, other devices are now able to initialize.

Unfortunatly it's not quite that simple.

> static void current_ioresource(struct pnp_resource_table * res, int io, 
> int len)
> {
>        int i = 0;
> 
> +      if (!io) return;
>        while ((res->port_resource[i].flags & IORESOURCE_IO) && i < 
> PNP_MAX_PORT) i++;
>        if (i < PNP_MAX_PORT) {
>                res->port_resource[i].start = (unsigned long) io;
>                res->port_resource[i].end = (unsigned long)(io + len - 1);
>                res->port_resource[i].flags = IORESOURCE_IO;  // Also
> clears _UNSET flag
>        }
> }

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

(one for mem)
# cat id
PNP0c01 /* this is a system device */
# cat resources
state = active
mem 0x0-0x9ffff
mem 0xe4000-0xfffff
mem 0x100000-0x3ffffff
mem 0xfff80000-0xfffbffff

(and one for io ports)
# cat id
PNP0200	/* this is an AT DMA Controller */
# cat resources
state = active
io 0x0-0xf
io 0x81-0x8f
io 0xc0-0xdf
dma 4

Therefore just eliminating base 0 addresses is not a proper solution.

Also if we just skip the culprit resource then the resource index number
(a value that many drivers require to be consistent) will be offset by
the number of skipped resources of the same type.

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.

Also a device can have a disabled resource but not be fully disabled,
such as a parport with some features disabled (ECP etc).  So the
index number must be maintained, this will require some more complex
changes.

I'll have a full fix out soon.

Thanks,
Adam

Re: simple pnp bios io resources bug makes system unusable

[Linus Torvalds]

In article <20030701223050.GA19402@neo.rr.com>,
Adam Belay  <ambx1@neo.rr.com> 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
>busy.

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

Look:

>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)
		return;

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
			    behaviour)

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.

			Linus