Andrew Morton <akpm at linux-foundation.org> writes:
>
> That's:
>
> pci_restore_pcix_state(dev);
> pci_restore_msi_state(dev);
> WARN_ON(!hlist_empty(&dev->saved_cap_space));
>
> return 0;
Hmm. Either I am confused of I just found an unanticipated leak.
pci_restore_msi_state should be out of the picture as we don't yet
have ppc msi support and I don't think the g5 generation hardware
supported it either.
The only case I can see which might trigger this is if we saved
pci-X state and then didn't restore it because we could not find
the capability on restore.
Any chance you could walk that list and find the cap_nr of the remaining
element?
Something like:
{
struct pci_cap_saved_state *tmp;
struct hlist_node *pos;
hlist_for_each_entry(tmp, pos, &pci_dev->saved_cap_space, next)
printk(KERN_INFO "saved_cap: 0x%02x\n", tmp->cap_nr);
}
Until I get the best scenario I can come up with is a tg3 hardware bug
that doesn't renable the pci-X capability after a restore of power state.
Getting that cap_nr will at least allow me to be certain if I am dealing
with msi, pci-X or pci-e.
Unanticipated bugs aren't supposed to be this easy to find!
Eric
