From: "Scott Murray" <scottm@somanetworks.com>
> On Wed, 8 Jan 2003, Rusty Lynch wrote:
> 
> > From: "Yang, Harold" <harold.yang@intel.com>
> > > 
> > > Hi, Scott & Greg:
> > > 
> > > I have applied the cpci patch for kernel 2.4.19, and test it
> > > thoroughly on ZT5084 platform. Two bugs are found:
> > > 
> > > 1. In my ZT5084, the driver can't correctly detect the cPCI
> > >    Hot Swap bridge device. Two DEC21154 exist on ZT5084,
> > >    however, only one is the right bridge. The driver can't 
> > >    distinguish them correctly.
> > 
> > I just got a couple of ZT5541 peripheral master boards
> > and can finally see what happens when an enumerable board
> > is plugged into a ZT5084 chassis using a ZT5550 system master 
> > board.
> > 
> > As of yet I have only tried a 2.5.54 kernel, but I see the 
> > same problems along with some other wacky behavior that I 
> > am trying to isolate.
> > 
> > Now about the multiple DEC21154 devices ==>  on my ZT5550 that
> > is in system master mode, the first DEC21154 device is a bridge
> > for the slots to the left of the system slots, and the second
> > DEC21154 is a bridge for the right of the system slots.
> 
> Okay, that's what I originally wanted to determine from the lspci
> output I requested when Harold mentioned this problem at the end
> of November.
> 

I am attaching output for:
1. lspci -vvv
2. cat /proc/ioports
3. cat /proc/iomem

For a ZT5550 running as system master in the second system slot
of a ZT5084 chassis that has two ZT5541 (peripherial master) boards
plugged in (one to the left of the sytem slots and the other to 
the right of the system slots.)

> > So if I boot the system master (I'll talk about problems with 
> > hotswaping in another email) with a peripheral board plugged
> > into one of the slots on the right of the master using the
> > current 2.5.54 kernel then I run into problems the first time 
> > cpci_hotplug_core.c::check_slots() runs because it only looks
> > at the first bus when trying to find the card that caused the
> > #ENUM.
> 
> I assume by problems you mean that the cPCI event thread gets
> shut down (which is what I'd expect), or do you mean something more 
> severe?
> 

The event thread shutsdown with the 
"cannot find ENUM# source, shutting down" error message.  That's all.

> > The following patch will register each of the cpci busses instead
> > of just the first one detected.
> 
> Your patch is better than Harold's hack, but I'm probably going to
> try and think of some other alternative, as the while loop idea
> doesn't handle the possibility of someone having a 21154 bridge
> on a PMC card or actually as a bridge on a cPCI card.  The original
> code doesn't really handle that possiblity either, so I'll need to
> cook up something better anyway.
> 
> > NOTE: I'm a little worried that the right way to do this is to
> >       properly initialize the RSS bits, or at least see how the
> >       chassis is configured via the RSS bits to determine which 
> >       cpci bus to register.  The ZT5084 doesn't have near as many
> >       configurations as newer designs like the ZT5088.
> [snip]
> 
> I will investigate reading the active bus(es) out of the HC, as I've
> gotten the documentation for the HC from Performance Tech, I was just
> too busy before Christmas to dig into it then.  I'll try and have
> something that attempts to handle your ZT5084 chassis done in a few
> days.
> 
> Scott