> 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.
> 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 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
-- Scott Murray SOMA Networks, Inc. Toronto, Ontario e-mail: scottm@somanetworks.com
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/