Re: Greetings. Having a FIFO overrun when my amplc_pci230 card is set on the other side of a PCI bridge

Hi Ian, just wanted to keep you abreast of where I am. I've found out
that there is some quirk to the motherboard I had that caused lots of
problems with all sorts of cards with PLX pci controllers. Our hardware
provider has replaced the motherboard with one from a different vendor,
so all is well now. 

Thank you for the two patches and your time working with me on the
problem.

mike

On Fri, 2006-01-27 at 17:31 +0000, Ian Abbott wrote:
> On 27/01/06 16:14, Michael R. Head wrote:
> > On Fri, 2006-01-27 at 15:47 +0000, Ian Abbott wrote:
> >> My guess is that the driver is always reading 0xFFFF from the ADCCON 
> >> register that has the "ADC busy" bit.  The ADCCON is in the same region 
> >> as the ADCDATA register, so I think the driver is reading 0xFFFF from 
> >> all registers in that region.  (The digital I/O, counter timer and 
> >> interrupt control registers are in a separate region to the ADC and DAC 
> >> stuff.)
> >>
> >> It would be interesting to change the following line in amplc_pci230.c 
> >> to check this suspicion:
> >>
> >> 			rt_printk("timeout\n");
> >>
> >> becomes:
> >>
> >> 			rt_printk("timeout (adccon=%x)\n", status);
> >>
> >> If it prints "timeout (adccon=ffff)" then my suspicion is correct.
> > 
> > Cool. I'll try that out. What would it mean if is reading that?
> 
> It just means it's having trouble reading (and presumably writing) the 
> I/O ports.  Bad ports usually read all ones. 0xFFFF is not a valid value 
> for the ADCCON register, so reads that, something's definately wrong.
> 
> >>> I'm finding trouble with other PCI cards on the expansion, so it could
> >>> be a chipset issue or a general linux problem. If you can make an
> >>> educated guess as to what's causing the timeout across the PCI bridge,
> >>> I'd appreciate it. Do you think interrupts are simply not being
> >>> propagated? Maybe I/O or memory port data isn't getting to the card?
> >> ./inpn won't be using interrupts, but the other bug-fix for the 
> >> never-ending interrupts suggests that interrupts are getting through and 
> >> that the region containing the interrupt status and control registers is 
> >> at least partially working.  The region containing the ADC and DAC 
> >> registers probably isn't working, but I don't know if that is due to the 
> >> PLX PCI9052 bridge chip on the card, the PCI-to-PCI bridge or something 
> >> else.  The fact that you're having trouble with other cards lets us off 
> >> the hook a bit unless they are also using PLX chips!
> > 
> > All the cards I am  having trouble with are using PLX chips of different
> > model numbers. I did try a regular netgear ethernet card last month and
> > it worked in all the slots.
> 
> That's interesting as it suggests some problem with PLX chips.  The most 
> recent PLX chips for this sort of application (the 9000 series chips) 
> are the 9030, 9056 and 9656 (the last one being for 64-bit applications) 
> so it would be interesting to see if any of those have the same trouble. 
>   If you can get hold of a PCI230+ card from Amplicon to try out, it 
> uses the newer PLX PCI 9030 chip.
> 
-- 
Michael R. Head <burner_at_suppressingfire.org>
GPG: http://www.suppressingfire.org/~burner/gpg.key.txt [0x4C9DA1D0]