Messages in this thread | | | Date | Fri, 16 Apr 1999 11:47:50 -0700 (PDT) | From | Linux Lists <> | Subject | Re: Weird PCI problem |
| |
On Thu, 15 Apr 1999, Gerard Roudier wrote: > > A PCI base address register that maps I/O space must have bit 0 > _hardwired_ to 1 by the device. The same way, bit 0 must be hardwired to 0 > for base address registers that map into memory space.
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/
| |