On Saturday 31 January 2009, Parag Warudkar wrote:

On Fri, 30 Jan 2009, Linus Torvalds wrote:

quoted

Because we obviously have two people who say that their tg3 suspend/resume 
works fine, so the tg3 driver is obviously not _totally_ broken. So I'm 
wondering if there is something funny in between the CPU and the tg3, like 
a hotplug bridge that needs magic to wake up properly.

Because clearly the PCI config space addresses are working fine, but the 
thing is, while PCI config space accesses are routed by the device number 
(and the bridges notion of secondary bridging), the PCI memory space 
routing is based on address. So a PCI bridge can easily get one right (in 
fact, it's really hard to get config space accesses wrong without the 
bridges being _totally_ screwed up), while not routing the other at all.

So just do that "lspci -vvxxx" for the whole box, before and after, and 
send us the "before" and the "diff -u before after" thing, and maybe that 
shows something interesting. Because some bridge chip being confused would 
also explain why a total re-init of the whole tg3 chip by a driver unload 
and reload doesn't seem to help.

Totally worth having this problem from a "getting an opportunity to 
understand" standpoint. This confirms my long standing suspicion that bugs 
in Linux kernel are merely a handiwork of few clever people to get more 
people to understand and contribute :)

Any how  here is the pre-suspend lspci -vvxxx output followed by diff -u -

[--snip--]

I think this is what we're looking for:

and the PCIe port driver may be at fault.

Can you try to remove the pci_save_state(dev) from pcie_port_suspend_late()
and see if that helps?

Rafael