[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

problem with PCI add-in cards with a PCI2PCI bridge on it




PCI experts,

I have found a problem with PCI add-in cards which have a PCI2PCI bridge
(Intel 21150 is used)on it.

The problem can be stated as follows :
 
- We have a PCI add-in card which runs at 33 MHz /32 bit
- This card has a PCI2PCI bridge : the Intel chip 21150 is used
- The card runs on Intel and Sun platforms (NT and Solaris 2.6)
- There are 3 bus masters on the secondary PCI bus. One of them is the
PCI2PCI bridge itself (of course).
- For the other 2 bus masters the data lines 20 and 24 are used as IDSEL
lines (according to the PCI spec.)
  This corresponds to device 4 and device 8.

- There are 470 Ohm series resistors in the IDSEL as recommended by the
PCI spec to make the capacitive load
  of each chip (nearly) equal to 1 pin per signal.

When the board runs under Solaris, the following can happen :
 
- Solaris generates configuration cycles when the interrupts are
running. This occurs only on some machines (not all)
  and seems to be some kind of "housekeeping" functions of Solaris.

- During the configuration cycles Solaris reads out the device- and
vendor-ID of the device which requests an interrupt.

- Sometimes I noticed with the help of a PCI logic analyzer that the
wrong device ID has been read out. 
  When this happens the Solaris will crash with kernel panic.

The reason for this is that due to the series resistors in the IDSEL
(recommended by the PCI spec.) a timing problem 
is produced. The PCI spec. states that this CAN be solved by inserting
NOPs for the config cycles. But this is NOT
done by the 21150 chip.

If a Config cycle is generated AND there was another bus master active 1
or 2 clocks before the config cycle then the IDSEL
lines are not stable and the config cycle will return with corrupted IDs
which produces the kernel panic.

I spent now 3 weeks to find this effect.

After replacing the 470 series resistors with 0-Ohm values the system
works perfectly. Of course the PCI spec. on the secondary
bus is now violated because some chips have 2 loads for some data lines
instead of 1.

For me the PCI spec. is not clear. It says the config cycles CAN be made
slower, but the PCI2PCI bridge chips are NOT doing this.
It would have been better if the spec. says config cycles MUST be made
slower.
How about a 66 MHz bus ? In this case the situation would be much worse.

Perhaps somebody has made a similar experience and can send some
comments.

/Michael Lange, Hardware design engineer, DVS, Germany