It's not always easy to resolve problems associated with a PCI expansion chassis, and a limited number of developers have need of such an implementation. Although cards plugged into the expansion chassis should, in theory, experience only minimal effect on overall transaction timing, the reality is that there are subtle design issues introduced by the architecture itself that must be addressed.
First, additional propagation delay for the sub-bridge levels is introduced by the expansion chassis. A typical implementation is two sub-bridge levels deep, requiring extra PCI clock cycles for each level. Further delays are experienced if the cards themselves possess additional PCI sub-bridges. These delays are a combination of posting operations and actual propagation delays introduced by the hardware itself.
When cards are plugged into a host expansion slot, hardware exists in the host that provides information about which device slot is interrupting. On the other hand, all interrupts from an expansion chassis are funneled into a single interrupt slot line. This concept is known as "interrupt sharing." With interrupt sharing, the driver needs to ensure it does not depend solely on the hardware slot indicator for interrupt association. Instead, a well-behaved driver should follow the rules set forth in Designing Cards and Drivers for Power Macintosh Computers:
- Poll its own hardware to determine whether it is to provide service or not.
- If it is not to provide service, quickly return with
KIsrIsNotComplete. - If it is, service the routine then return with
KIsrIsComplete.
Extra time should be allowed for the hardware to properly reset interrupt flags that have been asserted, because latencies could make the interrupt look as though it is still asserted for a brief time. This is due to the accumulative full-turn delays of propagating down to the source hardware itself, then back to the host motherboard. The condition may cause the handler to be re-invoked after returning to its caller; however, when the handler regains control, the hardware interrupt has been cleared and the handler will return a KIsrIsNotComplete status. This ultimately will cause a spurious interrupt because no proper handler will not be found. The complication in all this is that it is not easy to tell when a device is plugged into a local bus versus an expansion chassis (and sharing interrupts). The device tree could be analyzed to make such a determination, although a good general practice for a handler might be to clear the interrupt before attempting to read the hardware back to ensure it has actually been cleared prior to returning to the caller.
Attempting to make a hypothetical determination as to which cards will work together and in what slot order is extremely difficult due to potential card interaction. This is due in part to loading characteristics and probing order as the cards are initialized. The bottom line is that any given configuration should be emperically tested to see if any problems arise. If problems are encountered, try switching the order of the cards in the slots. At the time of this writing, no known expansion chassis problems are being encountered in OpenFirmware, as opposed to the more rigorous thrashing that the cards receive once the system is booted. This could be because of relative slow access rates of OpenFirmware. More importantly, this emphasizes that these problems tend to be dynamic-speed related.
Lastly, spurious interrupts are symptomatic of the problems associated with expansion chassis operation, so be on the lookout for them as an indication of a potential interrupt timing problem.
Acrobat version of this Note (26K).