Just realized that the data I attached was for a 2.5.54
kernel with my patch to register both cpci buses. Here
is the same output for a normal 2.5.54 kernel.
I also added my dmesg.
--rustyl
From: "Rusty Lynch" <rusty@linux.co.intel.com>
> 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
>
-
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/
This archive was generated by hypermail 2b29 : Wed Jan 15 2003 - 22:00:25 EST