Welcome, Guest Login

Support Center

12 or more Telephony cards having problem running on 13slot PCI Expansion

Last Updated: Oct 25, 2016 10:35AM PDT
Product: 13slot and 7slot PCI expansion
Computer: Desktop / Server / Workstatin
OS: Any

12 or more Telephony cards having problem running on 13slot PCI Expansion


Problem Synopsis:

The pictures below are an illustrations of two flavors of Magma expansion units running Telephony PCI Cards.
* Two 7 PCI slot Chassis units populated unit with Telephony PCI Cards. Each Chassis can accommodate 7 PCI cards and run them without problem.
* 13slot Chassis,  populated  it with 13 PCI Telephony PCI Card, problem occurs: Only 11 or 12 are working and sometimes you can only run 8 Telephony PCI card.
The error: Unable to start the card
NOTE: The 13 slot chassis is not defective
1. I need a better understanding as to why the FIGURE A works and FIGURE B does not.  Is it related to IO assignment? Or is it BIOS limitation? What could be the main contributing factor?





Inputs from our Engineering Team:


Engineer1 Response:

Do you have the power requirements on these cards? 5, 3.3., 12volts, etc? My guess is it can be a loading issue. I would be interested in resource allocation too. When 8 work, does adding the 9th cause an error code on the 9nth card, does the system not boot, is the 9th card just not seen.
A long while back to get 10 dialogic cards working we had to add a load on the the 13th slot, we added an Ethernet card and this enabled the last 3 to be properly seen and powered, and enumerated.

Engineer2 Response:

If this has not come up already, my gut feeling is that it has to do with latency.  The system that you describe that works only has seven telephony cards hanging off one bridge; whereas the one that doesn't work has more.  I am not that familiar with the telephony cards, but it seems like this would be a real time data acquisition application similar to Digi which also has latency requirements.  Compatibility Test Group has confirmed my suspicion that Digi would not work in a 13 slot as effectively.  In fact they (Digi) prefers that with a 13-slot, the Digi cards hang off the first (upper) bridge on the chassis and not the second.  I would say there is a good chance these telephony cards work in a similar manner given this is a similar application: gathering real time audio information.

I think the answer is simply, don't attempt configuration B.  You are most likely bottle-necking the data and seeing latency in the system.

Engineer3 response:

The main difference I see is in the PCI bus architecture.  In figure A we are two bridges deep, while in Figure B we are 3 bridges deep.  Error code 10 (device failed to start) means that the device’s driver has detected a problem in its start routine and returned an error.  It is after Windows has assigned PCI IO and address space to the device so it is typically not an indication of a resource issue.  So I would suspect either Engineer 1's theory about loading is causing the cards in the third bridge to respond incorrectly or Kip’s theory that the third bridge is causing a latency that breaks an expected threshold is true.  A less likely, but still plausible cause would be an invalid enumeration, this usually causes and error code 31, but the behavior can be undefined and it is possible that the error is not’t being detected until later in the process.


Engineer3 response


If it is the IO issue, then it is because the PCI specification requires IO to be allocated on 4K boundaries, this would explain variation among different platforms, but in this case you should see an error code 12 (not enough resources).  Unfortunately if it is an IO issue then the problem gets worse in PCI express as each slot is logically a PCI bridge and with only 16 available IO windows there is no way you will ever be able to support 13 cards using IO.


I agree with Engineer2 that this is a latency issue.  Telephony cards are very sensitive to real time data transfers.  Delays are not acceptable…  An analyzer would likely prove this theory.

would hope that native PCI-E cards would not use IO as well (they should be memory mapped).  IO is supposed to be phased away, it is only used to support backwards compatibility, however I have seen PCI manufacturers use a PCI-E to PCI-X bridge to implement their PCI-E native cards. 

Contact Us

  • Email Us
  • Support Resources
      Download Center
seconds ago
a minute ago
minutes ago
an hour ago
hours ago
a day ago
days ago
Invalid characters found