Ok, I don't know whether this "hardwires" these bits inside our PCI
bridge (which is from PLX), but the EEPROM on the board programs the PCI
bridge to request a 32-bit non-prefetchable memory address from the
system. I think that if the system BIOS / O.S. are operating properly,
this should be enough in order to get that register programmed correctly
as requested.
> It is indeed quite weird to read 1 as bit 0 from a register that should
> have bit 0 hardwired to 0.
Really weird.
> Could it be possible that bit 0 is just writable for this base address
> register.
I don't think this is the case, because the address asginment works
correctly in other systems, and even in the same system, yet in a
different OS (DOS in this case). Without problem consistency within OS's,
I wouldn't point the problem to the hardware.
> 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.
I can't do that right now, as:
- this is a customer's production server;
- the problem _only_ happens on that system;
> 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.
So, do you think that if I _force_ that bit to be 0 by inserting the
appropriate code in the driver, it would make everything work ?? My
question is: wouldn't this affect other parts of the system that have
detected that address as an I/O address before ?!?!? If not, the solution,
although "dirty", is really trivial. The fact is that I always thought
that these PCI base register contents should (must) NOT be changed
manually.
Regards,
Ivan
> 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/