Messages in this thread | | | Date | Mon, 21 Apr 2008 22:05:02 -0600 | From | Alex Chiang <> | Subject | Re: 2.6.25-rc8-mm1 panic in rpaphp_register_slot() |
| |
* Benjamin Herrenschmidt <benh@kernel.crashing.org>: > > On Sat, 2008-04-19 at 00:38 -0600, Alex Chiang wrote: > > So I'm not sure how much we can use of your slot infrastructure, I'll > > have > > > to look, I suspect it can cover some cases but not all of them. > > > > *poke* > > > > Any update on this? > > > > Anything I can do to help? > > Not yet no. I've looked a bit, but ran out of time, I'll look more this > week-end or next week. I'm also trying to figure out who in IBM is > responsible for that hotplug stuff so they can get involved too. > > BTW. How would you do if the answer was we simply can't declare hotplug > "slots" ? ie. if I end up finding out (which is what I think will > happen) that there is simply no way for us to know in advance any > concept of "slot" with a devfn for hotplug ?
Hm, I may be getting lost in the twisty maze of pseries, but I guess I don't really understand this statement.
Today, before calling rpaphp_register_slot, we first call rpaphp_enable_slot. rpaphp_enable_slot makes a call to pcibios_find_pci_bus which must succeed before we ever try to register the slot.
So if there is a pci_bus, then it must have a ->self, which means it has a ->devfn. Right?
Are you saying that it is not accurate to use this pci_bus->self->devfn to keep track of slots?
> Basically, when doing hotplug, the hypervisor sends us new bits of > device-tree with things potentially ranging from host bridges, P2P > bridges to devices, but I'm not certain at this stage we can know in > advance where they'll hook up (in fact, for PHBs, we can't for sure) and > thus even if we end up supporting hotplug of actual slots, we don't even > know in advance the devfn where devices will appear. It's all hidden > from us by the hypervisor. > > How would that fit in your infrastructure ? Can we just disable usage of > your slots abstraction in our case ?
I suppose you could just pass in 0 as slot_nr/devfn. That is what my fixup patch did if it couldn't find a pci_bus->self. The result would be that for a given pci_bus, you would only see the first "slot" with this 0 slot_nr appear in sysfs, and it would have whatever name originally associated with your dn.
I think if I were to understand more about this issue, we could figure out a better solution...
thanks,
/ac
| |