On Sunday, April 15, 2012, Rafael J. Wysocki wrote:

On Sunday, April 15, 2012, Mikko Vinni wrote:

quoted

From: Rafael J. Wysocki:

quoted

quoted

 > Please change that dev_dbg() in pci_restore_state() into dev_info()
 > and see how many times it gets printed with the commit applied (not 

reverted).

quoted

 I ran the dmesg through "uniq -c" and it looks like this:

       1 ACPI: Low-level resume complete
       1 PM: Restoring platform NVS memory
       1 Enabling non-boot CPUs ...
       1 Booting Node 0 Processor 1 APIC 0x1
       1 CPU1 is up
       1 ACPI: Waking up from system sleep state S3
      10 pcieport 0000:00:02.0: restoring config space at offset 0x7 (was 

0x20005151, writing 0x5151)

Well, yeah.  So the commit you bisected it to is total and utter crap.
Most importantly, it retries the writes for all of the dwords in the 
device's
config space _including_ the status register (which by definition need not be
the same as the written value).

I wonder if the appended patch helps?

It does. It seems there is a change only in the devices that refuse to wake up;
somehow writing too many times to them affects the rest of the machine.
So, for this machine your patch fixes the problem of the touchpad not working.

Good, thanks for the confirmation. :-)

quoted

The write is now attempted (at most) 11 times, as shown below. Probably not
a huge deal.

      1 ACPI: Waking up from system sleep state S3
     11 pcieport 0000:00:02.0: restoring config space at offset 0x1c (was 0x20005151, writing 0x5151)

Well, here you see that the PCI Express port is refusing to accept a new BAR value.
It seems not to be operational and this probably is the reason why the device below
the port don't respond later.

I'm not sure why that happens, though.

OK, I know.  There simply are fewer BARs for bridges (and PCIe ports)
and here we're attempting to overwrite the secondary status register.  Sigh.

Well, I guess we should only retry the writes to BARs for Type 0 headers.

Thanks,
Rafael