Could it be possible that bit 0 is just writable for this base address
register. You can verify that by hacking appropriately the Cyclades driver
in its detection routine. You may try for example:
- Read the value of the offending base address reg. and save it.
- Write 1 to that base address reg., then read it and print the value.
- Write 0 to that base address, then read it and print the value.
- Restore the value of that base address.
(You can use debug under DOS to read/write the config space if you
prefer, and know how to deal with)
Note that if bit 0 is writable, the device may just be bogus and not
conformant to PCI specs, but it could be trivial to work around the
problem.
Regards,
Gérard.
On Thu, 15 Apr 1999, Linux Lists wrote:
>
> Hi there,
>
> I have a customer with a pretty weird problem.
>
> - Pentium MMX 200MHz
> - AMI BIOS
> - Intel Triton II chipset
> - Cyclades Cyclom-YeP (32 ports)
> - Linux Red Hat
> - Kernel 2.0.36 (stock kernel, not RPM)
>
> When the driver is built into the kernel (monolythic), the Cyclades card
> is detected by the kernel, but no interrupts are generated by the card.
>
> Analyzing the problem a little further, I noticed that /proc/pci yells:
>
> $ cat /proc/pci
> PCI devices found:
> <snip>
> Communication controller: Cyclades Cyclom-Y above 1Mbyte (rev 1).
> Medium devsel. Fast back-to-back capable. IRQ 15. Master Capable.
> Latency=32.
> Non-prefetchable 32 bit memory at 0xe031a000.
> I/O at 0x6200.
> I/O at 0xe0310000.
> ^^^^^^^^^^^^^^^^^
>
> , when it should be yelling:
>
> $ cat /proc/pci
> PCI devices found:
> <snip>
> Bus 0, device 18, function 0:
> Communication controller: Cyclades Cyclom-Y above 1Mbyte (rev 1).
> Medium devsel. Fast back-to-back capable. IRQ 15. Master Capable.
> Latency=32.
> Non-prefetchable 32 bit memory at 0xe031a000.
> I/O at 0x6200.
> Non-prefetchable 32 bit memory at 0xe0310000.
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>
> For those who know PCI: the first address bits (before the masking) are
> 0x01, which means the address is being allocated as an I/O address.
> However, I am _sure_ the card _requests_ a 32-bit memory address (bits
> equals 0x00), yet it's being assigned an I/O adress instead.
>
> Another interesting info: I was thinking it to be a PCI BIOS problem, but
> then, by booting the system from a DOS floppy and running a diagnostics
> utility, I was able to see that, under DOS, the first address bits for
> that address were correctly set to 0x00. Dunno whether this releases the
> BIOS from being the culprit, but it's kinda weird ...
>
> Furthermore, under this DOS environment in the same system the card
> performs flawlessly.
>
> As additional info:
>
> - I tested the HW itself and it's ok.
> - I swapped the card by another one that I tested in a different system,
> and it had the same problem;
>
> Any hints ???
>
> TIA for your help.
>
> Regards,
> Ivan
>
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.rutgers.edu
> Please read the FAQ at http://www.tux.org/lkml/
>
>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/