isapnp bug in autoconfiguring

isapnp bug in autoconfiguring

Post by Rainer Goellne » Thu, 18 Feb 1999 04:00:00



There's a bug in the isapnp code that probes for devices. The code
believes, the work is done when it has found a_n_y ISA PnP devices,
but has no chance to get to know a_l_l of them under all circumstances.
As far as I can see, the bug is present in any version of FreeBSD that
has PnP support, and probably in any other Unix (including Linux),
that relies on isapnp.

My actual problem is an ISDN adapter, "Sedlbauer Win Speed", sold by
the german Telecom as TeleDat 100, part of a special offer for

other cards with the same (mis?)behaviour:
 - Before I installed the card, the kernel found my SoundBlaster as
   CSN 1, named CTL0051 or so, and was content.
 - After I plugged the ISDN card in (and prayed, as demanded by the
   PnP standard :-(, the kernel found my SoundBlaster as CSN 1, was
   content, and kindly ignored isic0, which is the appropiate device
   for the ISDN card.
 - The BIOS found the ISDN card as CSN 2, indicating that the card
   actually was in place. Unplugging the SoundBlaster revealed it
   in the kernel boot sequence, then as CSN 1 of course.
Having mangled all my PnP adresses this way, I considered buying a
new ISDN card, one that doesn't bother me with a bavarian name at
boot time. But I was ambitious...

So, skipping flames concerning PnP, here's the point:
At the end of /sys/i386/isa/pnp.c, you'll find this loop:

    /* Try various READ_DATA ports from 0x203-0x3ff */
    for (pnp_rd_port = 0x80; (pnp_rd_port < 0xff); pnp_rd_port += 0x10)
{
        if (bootverbose)
            printf("Trying Read_Port at %x\n", (pnp_rd_port << 2) |
0x3);

        num_pnp_devs = pnp_isolation_protocol();
        if (num_pnp_devs)
            break;
    }

pnp_isolation_protocol() will ask all ISA devices to respond on
pnp_rd_port. Obviously, the loop terminates, if at least one of them
does. The SoundBlaster responds at 0x203, the ISDN card does not.
Although the idea is to try again at 0x243, which would be ok for
both cards, the loop never gets there. Hence the kernel never gets
to know the ISDN card.

The solution that works for me is changing the initial value from
0x80 to 0x90. I don't think there has to be a common address, it is
just luck in my case. A clean solution would turn the nested loops
around (the other one is in pnp_isolation_protocol()):
 for (csn = 1; (csn < MAX_PNP_CARDS); csn++)
   for (pnp_rd_port = 0x80; (pnp_rd_port < 0xff); pnp_rd_port += 0x10) {
     if (pnp_isolation_protocol(CSN <-- just for one slot!!!))
     ...and so forth
You see what luck I had? There's only one global pnp_read_port for
all devices :-( Anyone screaming 'I wanna fix it'?

I know, this is the wrong group for bug reports. I'm a bag of nerves
from seeking for that bug, I'm not willing to bother with finding and
filling in the right form at the right place any more.

Nevertheless, I'd like to share the solution. Maybe, someone is willing
to deposit it for me at the right place? Thanks in advance!

--
Rainer G"ollner                      Institut f"ur Arbeitsphysiologie
Brunnenstr. 22                           an der Universit"at Dortmund
44145 Dortmund                           Ardeystr. 67, 44139 Dortmund

 
 
 

1. mangled isapnp IDs in /proc/bus/isapnp/devices

Hi all,

is there a reason why the isapnp device id are mangled this way:

drivers/pnp/isapnp_proc.c

static void isapnp_devid(char *str, unsigned short vendor, unsigned short device)
{
        sprintf(str, "%c%c%c%x%x%x%x",
                        'A' + ((vendor >> 2) & 0x3f) - 1,
                        'A' + (((vendor & 3) << 3) | ((vendor >> 13) & 7)) - 1,
                        'A' + ((vendor >> 8) & 0x1f) - 1,
                        (device >> 4) & 0x0f,
                        device & 0x0f,
                        (device >> 12) & 0x0f,
                        (device >> 8) & 0x0f);

This results in output like:

CSCd937 CSC0000

Which I have to un-mangle ... :-( What is the reason for not outputting
simple hex?

Sincerely,
- Ren

--  
Ren Rebe - Europe/Germany/Berlin

web:      http://www.rocklinux.org/people/rene http://gsmp.tfh-berlin.de/rene/

Anyone sending unwanted advertising e-mail to this address will be
charged $25 for network traffic and computing time. By extracting my
address from this message or its header, you agree to these terms.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

2. xterm with colors?

3. Configuring ISAPNP - isapnp.txt (0/1)

4. Using make with RCS

5. possible bug w/isapnp and / or sndconfig

6. FileSystem Full; How to transfer the Data to another Disc?

7. Autoconfiguring kernel

8. MLPPP on Linux - available ?

9. GTK and the autoconfigure

10. OpenBSD 3.1 RAID 1 with autoconfigure

11. Format's Autoconfigure Fails, Help.

12. how to autoconfigure a new video card?

13. IP autoconfigure via DHCP please help!