[PATCH] Workaround for a PCI restoring bug

[PATCH] Workaround for a PCI restoring bug

[Lukas Hejtmanek]

[-- Attachment #1: Type: text/plain, Size: 348 bytes --]

Hello,

as of 2.6.21-git16, the bugs related to restoring PCI are still present. The
save pci function reads only -1 from the PCI config space and when restoring,
it messes up totaly most PCI devices. The attached patch is workaround only
until proper fix is found and included. Could it be included into the mainline
for now?

-- 
Lukáš Hejtmánek

[-- Attachment #2: pci.patch --]
[-- Type: text/x-diff, Size: 488 bytes --]

--- drivers/pci/pci.c.orig	2006-07-15 23:53:08.000000000 +0200
+++ drivers/pci/pci.c	2006-07-21 00:51:07.000000000 +0200
@@ -477,7 +477,7 @@
 	 */
 	for (i = 15; i >= 0; i--) {
 		pci_read_config_dword(dev, i * 4, &val);
-		if (val != dev->saved_config_space[i]) {
+		if (val != dev->saved_config_space[i] && dev->saved_config_space[i] != 0xffffffff) {
 			printk(KERN_DEBUG "PM: Writing back config space on "
 				"device %s at offset %x (was %x, writing %x)\n",
 				pci_name(dev), i,

Re: [PATCH] Workaround for a PCI restoring bug

[Robert Hancock]

Lukas Hejtmanek wrote:
> Hello,
> 
> as of 2.6.21-git16, the bugs related to restoring PCI are still present. The
> save pci function reads only -1 from the PCI config space and when restoring,
> it messes up totaly most PCI devices. The attached patch is workaround only
> until proper fix is found and included. Could it be included into the mainline
> for now?

It's not really a fix, that value might be legitimately supposed to be 
in the config space. Sounds like some driver is disabling the device 
before saving the state or something..

-- 
Robert Hancock      Saskatoon, SK, Canada
To email, remove "nospam" from hancockr@nospamshaw.ca
Home Page: http://www.roberthancock.com/

Re: [PATCH] Workaround for a PCI restoring bug

[Andrew Morton]

On Sat, 12 May 2007 22:12:37 +0200 Lukas Hejtmanek <xhejtman@ics.muni.cz> wrote:

> as of 2.6.21-git16, the bugs related to restoring PCI are still present. The
> save pci function reads only -1 from the PCI config space and when restoring,
> it messes up totaly most PCI devices. The attached patch is workaround only
> until proper fix is found and included. Could it be included into the mainline
> for now?
> 
> -- 
> Lukáš Hejtmánek
> 
> 
> [pci.patch  text/x-diff (489B)]
> --- drivers/pci/pci.c.orig	2006-07-15 23:53:08.000000000 +0200
> +++ drivers/pci/pci.c	2006-07-21 00:51:07.000000000 +0200
> @@ -477,7 +477,7 @@
>  	 */
>  	for (i = 15; i >= 0; i--) {
>  		pci_read_config_dword(dev, i * 4, &val);
> -		if (val != dev->saved_config_space[i]) {
> +		if (val != dev->saved_config_space[i] && dev->saved_config_space[i] != 0xffffffff) {
>  			printk(KERN_DEBUG "PM: Writing back config space on "
>  				"device %s at offset %x (was %x, writing %x)\n",
>  				pci_name(dev), i,

This change might indeed be a suitable workaround for some busted hardware,
but we'd need to know quite a bit about the problem before we could merge
anything like this

So, again, please send a full bug report.  An emailed one would be OK in
this case.

Thanks.

Re: [PATCH] Workaround for a PCI restoring bug

[Lukas Hejtmanek]

Hello,

On Sat, May 12, 2007 at 11:47:43PM -0700, Andrew Morton wrote:
> This change might indeed be a suitable workaround for some busted hardware,
> but we'd need to know quite a bit about the problem before we could merge
> anything like this
> 
> So, again, please send a full bug report.  An emailed one would be OK in
> this case.

I've reported this some time ago. I have been recommended to use -mm tree
instead of the mainline.

I've also noticed that someone pointed out that for some reason, PCI config
space is saved twice, the first is OK, the second saves already disabled
devices. Unfortunately, I'm unable to find this discussion in LKM.

This is not a regression, this problem has been always present in the kernel.

These devices are not saved correctly:
01:01.0 CardBus bridge: Ricoh Co Ltd RL5c476 II (rev b3)
01:01.1 FireWire (IEEE 1394): Ricoh Co Ltd R5C552 IEEE 1394 Controller (rev 08)
01:01.2 Generic system peripheral [0805]: Ricoh Co Ltd R5C822 SD/SDIO/MMC/MS/MSPro Host Adapter (rev 17)
01:01.3 System peripheral: Ricoh Co Ltd R5C592 Memory Stick Bus Host Adapter (rev 08)
01:01.4 System peripheral: Ricoh Co Ltd xD-Picture Card Controller (rev 03)

A bit strange, the devices:
01:00.0 Ethernet controller 
01:02.0 Network controller 
seem to be OK. These two devices are behind the same PCI bridge as the devices
above.

The log contains the following and similar messages for all these devices:
May 12 22:07:13 anubis kernel: PM: Writing back config space on device
0000:01:01.0 at offset f (was 800100, writing ffffffff)
May 12 22:07:13 anubis kernel: PM: Writing back config space on device
0000:01:01.0 at offset e (was d4fc, writing ffffffff)
May 12 22:07:13 anubis kernel: PM: Writing back config space on device
0000:01:01.0 at offset d (was d400, writing ffffffff)
May 12 22:07:13 anubis kernel: PM: Writing back config space on device
0000:01:01.0 at offset c (was 0, writing ffffffff)
May 12 22:07:13 anubis kernel: PM: Writing back config space on device
0000:01:01.0 at offset b (was 0, writing ffffffff)
May 12 22:07:13 anubis kernel: PM: Writing back config space on device
0000:01:01.0 at offset a (was 3bfff000, writing ffffffff)
May 12 22:07:13 anubis kernel: PM: Writing back config space on device
0000:01:01.0 at offset 9 (was 0, writing ffffffff)
May 12 22:07:13 anubis kernel: PM: Writing back config space on device
0000:01:01.0 at offset 8 (was 0, writing ffffffff)
May 12 22:07:13 anubis kernel: PM: Writing back config space on device
0000:01:01.0 at offset 7 (was 0, writing ffffffff)
May 12 22:07:13 anubis kernel: PM: Writing back config space on device
0000:01:01.0 at offset 6 (was 40020201, writing ffffffff)
May 12 22:07:13 anubis kernel: PM: Writing back config space on device
0000:01:01.0 at offset 5 (was 20000dc, writing ffffffff)
May 12 22:07:13 anubis kernel: PM: Writing back config space on device
0000:01:01.0 at offset 4 (was 0, writing ffffffff)
May 12 22:07:13 anubis kernel: PM: Writing back config space on device
0000:01:01.0 at offset 3 (was 822000, writing ffffffff)
May 12 22:07:13 anubis kernel: PM: Writing back config space on device
0000:01:01.0 at offset 2 (was 60700b3, writing ffffffff)
May 12 22:07:13 anubis kernel: PM: Writing back config space on device
0000:01:01.0 at offset 1 (was 2100107, writing ffffffff)
May 12 22:07:13 anubis kernel: PM: Writing back config space on device
0000:01:01.0 at offset 0 (was 4761180, writing ffffffff)


-- 
Lukáš Hejtmánek

Re: [PATCH] Workaround for a PCI restoring bug

[Andrew Morton]

On Sun, 13 May 2007 10:57:18 +0200 Lukas Hejtmanek <xhejtman@ics.muni.cz> wrote:

> Hello,
> 
> On Sat, May 12, 2007 at 11:47:43PM -0700, Andrew Morton wrote:
> > This change might indeed be a suitable workaround for some busted hardware,
> > but we'd need to know quite a bit about the problem before we could merge
> > anything like this
> > 
> > So, again, please send a full bug report.  An emailed one would be OK in
> > this case.
> 
> I've reported this some time ago. I have been recommended to use -mm tree
> instead of the mainline.
> 
> I've also noticed that someone pointed out that for some reason, PCI config
> space is saved twice, the first is OK, the second saves already disabled
> devices. Unfortunately, I'm unable to find this discussion in LKM.

Yeah, that sounds risky.

Can you put a dump_stack() call into the PCI saving function?  That way
we'll see what the two call paths are.


> This is not a regression, this problem has been always present in the kernel.
> 
> These devices are not saved correctly:
> 01:01.0 CardBus bridge: Ricoh Co Ltd RL5c476 II (rev b3)
> 01:01.1 FireWire (IEEE 1394): Ricoh Co Ltd R5C552 IEEE 1394 Controller (rev 08)
> 01:01.2 Generic system peripheral [0805]: Ricoh Co Ltd R5C822 SD/SDIO/MMC/MS/MSPro Host Adapter (rev 17)
> 01:01.3 System peripheral: Ricoh Co Ltd R5C592 Memory Stick Bus Host Adapter (rev 08)
> 01:01.4 System peripheral: Ricoh Co Ltd xD-Picture Card Controller (rev 03)
> 
> A bit strange, the devices:
> 01:00.0 Ethernet controller 
> 01:02.0 Network controller 
> seem to be OK. These two devices are behind the same PCI bridge as the devices
> above.
> 
> The log contains the following and similar messages for all these devices:
> May 12 22:07:13 anubis kernel: PM: Writing back config space on device
> 0000:01:01.0 at offset f (was 800100, writing ffffffff)
> May 12 22:07:13 anubis kernel: PM: Writing back config space on device
> 0000:01:01.0 at offset e (was d4fc, writing ffffffff)
> May 12 22:07:13 anubis kernel: PM: Writing back config space on device
> 0000:01:01.0 at offset d (was d400, writing ffffffff)
> May 12 22:07:13 anubis kernel: PM: Writing back config space on device
> 0000:01:01.0 at offset c (was 0, writing ffffffff)
> May 12 22:07:13 anubis kernel: PM: Writing back config space on device
> 0000:01:01.0 at offset b (was 0, writing ffffffff)
> May 12 22:07:13 anubis kernel: PM: Writing back config space on device
> 0000:01:01.0 at offset a (was 3bfff000, writing ffffffff)
> May 12 22:07:13 anubis kernel: PM: Writing back config space on device
> 0000:01:01.0 at offset 9 (was 0, writing ffffffff)
> May 12 22:07:13 anubis kernel: PM: Writing back config space on device
> 0000:01:01.0 at offset 8 (was 0, writing ffffffff)
> May 12 22:07:13 anubis kernel: PM: Writing back config space on device
> 0000:01:01.0 at offset 7 (was 0, writing ffffffff)
> May 12 22:07:13 anubis kernel: PM: Writing back config space on device
> 0000:01:01.0 at offset 6 (was 40020201, writing ffffffff)
> May 12 22:07:13 anubis kernel: PM: Writing back config space on device
> 0000:01:01.0 at offset 5 (was 20000dc, writing ffffffff)
> May 12 22:07:13 anubis kernel: PM: Writing back config space on device
> 0000:01:01.0 at offset 4 (was 0, writing ffffffff)
> May 12 22:07:13 anubis kernel: PM: Writing back config space on device
> 0000:01:01.0 at offset 3 (was 822000, writing ffffffff)
> May 12 22:07:13 anubis kernel: PM: Writing back config space on device
> 0000:01:01.0 at offset 2 (was 60700b3, writing ffffffff)
> May 12 22:07:13 anubis kernel: PM: Writing back config space on device
> 0000:01:01.0 at offset 1 (was 2100107, writing ffffffff)
> May 12 22:07:13 anubis kernel: PM: Writing back config space on device
> 0000:01:01.0 at offset 0 (was 4761180, writing ffffffff)

It does seem wrong.

Re: [PATCH] Workaround for a PCI restoring bug

[Lukas Hejtmanek]

On Sun, May 13, 2007 at 02:11:19AM -0700, Andrew Morton wrote:
> > I've also noticed that someone pointed out that for some reason, PCI config
> > space is saved twice, the first is OK, the second saves already disabled
> > devices. Unfortunately, I'm unable to find this discussion in LKM.
> 
> Yeah, that sounds risky.
> 
> Can you put a dump_stack() call into the PCI saving function?  That way
> we'll see what the two call paths are.

I did it, but it seems to be OK. PCI saves only once each device. So the issue
was not related to this.

So what should I try next?

-- 
Lukáš Hejtmánek

Re: [PATCH] Workaround for a PCI restoring bug

[Andrew Morton]

On Sun, 13 May 2007 14:21:14 +0200 Lukas Hejtmanek <xhejtman@ics.muni.cz> wrote:

> On Sun, May 13, 2007 at 02:11:19AM -0700, Andrew Morton wrote:
> > > I've also noticed that someone pointed out that for some reason, PCI config
> > > space is saved twice, the first is OK, the second saves already disabled
> > > devices. Unfortunately, I'm unable to find this discussion in LKM.
> > 
> > Yeah, that sounds risky.
> > 
> > Can you put a dump_stack() call into the PCI saving function?  That way
> > we'll see what the two call paths are.
> 
> I did it, but it seems to be OK. PCI saves only once each device. So the issue
> was not related to this.
> 
> So what should I try next?
> 

So.... we don't know 0xffffffff's are getting into dev->saved_config_space[]?


Possibly we're saving the device's state when it is already partway or
fully through the suspend process, dunno.

What if you were to put code into pci_save_state() to detect when it reads
an oxffffffff?  Do a dump_stack() and print pci_dev->current_state and
->enable_cnt and various other things in there?


Or maybe we've done something in the wrong order which has affected our
ability to access this device.  Print the order in which devices are
getting suspended, let's see if we're taking down the bridge(s) in the
correct order.

Re: [PATCH] Workaround for a PCI restoring bug

[Lukas Hejtmanek]

On Sun, May 13, 2007 at 11:59:47AM -0700, Andrew Morton wrote:
> Possibly we're saving the device's state when it is already partway or
> fully through the suspend process, dunno.
> 
> What if you were to put code into pci_save_state() to detect when it reads
> an oxffffffff?  Do a dump_stack() and print pci_dev->current_state and
> ->enable_cnt and various other things in there?

The PCI topology looks like this:
-[0000:00]-+-00.0
           +-01.0-[0000:03]--
           +-02.0
           +-02.1
           +-1b.0
           +-1d.0
           +-1d.1
           +-1d.2
           +-1d.3
           +-1d.7
           +-1e.0-[0000:01-02]--+-00.0
           |                    +-01.0
           |                    +-01.1
           |                    +-01.2
           |                    +-01.3
           |                    +-01.4
           |                    \-02.0
           +-1f.0
           +-1f.1
           \-1f.3

I've modified the pci.c source in the following way:

pci_save_state:
        int wrong=0;
        /* XXX: 100% dword access ok here? */
        printk(KERN_DEBUG "PM: saving PCI state %s\n", pci_name(dev));
        printk(KERN_DEBUG "PM: dev state %d\n", dev->current_state);
        printk(KERN_DEBUG "PM: dev enabled? %d\n", atomic_read(&(dev->enable_cnt)));
        dump_stack();
        for (i = 0; i < 16; i++) {
                pci_read_config_dword(dev, i * 4,&dev->saved_config_space[i]);
                if(dev->saved_config_space[i] == 0xffffffff) {
                        wrong++;
                }
        }
        printk(KERN_DEBUG "PM: wrong values count %d\n", wrong);

and pci_restore_state:
        printk(KERN_DEBUG "PM: restoring PCI state %s\n", pci_name(dev));
        printk(KERN_DEBUG "PM: dev state %d\n", dev->current_state);
        printk(KERN_DEBUG "PM: dev enabled? %d\n", atomic_read(&(dev->enable_cnt)));


The dmesg is attached. It looks strange as the devices 0000:01:01.* are in the
same  state in both pci_save and pci_restore but in pci_save, only -1 are read
and in pci_restore the correct values are read. Maybe, it is something ACPI
related - if ACPI suspend is called at the beginning, these particular devices
suspend and their state cannot be properly gained.

I've checked also order of device suspending. It looks correct, the bridge
00:1e.0 is suspended after those devices.

So, what to do next?


PM: saving PCI state 0000:01:02.0
PM: dev state 5
PM: dev enabled? 0
 [<c0201861>] pci_save_state+0x61/0x2b0
 [<c02038be>] pci_device_suspend+0x4e/0x60
 [<c0250258>] suspend_device+0xe8/0x1b0
 [<c021997e>] acpi_hw_clear_gpe_block+0x0/0x32
 [<c01f7072>] kobject_get+0x12/0x20
 [<c02503e1>] device_suspend+0xc1/0x160
 [<c013e8a5>] enter_state+0xa5/0x140
 [<c013ea83>] state_store+0xf3/0x100
 [<c013e990>] state_store+0x0/0x100
 [<c01a91e0>] subsys_attr_store+0x30/0x40
 [<c01a9351>] sysfs_write_file+0xb1/0x110
 [<c016c016>] vfs_write+0xa6/0x140
 [<c01a92a0>] sysfs_write_file+0x0/0x110
 [<c016c5f1>] sys_write+0x41/0x70
 [<c0104068>] syscall_call+0x7/0xb
 [<c0340000>] schedule+0x280/0x630
 =======================
PM: wrong values count 0
PM: saving PCI state 0000:01:01.4
PM: dev state 5
PM: dev enabled? 0
 [<c0201861>] pci_save_state+0x61/0x2b0
 [<c02038be>] pci_device_suspend+0x4e/0x60
 [<c0250258>] suspend_device+0xe8/0x1b0
 [<c021997e>] acpi_hw_clear_gpe_block+0x0/0x32
 [<c01f7072>] kobject_get+0x12/0x20
 [<c02503e1>] device_suspend+0xc1/0x160
 [<c013e8a5>] enter_state+0xa5/0x140
 [<c013ea83>] state_store+0xf3/0x100
 [<c013e990>] state_store+0x0/0x100
 [<c01a91e0>] subsys_attr_store+0x30/0x40
 [<c01a9351>] sysfs_write_file+0xb1/0x110
 [<c016c016>] vfs_write+0xa6/0x140
 [<c01a92a0>] sysfs_write_file+0x0/0x110
 [<c016c5f1>] sys_write+0x41/0x70
 [<c0104068>] syscall_call+0x7/0xb
 [<c0340000>] schedule+0x280/0x630
 =======================
PM: wrong values count 16
PM: saving PCI state 0000:01:01.3
PM: dev state 5
PM: dev enabled? 0
 [<c0201861>] pci_save_state+0x61/0x2b0
 [<c02038be>] pci_device_suspend+0x4e/0x60
 [<c0250258>] suspend_device+0xe8/0x1b0
 [<c021997e>] acpi_hw_clear_gpe_block+0x0/0x32
 [<c01f7072>] kobject_get+0x12/0x20
 [<c02503e1>] device_suspend+0xc1/0x160
 [<c013e8a5>] enter_state+0xa5/0x140
 [<c013ea83>] state_store+0xf3/0x100
 [<c013e990>] state_store+0x0/0x100
 [<c01a91e0>] subsys_attr_store+0x30/0x40
 [<c01a9351>] sysfs_write_file+0xb1/0x110
 [<c016c016>] vfs_write+0xa6/0x140
 [<c01a92a0>] sysfs_write_file+0x0/0x110
 [<c016c5f1>] sys_write+0x41/0x70
 [<c0104068>] syscall_call+0x7/0xb
 [<c0340000>] schedule+0x280/0x630
 =======================
PM: wrong values count 16
PM: saving PCI state 0000:01:01.2
PM: dev state 5
PM: dev enabled? 0
 [<c0201861>] pci_save_state+0x61/0x2b0
 [<c02038be>] pci_device_suspend+0x4e/0x60
 [<c0250258>] suspend_device+0xe8/0x1b0
 [<c021997e>] acpi_hw_clear_gpe_block+0x0/0x32
 [<c01f7072>] kobject_get+0x12/0x20
 [<c02503e1>] device_suspend+0xc1/0x160
 [<c013e8a5>] enter_state+0xa5/0x140
 [<c013ea83>] state_store+0xf3/0x100
 [<c013e990>] state_store+0x0/0x100
 [<c01a91e0>] subsys_attr_store+0x30/0x40
 [<c01a9351>] sysfs_write_file+0xb1/0x110
 [<c016c016>] vfs_write+0xa6/0x140
 [<c01a92a0>] sysfs_write_file+0x0/0x110
 [<c016c5f1>] sys_write+0x41/0x70
 [<c0104068>] syscall_call+0x7/0xb
 [<c0340000>] schedule+0x280/0x630
 =======================
PM: wrong values count 16
PM: saving PCI state 0000:01:01.1
PM: dev state 5
PM: dev enabled? 1
 [<c0201861>] pci_save_state+0x61/0x2b0
 [<c02038be>] pci_device_suspend+0x4e/0x60
 [<c0250258>] suspend_device+0xe8/0x1b0
 [<c021997e>] acpi_hw_clear_gpe_block+0x0/0x32
 [<c01f7072>] kobject_get+0x12/0x20
 [<c02503e1>] device_suspend+0xc1/0x160
 [<c013e8a5>] enter_state+0xa5/0x140
 [<c013ea83>] state_store+0xf3/0x100
 [<c013e990>] state_store+0x0/0x100
 [<c01a91e0>] subsys_attr_store+0x30/0x40
 [<c01a9351>] sysfs_write_file+0xb1/0x110
 [<c016c016>] vfs_write+0xa6/0x140
 [<c01a92a0>] sysfs_write_file+0x0/0x110
 [<c016c5f1>] sys_write+0x41/0x70
 [<c0104068>] syscall_call+0x7/0xb
 [<c0340000>] schedule+0x280/0x630
 =======================
PM: wrong values count 16
PM: saving PCI state 0000:01:01.0
PM: dev state 5
PM: dev enabled? 1
 [<c0201861>] pci_save_state+0x61/0x2b0
 [<c02038be>] pci_device_suspend+0x4e/0x60
 [<c0250258>] suspend_device+0xe8/0x1b0
 [<c021997e>] acpi_hw_clear_gpe_block+0x0/0x32
 [<c01f7072>] kobject_get+0x12/0x20
 [<c02503e1>] device_suspend+0xc1/0x160
 [<c013e8a5>] enter_state+0xa5/0x140
 [<c013ea83>] state_store+0xf3/0x100
 [<c013e990>] state_store+0x0/0x100
 [<c01a91e0>] subsys_attr_store+0x30/0x40
 [<c01a9351>] sysfs_write_file+0xb1/0x110
 [<c016c016>] vfs_write+0xa6/0x140
 [<c01a92a0>] sysfs_write_file+0x0/0x110
 [<c016c5f1>] sys_write+0x41/0x70
 [<c0104068>] syscall_call+0x7/0xb
 [<c0340000>] schedule+0x280/0x630
 =======================
PM: wrong values count 16
PM: saving PCI state 0000:01:00.0
PM: dev state 0
PM: dev enabled? 1
 [<c0201861>] pci_save_state+0x61/0x2b0
 [<c0200733>] pci_find_capability+0x33/0x40
 [<ef848027>] skge_suspend+0x27/0xe0 [skge]
 [<c0203893>] pci_device_suspend+0x23/0x60
 [<c0250258>] suspend_device+0xe8/0x1b0
 [<c021997e>] acpi_hw_clear_gpe_block+0x0/0x32
 [<c01f7072>] kobject_get+0x12/0x20
 [<c02503e1>] device_suspend+0xc1/0x160
 [<c013e8a5>] enter_state+0xa5/0x140
 [<c013ea83>] state_store+0xf3/0x100
 [<c013e990>] state_store+0x0/0x100
 [<c01a91e0>] subsys_attr_store+0x30/0x40
 [<c01a9351>] sysfs_write_file+0xb1/0x110
 [<c016c016>] vfs_write+0xa6/0x140
 [<c01a92a0>] sysfs_write_file+0x0/0x110
 [<c016c5f1>] sys_write+0x41/0x70
 [<c0104068>] syscall_call+0x7/0xb
 [<c0340000>] schedule+0x280/0x630
 =======================
PM: wrong values count 0
PM: saving PCI state 0000:00:1f.3
PM: dev state 5
PM: dev enabled? 1
 [<c0201861>] pci_save_state+0x61/0x2b0
 [<ef85b04e>] i801_suspend+0xe/0x40 [i2c_i801]
 [<c0203893>] pci_device_suspend+0x23/0x60
 [<c0250258>] suspend_device+0xe8/0x1b0
 [<c021997e>] acpi_hw_clear_gpe_block+0x0/0x32
 [<c01f7072>] kobject_get+0x12/0x20
 [<c02503e1>] device_suspend+0xc1/0x160
 [<c013e8a5>] enter_state+0xa5/0x140
 [<c013ea83>] state_store+0xf3/0x100
 [<c013e990>] state_store+0x0/0x100
 [<c01a91e0>] subsys_attr_store+0x30/0x40
 [<c01a9351>] sysfs_write_file+0xb1/0x110
 [<c016c016>] vfs_write+0xa6/0x140
 [<c01a92a0>] sysfs_write_file+0x0/0x110
 [<c016c5f1>] sys_write+0x41/0x70
 [<c0104068>] syscall_call+0x7/0xb
 [<c0340000>] schedule+0x280/0x630
 =======================
PM: wrong values count 0
PM: saving PCI state 0000:00:1f.1
PM: dev state 5
PM: dev enabled? 1
 [<c0201861>] pci_save_state+0x61/0x2b0
 [<c0267bb4>] ata_pci_device_do_suspend+0x14/0x50
 [<c026d3ec>] ata_pci_device_suspend+0x2c/0x40
 [<c0203893>] pci_device_suspend+0x23/0x60
 [<c0250258>] suspend_device+0xe8/0x1b0
 [<c021997e>] acpi_hw_clear_gpe_block+0x0/0x32
 [<c01f7072>] kobject_get+0x12/0x20
 [<c02503e1>] device_suspend+0xc1/0x160
 [<c013e8a5>] enter_state+0xa5/0x140
 [<c013ea83>] state_store+0xf3/0x100
 [<c013e990>] state_store+0x0/0x100
 [<c01a91e0>] subsys_attr_store+0x30/0x40
 [<c01a9351>] sysfs_write_file+0xb1/0x110
 [<c016c016>] vfs_write+0xa6/0x140
 [<c01a92a0>] sysfs_write_file+0x0/0x110
 [<c016c5f1>] sys_write+0x41/0x70
 [<c0104068>] syscall_call+0x7/0xb
 [<c0340000>] schedule+0x280/0x630
 =======================
PM: wrong values count 0
ACPI: PCI interrupt for device 0000:00:1f.1 disabled
pci_set_power_state(): 0000:00:1f.1: state=3, current state=5
PM: saving PCI state 0000:00:1f.0
PM: dev state 5
PM: dev enabled? 0
 [<c0201861>] pci_save_state+0x61/0x2b0
 [<c02038be>] pci_device_suspend+0x4e/0x60
 [<c0250258>] suspend_device+0xe8/0x1b0
 [<c021997e>] acpi_hw_clear_gpe_block+0x0/0x32
 [<c01f7072>] kobject_get+0x12/0x20
 [<c02503e1>] device_suspend+0xc1/0x160
 [<c013e8a5>] enter_state+0xa5/0x140
 [<c013ea83>] state_store+0xf3/0x100
 [<c013e990>] state_store+0x0/0x100
 [<c01a91e0>] subsys_attr_store+0x30/0x40
 [<c01a9351>] sysfs_write_file+0xb1/0x110
 [<c016c016>] vfs_write+0xa6/0x140
 [<c01a92a0>] sysfs_write_file+0x0/0x110
 [<c016c5f1>] sys_write+0x41/0x70
 [<c0104068>] syscall_call+0x7/0xb
 [<c0340000>] schedule+0x280/0x630
 =======================
PM: wrong values count 0
PM: saving PCI state 0000:00:1e.0
PM: dev state 5
PM: dev enabled? 1
 [<c0201861>] pci_save_state+0x61/0x2b0
 [<c02038be>] pci_device_suspend+0x4e/0x60
 [<c0250258>] suspend_device+0xe8/0x1b0
 [<c021997e>] acpi_hw_clear_gpe_block+0x0/0x32
 [<c01f7072>] kobject_get+0x12/0x20
 [<c02503e1>] device_suspend+0xc1/0x160
 [<c013e8a5>] enter_state+0xa5/0x140
 [<c013ea83>] state_store+0xf3/0x100
 [<c013e990>] state_store+0x0/0x100
 [<c01a91e0>] subsys_attr_store+0x30/0x40
 [<c01a9351>] sysfs_write_file+0xb1/0x110
 [<c016c016>] vfs_write+0xa6/0x140
 [<c01a92a0>] sysfs_write_file+0x0/0x110
 [<c016c5f1>] sys_write+0x41/0x70
 [<c0104068>] syscall_call+0x7/0xb
 [<c0340000>] schedule+0x280/0x630
 =======================
PM: wrong values count 0
PM: saving PCI state 0000:00:1d.7
PM: dev state 0
PM: dev enabled? 1
 [<c0201861>] pci_save_state+0x61/0x2b0
 [<c028abcc>] usb_hcd_pci_suspend+0x13c/0x160
 [<c0203893>] pci_device_suspend+0x23/0x60
 [<c0250258>] suspend_device+0xe8/0x1b0
 [<c021997e>] acpi_hw_clear_gpe_block+0x0/0x32
 [<c01f7072>] kobject_get+0x12/0x20
 [<c02503e1>] device_suspend+0xc1/0x160
 [<c013e8a5>] enter_state+0xa5/0x140
 [<c013ea83>] state_store+0xf3/0x100
 [<c013e990>] state_store+0x0/0x100
 [<c01a91e0>] subsys_attr_store+0x30/0x40
 [<c01a9351>] sysfs_write_file+0xb1/0x110
 [<c016c016>] vfs_write+0xa6/0x140
 [<c01a92a0>] sysfs_write_file+0x0/0x110
 [<c016c5f1>] sys_write+0x41/0x70
 [<c0104068>] syscall_call+0x7/0xb
 [<c0340000>] schedule+0x280/0x630
 =======================
PM: wrong values count 0
ACPI: PCI interrupt for device 0000:00:1d.7 disabled
PM: saving PCI state 0000:00:1d.3
PM: dev state 0
PM: dev enabled? 1
 [<c0201861>] pci_save_state+0x61/0x2b0
 [<ef82c832>] uhci_suspend+0x92/0xf0 [uhci_hcd]
 [<c028abcc>] usb_hcd_pci_suspend+0x13c/0x160
 [<c0203893>] pci_device_suspend+0x23/0x60
 [<c0250258>] suspend_device+0xe8/0x1b0
 [<c021997e>] acpi_hw_clear_gpe_block+0x0/0x32
 [<c01f7072>] kobject_get+0x12/0x20
 [<c02503e1>] device_suspend+0xc1/0x160
 [<c013e8a5>] enter_state+0xa5/0x140
 [<c013ea83>] state_store+0xf3/0x100
 [<c013e990>] state_store+0x0/0x100
 [<c01a91e0>] subsys_attr_store+0x30/0x40
 [<c01a9351>] sysfs_write_file+0xb1/0x110
 [<c016c016>] vfs_write+0xa6/0x140
 [<c01a92a0>] sysfs_write_file+0x0/0x110
 [<c016c5f1>] sys_write+0x41/0x70
 [<c0104068>] syscall_call+0x7/0xb
 [<c0340000>] schedule+0x280/0x630
 =======================
PM: wrong values count 0
ACPI: PCI interrupt for device 0000:00:1d.3 disabled
PM: saving PCI state 0000:00:1d.2
PM: dev state 0
PM: dev enabled? 1
 [<c0201861>] pci_save_state+0x61/0x2b0
 [<ef82c832>] uhci_suspend+0x92/0xf0 [uhci_hcd]
 [<c028abcc>] usb_hcd_pci_suspend+0x13c/0x160
 [<c0203893>] pci_device_suspend+0x23/0x60
 [<c0250258>] suspend_device+0xe8/0x1b0
 [<c021997e>] acpi_hw_clear_gpe_block+0x0/0x32
 [<c01f7072>] kobject_get+0x12/0x20
 [<c02503e1>] device_suspend+0xc1/0x160
 [<c013e8a5>] enter_state+0xa5/0x140
 [<c013ea83>] state_store+0xf3/0x100
 [<c013e990>] state_store+0x0/0x100
 [<c01a91e0>] subsys_attr_store+0x30/0x40
 [<c01a9351>] sysfs_write_file+0xb1/0x110
 [<c016c016>] vfs_write+0xa6/0x140
 [<c01a92a0>] sysfs_write_file+0x0/0x110
 [<c016c5f1>] sys_write+0x41/0x70
 [<c0104068>] syscall_call+0x7/0xb
 [<c0340000>] schedule+0x280/0x630
 =======================
PM: wrong values count 0
ACPI: PCI interrupt for device 0000:00:1d.2 disabled
PM: saving PCI state 0000:00:1d.1
PM: dev state 0
PM: dev enabled? 1
 [<c0201861>] pci_save_state+0x61/0x2b0
 [<ef82c832>] uhci_suspend+0x92/0xf0 [uhci_hcd]
 [<c028abcc>] usb_hcd_pci_suspend+0x13c/0x160
 [<c0203893>] pci_device_suspend+0x23/0x60
 [<c0250258>] suspend_device+0xe8/0x1b0
 [<c021997e>] acpi_hw_clear_gpe_block+0x0/0x32
 [<c01f7072>] kobject_get+0x12/0x20
 [<c02503e1>] device_suspend+0xc1/0x160
 [<c013e8a5>] enter_state+0xa5/0x140
 [<c013ea83>] state_store+0xf3/0x100
 [<c013e990>] state_store+0x0/0x100
 [<c01a91e0>] subsys_attr_store+0x30/0x40
 [<c01a9351>] sysfs_write_file+0xb1/0x110
 [<c016c016>] vfs_write+0xa6/0x140
 [<c01a92a0>] sysfs_write_file+0x0/0x110
 [<c016c5f1>] sys_write+0x41/0x70
 [<c0104068>] syscall_call+0x7/0xb
 [<c0340000>] schedule+0x280/0x630
 =======================
PM: wrong values count 0
ACPI: PCI interrupt for device 0000:00:1d.1 disabled
PM: saving PCI state 0000:00:1d.0
PM: dev state 0
PM: dev enabled? 1
 [<c0201861>] pci_save_state+0x61/0x2b0
 [<ef82c832>] uhci_suspend+0x92/0xf0 [uhci_hcd]
 [<c028abcc>] usb_hcd_pci_suspend+0x13c/0x160
 [<c0203893>] pci_device_suspend+0x23/0x60
 [<c0250258>] suspend_device+0xe8/0x1b0
 [<c021997e>] acpi_hw_clear_gpe_block+0x0/0x32
 [<c01f7072>] kobject_get+0x12/0x20
 [<c02503e1>] device_suspend+0xc1/0x160
 [<c013e8a5>] enter_state+0xa5/0x140
 [<c013ea83>] state_store+0xf3/0x100
 [<c013e990>] state_store+0x0/0x100
 [<c01a91e0>] subsys_attr_store+0x30/0x40
 [<c01a9351>] sysfs_write_file+0xb1/0x110
 [<c016c016>] vfs_write+0xa6/0x140
 [<c01a92a0>] sysfs_write_file+0x0/0x110
 [<c016c5f1>] sys_write+0x41/0x70
 [<c0104068>] syscall_call+0x7/0xb
 [<c0340000>] schedule+0x280/0x630
 =======================
PM: wrong values count 0
ACPI: PCI interrupt for device 0000:00:1d.0 disabled
ACPI: PCI interrupt for device 0000:00:1b.0 disabled
PM: saving PCI state 0000:00:1b.0
PM: dev state 0
PM: dev enabled? 0
 [<c0201861>] pci_save_state+0x61/0x2b0
 [<c0200484>] pci_disable_device+0x54/0x90
 [<ef86ebf7>] azx_suspend+0xa7/0xd0 [snd_hda_intel]
 [<c0203893>] pci_device_suspend+0x23/0x60
 [<c0250258>] suspend_device+0xe8/0x1b0
 [<c021997e>] acpi_hw_clear_gpe_block+0x0/0x32
 [<c01f7072>] kobject_get+0x12/0x20
 [<c02503e1>] device_suspend+0xc1/0x160
 [<c013e8a5>] enter_state+0xa5/0x140
 [<c013ea83>] state_store+0xf3/0x100
 [<c013e990>] state_store+0x0/0x100
 [<c01a91e0>] subsys_attr_store+0x30/0x40
 [<c01a9351>] sysfs_write_file+0xb1/0x110
 [<c016c016>] vfs_write+0xa6/0x140
 [<c01a92a0>] sysfs_write_file+0x0/0x110
 [<c016c5f1>] sys_write+0x41/0x70
 [<c0104068>] syscall_call+0x7/0xb
 [<c0340000>] schedule+0x280/0x630
 =======================
PM: wrong values count 0
PM: saving PCI state 0000:00:02.1
PM: dev state 5
PM: dev enabled? 0
 [<c0201861>] pci_save_state+0x61/0x2b0
 [<ef86ec09>] azx_suspend+0xb9/0xd0 [snd_hda_intel]
 [<c02038be>] pci_device_suspend+0x4e/0x60
 [<c0250258>] suspend_device+0xe8/0x1b0
 [<c021997e>] acpi_hw_clear_gpe_block+0x0/0x32
 [<c01f7072>] kobject_get+0x12/0x20
 [<c02503e1>] device_suspend+0xc1/0x160
 [<c013e8a5>] enter_state+0xa5/0x140
 [<c013ea83>] state_store+0xf3/0x100
 [<c013e990>] state_store+0x0/0x100
 [<c01a91e0>] subsys_attr_store+0x30/0x40
 [<c01a9351>] sysfs_write_file+0xb1/0x110
 [<c016c016>] vfs_write+0xa6/0x140
 [<c01a92a0>] sysfs_write_file+0x0/0x110
 [<c016c5f1>] sys_write+0x41/0x70
 [<c0104068>] syscall_call+0x7/0xb
 [<c0340000>] schedule+0x280/0x630
 =======================
PM: wrong values count 0
PM: saving PCI state 0000:00:02.0
PM: dev state 5
PM: dev enabled? 0
 [<c0201861>] pci_save_state+0x61/0x2b0
 [<ef86ec09>] azx_suspend+0xb9/0xd0 [snd_hda_intel]
 [<c02038be>] pci_device_suspend+0x4e/0x60
 [<c0250258>] suspend_device+0xe8/0x1b0
 [<c021997e>] acpi_hw_clear_gpe_block+0x0/0x32
 [<c01f7072>] kobject_get+0x12/0x20
 [<c02503e1>] device_suspend+0xc1/0x160
 [<c013e8a5>] enter_state+0xa5/0x140
 [<c013ea83>] state_store+0xf3/0x100
 [<c013e990>] state_store+0x0/0x100
 [<c01a91e0>] subsys_attr_store+0x30/0x40
 [<c01a9351>] sysfs_write_file+0xb1/0x110
 [<c016c016>] vfs_write+0xa6/0x140
 [<c01a92a0>] sysfs_write_file+0x0/0x110
 [<c016c5f1>] sys_write+0x41/0x70
 [<c0104068>] syscall_call+0x7/0xb
 [<c0340000>] schedule+0x280/0x630
 =======================
PM: wrong values count 0
PM: saving PCI state 0000:00:01.0
PM: dev state 0
PM: dev enabled? 2
 [<c0201861>] pci_save_state+0x61/0x2b0
 [<c0206788>] pcie_port_device_suspend+0x18/0x20
 [<c0203893>] pci_device_suspend+0x23/0x60
 [<c0250258>] suspend_device+0xe8/0x1b0
 [<c021997e>] acpi_hw_clear_gpe_block+0x0/0x32
 [<c01f7072>] kobject_get+0x12/0x20
 [<c02503e1>] device_suspend+0xc1/0x160
 [<c013e8a5>] enter_state+0xa5/0x140
 [<c013ea83>] state_store+0xf3/0x100
 [<c013e990>] state_store+0x0/0x100
 [<c01a91e0>] subsys_attr_store+0x30/0x40
 [<c01a9351>] sysfs_write_file+0xb1/0x110
 [<c016c016>] vfs_write+0xa6/0x140
 [<c01a92a0>] sysfs_write_file+0x0/0x110
 [<c016c5f1>] sys_write+0x41/0x70
 [<c0104068>] syscall_call+0x7/0xb
 [<c0340000>] schedule+0x280/0x630
 =======================
PM: wrong values count 0
PM: saving PCI state 0000:00:00.0
PM: dev state 5
PM: dev enabled? 1
 [<c0201861>] pci_save_state+0x61/0x2b0
 [<c0206788>] pcie_port_device_suspend+0x18/0x20
 [<c02038be>] pci_device_suspend+0x4e/0x60
 [<c0250258>] suspend_device+0xe8/0x1b0
 [<c021997e>] acpi_hw_clear_gpe_block+0x0/0x32
 [<c01f7072>] kobject_get+0x12/0x20
 [<c02503e1>] device_suspend+0xc1/0x160
 [<c013e8a5>] enter_state+0xa5/0x140
 [<c013ea83>] state_store+0xf3/0x100
 [<c013e990>] state_store+0x0/0x100
 [<c01a91e0>] subsys_attr_store+0x30/0x40
 [<c01a9351>] sysfs_write_file+0xb1/0x110
 [<c016c016>] vfs_write+0xa6/0x140
 [<c01a92a0>] sysfs_write_file+0x0/0x110
 [<c016c5f1>] sys_write+0x41/0x70
 [<c0104068>] syscall_call+0x7/0xb
 [<c0340000>] schedule+0x280/0x630
 =======================
PM: wrong values count 0
Back to C!
PCI: Enabled ICH6/i801 SMBus device
ACPI: Transitioning device [FN00] to D3
ACPI: Transitioning device [FN00] to D3
PM: restoring PCI state 0000:00:00.0
PM: dev state 5
PM: dev enabled? 1
PM: restoring PCI state 0000:00:02.0
PM: dev state 5
PM: dev enabled? 0
PM: restoring PCI state 0000:00:01.0
PM: dev state 0
PM: dev enabled? 2
PM: Writing back config space on device 0000:00:01.0 at offset f (was 60100, writing 60105)
PM: Writing back config space on device 0000:00:01.0 at offset 1 (was 100104, writing 100504)
PCI: Setting latency timer of device 0000:00:01.0 to 64
PM: restoring PCI state 0000:00:02.0
PM: dev state 5
PM: dev enabled? 0
PM: restoring PCI state 0000:00:02.1
PM: dev state 5
PM: dev enabled? 0
PM: restoring PCI state 0000:00:1b.0
PM: dev state 0
PM: dev enabled? 0
PM: Writing back config space on device 0000:00:1b.0 at offset 1 (was 100006, writing 100002)
ACPI: PCI Interrupt 0000:00:1b.0[A] -> GSI 16 (level, low) -> IRQ 16
PCI: Setting latency timer of device 0000:00:1b.0 to 64
ACPI: PCI Interrupt 0000:00:1d.0[A] -> GSI 23 (level, low) -> IRQ 19
PCI: Setting latency timer of device 0000:00:1d.0 to 64
PM: restoring PCI state 0000:00:1d.0
PM: dev state 0
PM: dev enabled? 1
usb usb1: root hub lost power or was reset
ACPI: PCI Interrupt 0000:00:1d.1[B] -> GSI 19 (level, low) -> IRQ 20
PCI: Setting latency timer of device 0000:00:1d.1 to 64
PM: restoring PCI state 0000:00:1d.1
PM: dev state 0
PM: dev enabled? 1
usb usb2: root hub lost power or was reset
ACPI: PCI Interrupt 0000:00:1d.2[C] -> GSI 18 (level, low) -> IRQ 18
PCI: Setting latency timer of device 0000:00:1d.2 to 64
PM: restoring PCI state 0000:00:1d.2
PM: dev state 0
PM: dev enabled? 1
usb usb3: root hub lost power or was reset
ACPI: PCI Interrupt 0000:00:1d.3[D] -> GSI 16 (level, low) -> IRQ 16
PCI: Setting latency timer of device 0000:00:1d.3 to 64
PM: restoring PCI state 0000:00:1d.3
PM: dev state 0
PM: dev enabled? 1
usb usb4: root hub lost power or was reset
ACPI: PCI Interrupt 0000:00:1d.7[A] -> GSI 23 (level, low) -> IRQ 19
PCI: Setting latency timer of device 0000:00:1d.7 to 64
PM: restoring PCI state 0000:00:1d.7
PM: dev state 0
PM: dev enabled? 1
PM: restoring PCI state 0000:00:1e.0
PM: dev state 5
PM: dev enabled? 1
PM: Writing back config space on device 0000:00:1e.0 at offset 9 (was 1fff1, writing 35f13001)
PCI: Setting latency timer of device 0000:00:1e.0 to 64
PM: restoring PCI state 0000:00:1f.0
PM: dev state 5
PM: dev enabled? 0
PM: restoring PCI state 0000:00:1f.1
PM: dev state 5
PM: dev enabled? 0
PM: Writing back config space on device 0000:00:1f.1 at offset 1 (was 2800005, writing 2880005)
ACPI: PCI Interrupt 0000:00:1f.1[A] -> GSI 18 (level, low) -> IRQ 18
PCI: Setting latency timer of device 0000:00:1f.1 to 64
PM: restoring PCI state 0000:00:1f.3
PM: dev state 5
PM: dev enabled? 1
PM: restoring PCI state 0000:01:00.0
PM: dev state 0
PM: dev enabled? 1
PM: restoring PCI state 0000:01:01.0
PM: dev state 5
PM: dev enabled? 1
PM: Writing back config space on device 0000:01:01.0 at offset f (was 800100, writing ffffffff)
PM: Writing back config space on device 0000:01:01.0 at offset e (was d4fc, writing ffffffff)
PM: Writing back config space on device 0000:01:01.0 at offset d (was d400, writing ffffffff)
PM: Writing back config space on device 0000:01:01.0 at offset c (was 0, writing ffffffff)
PM: Writing back config space on device 0000:01:01.0 at offset b (was 0, writing ffffffff)
PM: Writing back config space on device 0000:01:01.0 at offset a (was 3bfff000, writing ffffffff)
PM: Writing back config space on device 0000:01:01.0 at offset 9 (was 0, writing ffffffff)
PM: Writing back config space on device 0000:01:01.0 at offset 8 (was 0, writing ffffffff)
PM: Writing back config space on device 0000:01:01.0 at offset 7 (was 0, writing ffffffff)
PM: Writing back config space on device 0000:01:01.0 at offset 6 (was 40020201, writing ffffffff)
PM: Writing back config space on device 0000:01:01.0 at offset 5 (was 20000dc, writing ffffffff)
PM: Writing back config space on device 0000:01:01.0 at offset 4 (was 0, writing ffffffff)
PM: Writing back config space on device 0000:01:01.0 at offset 3 (was 822000, writing ffffffff)
PM: Writing back config space on device 0000:01:01.0 at offset 2 (was 60700b3, writing ffffffff)
PM: Writing back config space on device 0000:01:01.0 at offset 1 (was 2100107, writing ffffffff)
PM: Writing back config space on device 0000:01:01.0 at offset 0 (was 4761180, writing ffffffff)
ACPI: PCI Interrupt 0000:01:01.0[A] -> GSI 17 (level, low) -> IRQ 17
PM: restoring PCI state 0000:01:01.1
PM: dev state 5
PM: dev enabled? 1
PM: Writing back config space on device 0000:01:01.1 at offset f (was 4020205, writing ffffffff)
PM: Writing back config space on device 0000:01:01.1 at offset e (was 0, writing ffffffff)
PM: Writing back config space on device 0000:01:01.1 at offset d (was dc, writing ffffffff)
PM: Writing back config space on device 0000:01:01.1 at offset c (was 0, writing ffffffff)
PM: Writing back config space on device 0000:01:01.1 at offset b (was 19671043, writing ffffffff)
PM: Writing back config space on device 0000:01:01.1 at offset a (was 0, writing ffffffff)
PM: Writing back config space on device 0000:01:01.1 at offset 9 (was 0, writing ffffffff)
PM: Writing back config space on device 0000:01:01.1 at offset 8 (was 0, writing ffffffff)
PM: Writing back config space on device 0000:01:01.1 at offset 7 (was 0, writing ffffffff)
PM: Writing back config space on device 0000:01:01.1 at offset 6 (was 0, writing ffffffff)
PM: Writing back config space on device 0000:01:01.1 at offset 5 (was 0, writing ffffffff)
PM: Writing back config space on device 0000:01:01.1 at offset 4 (was fe8fd800, writing ffffffff)
PM: Writing back config space on device 0000:01:01.1 at offset 3 (was 804000, writing ffffffff)
PM: Writing back config space on device 0000:01:01.1 at offset 2 (was c001008, writing ffffffff)
PM: Writing back config space on device 0000:01:01.1 at offset 1 (was 2100006, writing ffffffff)
PM: Writing back config space on device 0000:01:01.1 at offset 0 (was 5521180, writing ffffffff)
ACPI: PCI Interrupt 0000:01:01.1[B] -> GSI 16 (level, low) -> IRQ 16
PM: restoring PCI state 0000:01:01.2
PM: dev state 5
PM: dev enabled? 0
PM: Writing back config space on device 0000:01:01.2 at offset f (was 306, writing ffffffff)
PM: Writing back config space on device 0000:01:01.2 at offset e (was 0, writing ffffffff)
PM: Writing back config space on device 0000:01:01.2 at offset d (was 80, writing ffffffff)
PM: Writing back config space on device 0000:01:01.2 at offset c (was 0, writing ffffffff)
PM: Writing back config space on device 0000:01:01.2 at offset b (was 19671043, writing ffffffff)
PM: Writing back config space on device 0000:01:01.2 at offset a (was 0, writing ffffffff)
PM: Writing back config space on device 0000:01:01.2 at offset 9 (was 0, writing ffffffff)
PM: Writing back config space on device 0000:01:01.2 at offset 8 (was 0, writing ffffffff)
PM: Writing back config space on device 0000:01:01.2 at offset 7 (was 0, writing ffffffff)
PM: Writing back config space on device 0000:01:01.2 at offset 6 (was 0, writing ffffffff)
PM: Writing back config space on device 0000:01:01.2 at offset 5 (was 0, writing ffffffff)
PM: Writing back config space on device 0000:01:01.2 at offset 4 (was fe8fe400, writing ffffffff)
PM: Writing back config space on device 0000:01:01.2 at offset 3 (was 804000, writing ffffffff)
PM: Writing back config space on device 0000:01:01.2 at offset 2 (was 8050017, writing ffffffff)
PM: Writing back config space on device 0000:01:01.2 at offset 1 (was 2100006, writing ffffffff)
PM: Writing back config space on device 0000:01:01.2 at offset 0 (was 8221180, writing ffffffff)
PM: restoring PCI state 0000:01:01.3
PM: dev state 5
PM: dev enabled? 0
PM: Writing back config space on device 0000:01:01.3 at offset f (was 306, writing ffffffff)
PM: Writing back config space on device 0000:01:01.3 at offset e (was 0, writing ffffffff)
PM: Writing back config space on device 0000:01:01.3 at offset d (was 80, writing ffffffff)
PM: Writing back config space on device 0000:01:01.3 at offset c (was 0, writing ffffffff)
PM: Writing back config space on device 0000:01:01.3 at offset b (was 19671043, writing ffffffff)
PM: Writing back config space on device 0000:01:01.3 at offset a (was 0, writing ffffffff)
PM: Writing back config space on device 0000:01:01.3 at offset 9 (was 0, writing ffffffff)
PM: Writing back config space on device 0000:01:01.3 at offset 8 (was 0, writing ffffffff)
PM: Writing back config space on device 0000:01:01.3 at offset 7 (was 0, writing ffffffff)
PM: Writing back config space on device 0000:01:01.3 at offset 6 (was 0, writing ffffffff)
PM: Writing back config space on device 0000:01:01.3 at offset 5 (was 0, writing ffffffff)
PM: Writing back config space on device 0000:01:01.3 at offset 4 (was fe8fe800, writing ffffffff)
PM: Writing back config space on device 0000:01:01.3 at offset 3 (was 800000, writing ffffffff)
PM: Writing back config space on device 0000:01:01.3 at offset 2 (was 8800008, writing ffffffff)
PM: Writing back config space on device 0000:01:01.3 at offset 1 (was 2100002, writing ffffffff)
PM: Writing back config space on device 0000:01:01.3 at offset 0 (was 5921180, writing ffffffff)
PM: restoring PCI state 0000:01:01.4
PM: dev state 5
PM: dev enabled? 0
PM: Writing back config space on device 0000:01:01.4 at offset f (was 306, writing ffffffff)
PM: Writing back config space on device 0000:01:01.4 at offset e (was 0, writing ffffffff)
PM: Writing back config space on device 0000:01:01.4 at offset d (was 80, writing ffffffff)
PM: Writing back config space on device 0000:01:01.4 at offset c (was 0, writing ffffffff)
PM: Writing back config space on device 0000:01:01.4 at offset b (was 19671043, writing ffffffff)
PM: Writing back config space on device 0000:01:01.4 at offset a (was 0, writing ffffffff)
PM: Writing back config space on device 0000:01:01.4 at offset 9 (was 0, writing ffffffff)
PM: Writing back config space on device 0000:01:01.4 at offset 8 (was 0, writing ffffffff)
PM: Writing back config space on device 0000:01:01.4 at offset 7 (was 0, writing ffffffff)
PM: Writing back config space on device 0000:01:01.4 at offset 6 (was 0, writing ffffffff)
PM: Writing back config space on device 0000:01:01.4 at offset 5 (was 0, writing ffffffff)
PM: Writing back config space on device 0000:01:01.4 at offset 4 (was fe8fec00, writing ffffffff)
PM: Writing back config space on device 0000:01:01.4 at offset 3 (was 800000, writing ffffffff)
PM: Writing back config space on device 0000:01:01.4 at offset 2 (was 8800003, writing ffffffff)
PM: Writing back config space on device 0000:01:01.4 at offset 1 (was 2100002, writing ffffffff)
PM: Writing back config space on device 0000:01:01.4 at offset 0 (was 8521180, writing ffffffff)
PM: restoring PCI state 0000:01:02.0
PM: dev state 5
PM: dev enabled? 0
PM: Writing back config space on device 0000:01:02.0 at offset 1 (was 2900016, writing 2900002)

-- 
Lukáš Hejtmánek

RE: [PATCH] Workaround for a PCI restoring bug

[Brown, Len]

[-- Attachment #1: Type: text/plain, Size: 5706 bytes --]

>> the problem is that saving device state didn't 
>> work, because the device was somehow turned off at suspend 
>> time before we even saved it, so we saved crap.
>> Or more specifically, we saved 
>> all-0xffffffff values from the config space, because the 
>> devices were effectively not there any more! ]
>> 
>> On Wed, 16 May 2007, Lukas Hejtmanek wrote:
>> > 
>> > ...
>> > The problematic code is in drivers/acpi/hardware/hwsleep.c method
>> > acpi_enter_sleep_state_prep.
>> > 
>> > In particular code:
>> > /* Run the _PTS and _GTS methods */
>> > 

>> 
>> Ok, so to fix this bug, we really should do 
>> acpi_enter_sleep_state_prep() 
>> _after_ we have done our own suspend/save of the device information, 
>> rather than before. Because clearly acpi_enter_sleep_state_prep() can

>> corrupt the state wee *want* to save!

Right.

>> Of course, it has to be between the "suspend()" and the 
>> "suspend_late()" 
>> calls, since it wants to run with interrupts enabled and the 
>> system in a 
>> working state, and the final suspend_late() really does end 
>> up shutting 
>> things down and does *not* want to have things in a "working" state.
>> 
>> But that's fine. It is, after all, how suspend/suspend_late 
>> was designed 
>> to work: the "suspend()" part should allocate memory and 
>> save state, the 
>> "suspend_late()" part should actually suspend the device. So 
>> this does fit in the model.

>> - call "device_suspend()" before the "pm_ops->prepare()" function,
and 
>>    then call the "suspend_late()" thing just before the actual
suspend. 
>> 
>>    This *should* work, and I think it's the right thing to do, but
the 
>>    "change order of ACPI calls" is dangerous. Much more dangerous
than I'd 
>>    like. There's no way I can do it before 2.6.22 - it would have to
go 
>>    into 2.6.23-rc1 (and the ugly patch might be a candidate for
2.6.22, 
>>    however much I hate it)

While I know it breaks your own rule for taking risks after rc1,
I don't see a huge down-side to pushing this patch now.
Suspend on Linux has numerous problems on numerous boxes, and this fix
appears to be obvious and important -- so the reward is potentially
large.
It is a small text change to code that is not otherwise changing --
so if it causes a regression before 2.6.22, simply revert it.
Consider that if Rafael had found this test-case box, I'm sure he would
have
shipped you this patch before the rc1 cutoff.

Acked-by: Len Brown <len.brown@intel.com>
If you want somebody to blame:-)

>>    However, the reason I think that's the correct thing to 
>>    do is that on *resume*, we actually already call "pm_finish()"
>>    before we call  "device_resume()", so _logically_ we should do
>>    the suspend in the reverse order too!

Agreed.

>> Len? What do you think? Does the ACPI spec say anything? Do 
>> you know what the other system (the one that BIOS vendors actually
test with) does?

>Well, I've raised exactly the same issue on linux-pm and 
>linux-acpi recently,
>but I haven't had a test case to support my observations.
>
>In fact, we're violating the spec by executing the _PTS and 
>_GTS control methods before suspending devices.

Agreed.  suspend_prepare() has this order wrong.
Linus' patch (attached) looks like it fixes it.

>The spec is clear in these points:
>_PTS should be executed *after* devices are placed in 
>low-power states and
>_GTS should be executed immediately before the sleep state is 
>*entered*.

Yep -- here's the quote from ACPI 3.0b:

OSPM will invoke _GTS, _PTS, _TTS, _WAK, and _BFS in the following
order:
1.OSPM decides (through a policy scheme) to place the system into a
sleeping state.
2._TTS(Sx) is run, where Sx is the desired sleep state to enter.
3. OSPM notifies all native device drivers of the sleep state transition
4._PTS is run
5.OSPM readies system for the sleep state transition
6._GTS is run
7.OSPM writes the sleep vector and the system enters the specified Sx
sleep state.
8.System Wakes up
9._BFS is run
10.OSPM readies system for the return from the sleep state transition
11._WAK is run
12. OSPM notifies all native device drivers of the return from the sleep
state transition
13._TTS(0) is run to indicate the return to the S0 state.

Technically we write the sleep vector too early as well.
And we don't evaluate _TTS at all -- though _TTS was
added only as of ACPI 3.0 and I've not seen it implemented on
any of the systems I've got.

>Thus I think the second patch is a better thing to do long 
>term.  Moreover, I'd
>also move the execution of _GTS to after disable_nonboot_cpus()

I'd agree to that on the grounds of symmetry.
However, I expect it will be a NOP -- since the BIOS
can't tell the difference between an enabled and a non-enabled CPU.
(The possible exception is if any BIOS hooks -- such as magic traps
 into SMM -- assume that they're run in cpu0).

In the resume case, the order is important.  Per our discussion
on this last November, _WAK must follow _INIT of the non boot cpus
so that it can patch up stuff in firmware that got cleared on reset.
This continues to be true in Linux.

>(and, symmetrically, the execution of _BFS to before 
>enable_nonboot_cpus(), which
>also would be more in line with the spec, but that's a separate issue).

True, _BFS is probably later than the spec wants.
But like _GTS, it was added with ACPI 2.0 and it is optional
for a BIOS to implement it.  Poking around, I don't see any systems
that actually implement _BFS or _GTS.  So that tweak probably isn't
a big deal like the problem at hand.

thanks,
-Len

[-- Attachment #2: diff-better --]
[-- Type: application/octet-stream, Size: 951 bytes --]

 kernel/power/main.c |   15 ++++++++-------
 1 files changed, 8 insertions(+), 7 deletions(-)

diff --git a/kernel/power/main.c b/kernel/power/main.c
index 40d56a3..b98b80c 100644
--- a/kernel/power/main.c
+++ b/kernel/power/main.c
@@ -97,25 +97,26 @@ static int suspend_prepare(suspend_state_t state)
 		}
 	}
 
-	if (pm_ops->prepare) {
-		if ((error = pm_ops->prepare(state)))
-			goto Thaw;
-	}
-
 	suspend_console();
 	error = device_suspend(PMSG_SUSPEND);
 	if (error) {
 		printk(KERN_ERR "Some devices failed to suspend\n");
-		goto Resume_devices;
+		goto Resume_console;
 	}
+	if (pm_ops->prepare) {
+		if ((error = pm_ops->prepare(state)))
+			goto Resume_devices;
+	}
+
 	error = disable_nonboot_cpus();
 	if (!error)
 		return 0;
 
 	enable_nonboot_cpus();
- Resume_devices:
 	pm_finish(state);
+ Resume_devices:
 	device_resume();
+ Resume_console:
 	resume_console();
  Thaw:
 	thaw_processes();

Re: [PATCH] Workaround for a PCI restoring bug

[Lukas Hejtmanek]

> Yep -- here's the quote from ACPI 3.0b:
> 
> OSPM will invoke _GTS, _PTS, _TTS, _WAK, and _BFS in the following
> order:
> 1.OSPM decides (through a policy scheme) to place the system into a
> sleeping state.
> 2._TTS(Sx) is run, where Sx is the desired sleep state to enter.
> 3. OSPM notifies all native device drivers of the sleep state transition
> 4._PTS is run
> 5.OSPM readies system for the sleep state transition
> 6._GTS is run
> 7.OSPM writes the sleep vector and the system enters the specified Sx
> sleep state.
> 8.System Wakes up
> 9._BFS is run
> 10.OSPM readies system for the return from the sleep state transition
> 11._WAK is run
> 12. OSPM notifies all native device drivers of the return from the sleep
> state transition
> 13._TTS(0) is run to indicate the return to the S0 state.
> 
> Technically we write the sleep vector too early as well.
> And we don't evaluate _TTS at all -- though _TTS was
> added only as of ACPI 3.0 and I've not seen it implemented on
> any of the systems I've got.

However, we still do something wrong with ACPI and suspend-to-ram because my
system is unable to reboot after resume from ram. The only way to reboot is to
disable the ACPI in the machine_emergency_restart(). (in particular, keyboard
LEDs flash as the reset has been issued but the BIOS logo does not appear.)

Any ideas, Len?

Andrew dislikes the patch resulted from this bug report:
http://bugzilla.kernel.org/show_bug.cgi?id=6655

Anyway, it works for me pretty well.

-- 
Lukáš Hejtmánek
-
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] Workaround for a PCI restoring bug

[Rafael J. Wysocki]

On Thursday, 17 May 2007 22:50, Lukas Hejtmanek wrote:
> > Yep -- here's the quote from ACPI 3.0b:
> > 
> > OSPM will invoke _GTS, _PTS, _TTS, _WAK, and _BFS in the following
> > order:
> > 1.OSPM decides (through a policy scheme) to place the system into a
> > sleeping state.
> > 2._TTS(Sx) is run, where Sx is the desired sleep state to enter.
> > 3. OSPM notifies all native device drivers of the sleep state transition
> > 4._PTS is run
> > 5.OSPM readies system for the sleep state transition
> > 6._GTS is run
> > 7.OSPM writes the sleep vector and the system enters the specified Sx
> > sleep state.
> > 8.System Wakes up
> > 9._BFS is run
> > 10.OSPM readies system for the return from the sleep state transition
> > 11._WAK is run
> > 12. OSPM notifies all native device drivers of the return from the sleep
> > state transition
> > 13._TTS(0) is run to indicate the return to the S0 state.
> > 
> > Technically we write the sleep vector too early as well.
> > And we don't evaluate _TTS at all -- though _TTS was
> > added only as of ACPI 3.0 and I've not seen it implemented on
> > any of the systems I've got.
> 
> However, we still do something wrong with ACPI and suspend-to-ram because my
> system is unable to reboot after resume from ram. The only way to reboot is to
> disable the ACPI in the machine_emergency_restart(). (in particular, keyboard
> LEDs flash as the reset has been issued but the BIOS logo does not appear.)

Can you please send me your DSDT?

Rafael

Re: [PATCH] Workaround for a PCI restoring bug

[Lukas Hejtmanek]

[-- Attachment #1: Type: text/plain, Size: 474 bytes --]

On Thu, May 17, 2007 at 11:25:05PM +0200, Rafael J. Wysocki wrote:
> > However, we still do something wrong with ACPI and suspend-to-ram because
> > my system is unable to reboot after resume from ram. The only way to
> > reboot is to disable the ACPI in the machine_emergency_restart(). (in
> > particular, keyboard LEDs flash as the reset has been issued but the BIOS
> > logo does not appear.)
> 
> Can you please send me your DSDT?

it's attached. 

-- 
Lukáš Hejtmánek

[-- Attachment #2: dsdt.gz --]
[-- Type: application/octet-stream, Size: 13773 bytes --]