Messages in this thread | | | From | (Eric W. Biederman) | Subject | Re: SATA resume slowness, e1000 MSI warning | Date | Wed, 07 Mar 2007 23:58:22 -0700 |
| |
Andrew Morton <akpm@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
- 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/
| |