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

Thanks for your reply Angel. I've emailed support at Amplicon Lifeline.
I also found out that some of the cards I'm using (though not this
particular one) have an older PCI interface controller (the PLX PCI9050)
that has issues with PCI bridges. Hopefully I'll be able to resolve some
of my problems by getting new cards that use the PLX PCI9030
controller...

thanks again,
mike

On Thu, 2006-01-05 at 16:18 +0100, Angel Guirao Elias wrote:
> Hello,
> 
>     Not sure I could help with the kind of error you are describing
> but I'm hardware, now starting with Comedi. My two suggestions are
> based in past projects, so they're not solutions but ideas or
> clarifications. Sorry I cannot do more.
> 
>     At the software level, a PCI-PCI bridge is transparent, always
> that its down-stream addresses ranges are properly defined. You could
> check this by running a lspci for the bridge itself, and checking that
> the addresses the bridge is fordwarding are compatible with the ones
> of the card on your #3 bus.
> 
>     Now, this is quite rare on commercial computers, commonly tied to
> custom hardware. I've only seen once, and it was a BIOS version
> problem finally. Once located, we had the OS to update at boot time
> the address set-up and, for later HW version of the embedded board,
> replaced the BIOS code.
> 
>    A more common problem is the INT assignmet. Classic Int lines are
> parallel to the PCI bus (non-MSI Ints) and not subjected to PCI strict
> timing.
> 
>    I'd also a similar problem here in another hardware design because
> the int assignments (a INTA# line is related to a device number or
> slot on the board) expected by the int controller wasn't the
> recommended by the PCI-PCI spec. Most BIOSes use the recommendation as
> reference and hence the mess.  The only solution was to rewire the int
> lines for the slots affected. 
> 
>    This condition can be checked on the hardware as well but it's
> tricky.
> 
>    So I do hope this will light up a little. I cannot think on any
> other hardware reason for this behaviour. I grant the delays of the
> board are properly designed, of course.
> 
>    Good luck.
> 
>              Angel
> 
>     
> 
> Michael R. Head wrote: 
> > On Wed, 2006-01-04 at 16:59 +0000, steve.sharples_at_nottingham.ac.uk
> > wrote:
> >   
> > > Hi there,
> > >     
> > 
> >   
> > > So the short answer is I don't really know. My guesses (more like
> > > wild shots in the dark) are...
> > > 
> > > - certain voltages on your extra PCI bus are not being supplied (5V or
> > >   3.3V) or are set to the wrong voltage, this may be causing the PCI230
> > >   card to go a bit mad (PCI230_INT_ADC held up high by something).
> > > 
> > > - propagation delays along the path of the interrupts is causing several
> > >   versions of the code to be run at the same time. I gather there are ways
> > >   of fixing this, I have no experience of it.
> > >     
> > 
> > This is my guess. I have another (externally housed) bridged bus that is
> > attached via a PCI card and I get the same result when the card is on
> > any of the busses (there are 4) attached to that bridge. I suspect that
> > since I get the same result on both bridges, they are both acting
> > "properly".
> > 
> > 
> >   
> > > Practical solutions if we can't find the cause of this and can't fix it:
> > > plug your PCI230 card into your main bus; buy an "industrial PC" with lots
> > > of PCI slots.
> > >     
> > 
> > I believe what I have is such a beast. The extra PCI (total of 12) slots
> > are provided by the bridge. I don't have the option to use the main bus.
> > In fact, the card must actually be housed on the external bus.
> > 
> > 
> >   
> > > Sorry there's not much more I can suggest. Anybody else out there had any
> > > similar problems/got any sensible solutions?
> > >     
> > 
> > Thanks for the help. I'm also poking the kernel mailing list about PCI
> > bridges in general...
> > 
> >   
> > > Cheers,
> > > 
> > >    Steve.
> > > 
> > > On Wed, 4 Jan 2006, Michael R. Head wrote:
> > > 
> > >     
> > > > Hello, I'm having some issues with my amplc_pci230 card. I have a 4U box
> > > > here that has a PCI bus (#2) with a Pericom Semiconductor PCI to PCI
> > > > bridge to another PCI bus (#3). When my PCI230 card is on bus #2, it
> > > > functions just fine with comedi (comedi_test runs and appears to
> > > > complete successfully). When I shut down and plug the card into a slot
> > > > on bus #3, I get nonstop messages in /var/log/messages (this is a RHEL 3
> > > > box)  once the driver is loaded.
> > > > 
> > > > kernel: comedi0: amplc_pci230: FIFO overrun
> > > > ...
> > > > 
> > > > Any hints or clues? Right now, it's the only thing plugged into any of
> > > > the PCI slots on the motherboard.
> > > > 
> > > > mike
> > > > 
> > > > --
> > > > Michael R. Head <burner_at_suppressingfire.org>
> > > > GPG: http://www.suppressingfire.org/~burner/gpg.key.txt [0x4C9DA1D0]
> > > > 
> > > >       
> > > This message has been checked for viruses but the contents of an attachment
> > > may still contain software viruses, which could damage your computer system:
> > > you are advised to perform your own checks. Email communications with the
> > > University of Nottingham may be monitored as permitted by UK legislation.
> > > 
> > > 
> > > _______________________________________________
> > > comedi mailing list
> > > comedi_at_comedi.org
> > > https://cvs.comedi.org/cgi-bin/mailman/listinfo/comedi
> > > 
> > >     
> 
-- 
Michael R. Head <burner_at_suppressingfire.org>
GPG: http://www.suppressingfire.org/~burner/gpg.key.txt [0x4C9DA1D0]