Bug 15165 - pm_suspend stopped working, while echo mem > /sys/power/state does
pm_suspend stopped working, while echo mem > /sys/power/state does
Status: CLOSED INVALID
Product: Power Management
Classification: Unclassified
Component: Hibernation/Suspend
All Linux
: P1 low
Assigned To: power-management_other
:
Depends on:
Blocks: 7216
  Show dependency treegraph
 
Reported: 2010-01-28 20:24 UTC by Michał Witkowski
Modified: 2011-04-12 22:43 UTC (History)
2 users (show)

See Also:
Kernel Version: 2.6.33-rc5
Tree: Mainline
Regression: Yes


Attachments

Description Michał Witkowski 2010-01-28 20:24:46 UTC
Hi,

I'm testing kernel 2.6.33-rc5 on my Lenovo Ideapad U330 laptop.

After moving to the rc5 kernel from 2.6.32.5, pm_suspend stopped working. 
I can still, however, suspend and resume under 2.6.33-rc5 using "echo mem > /sys/power/sate". The same method works ok under 2.6.32.5 too.

Unfortunately neither messages.log, dmesg, nor pm*.log files contain any clues as to why pm_suspend fails. I'm not using any quircks.

The thing is: pm_suspend is used by KDE's suspend bindings (through HAL I presume).

System is Arch Linux current. pm_suspend version is 1.2.6.1.

I'm sorry if I reported this in the wrong bugzilla, I thought that since pm_suspend broke with the 2.6.33-rc5, it's possibly a kernel regression. If its supposed to be reported somewhere else, please close this.
Comment 1 Rafael J. Wysocki 2010-01-28 20:34:58 UTC
Have you changed the kernel configuration?

Can you run scripts/diffconfig to compare .config for the old and new kernels?

I guess your distro tries to apply some workaround for your system that is not necessary any more and even hurts with the new kernel, so it should be reported to the distro as well IMO.
Comment 2 Michał Witkowski 2010-01-28 20:55:15 UTC
(In reply to comment #1)
> Have you changed the kernel configuration?
> 
> Can you run scripts/diffconfig to compare .config for the old and new kernels?

Nope I haven't. The input config file to the kernel 2.6.33-rc5 compilation was the exact one used to compile 2.6.32.5. New options where taken care of using:
  yes "" | make config

> 
> I guess your distro tries to apply some workaround for your system that is not
> necessary any more and even hurts with the new kernel, so it should be reported
> to the distro as well IMO.

Arch Linux usually ships vanilla packages. I've checked the PKGBUILD for pm-utils. The only patch is responsible for putting files somewhere else, because of Arch Linux's BSD-like init scripts.
Comment 3 Rafael J. Wysocki 2010-01-28 21:04:46 UTC
(In reply to comment #2)
> (In reply to comment #1)
> > Have you changed the kernel configuration?
> > 
> > Can you run scripts/diffconfig to compare .config for the old and new kernels?
> 
> Nope I haven't. The input config file to the kernel 2.6.33-rc5 compilation was
> the exact one used to compile 2.6.32.5. New options where taken care of using:
>   yes "" | make config

That's what I'm talking about.  Can you run the diffconfig, please?

> > I guess your distro tries to apply some workaround for your system that is not
> > necessary any more and even hurts with the new kernel, so it should be reported
> > to the distro as well IMO.
> 
> Arch Linux usually ships vanilla packages. I've checked the PKGBUILD for
> pm-utils. The only patch is responsible for putting files somewhere else,
> because of Arch Linux's BSD-like init scripts.

But it doesn't use "echo mem > /sys/power/state" by default, because everything would work if it did.  Please attach pm-suspend.log.
Comment 4 Michał Witkowski 2010-01-28 23:01:55 UTC
Ok, please ignore the bug report. After reinstalling the kernel package and the pm-utils package, the problem went away. :|
Comment 5 Jeremy Murphy 2011-04-05 05:36:38 UTC
I can reliably reproduce this bug with every recent kernel on two different laptops, as it has been plaguing me for a couple of years.  I would love to see it fixed, but I'm not sure if it is actually in the kernel or the script that triggers it.

In my case the nfsmount script triggers the bug, in either of two ways:

1) Reliable: mount an NFS share from my desktop on my laptop, shut down the desktop, then try to suspend the laptop.  No real surprise there.

2) Less reliable: any time it feels like it, even if nothing has been mounted.

Here is a snippet of dmesg from scenario #2 as an example:


Freezing user space processes ... 
Freezing of tasks failed after 20.01 seconds (1 tasks refusing to freeze, wq_busy=0):
mount.nfs       D ffff880057246f60     0 22088  22087 0x00800004
 ffff880057246f60 0000000000000082 000001001e6df8d8 ffff880040280630
 ffff88002c004340 ffffffff810e0a5f 0000000000011080 ffff88001e6dffd8
 0000000000011080 0000000000011080 ffff8800572471e0 ffff8800572471e8
Call Trace:
 [<ffffffff810e0a5f>] ? __d_instantiate+0x7d/0xc4
 [<ffffffff8145de1a>] ? rpc_wait_bit_killable+0x0/0x34
 [<ffffffff8145de4a>] ? rpc_wait_bit_killable+0x30/0x34
 [<ffffffff8148ac1d>] ? __wait_on_bit+0x3e/0x6f
 [<ffffffff8148acbc>] ? out_of_line_wait_on_bit+0x6e/0x77
 [<ffffffff8145de1a>] ? rpc_wait_bit_killable+0x0/0x34
 [<ffffffff8106badd>] ? wake_bit_function+0x0/0x2e
 [<ffffffff8145e498>] ? __rpc_execute+0xe9/0x243
 [<ffffffff8106baa3>] ? wake_up_bit+0x10/0x20
 [<ffffffff81458d1a>] ? rpc_run_task+0xd6/0xde
 [<ffffffff81458e05>] ? rpc_call_sync+0x3d/0x5d
 [<ffffffff81458e67>] ? rpc_ping+0x42/0x5a
 [<ffffffff81459709>] ? rpc_create+0x43d/0x4a4
 [<ffffffff8145f7bb>] ? rpcauth_lookup_credcache+0x198/0x1ff
 [<ffffffff81156091>] ? nfs_create_rpc_client+0x9b/0xdd
 [<ffffffff81156c88>] ? nfs4_set_client+0xc4/0x1f9
 [<ffffffff8145ea0d>] ? __rpc_init_priority_wait_queue+0x87/0xa8
 [<ffffffff811572f9>] ? nfs4_create_server+0xe5/0x1ea
 [<ffffffff8115f66e>] ? nfs4_remote_mount+0x49/0x179
 [<ffffffff810d3524>] ? vfs_kern_mount+0x6e/0x152
 [<ffffffff81160619>] ? nfs_do_root_mount+0x70/0x91
 [<ffffffff8116072f>] ? nfs4_try_mount+0x55/0xad
 [<ffffffff81160e96>] ? nfs_get_sb+0x405/0x637
 [<ffffffff810d354a>] ? vfs_kern_mount+0x94/0x152
 [<ffffffff810d3666>] ? do_kern_mount+0x49/0xd6
 [<ffffffff810e91a5>] ? do_mount+0x745/0x7b1
 [<ffffffff810e9299>] ? sys_mount+0x88/0xc3
 [<ffffffff8102577b>] ? system_call_fastpath+0x16/0x1b

Restarting tasks ... done.

/var/log/pm-suspend.log has the "Device or resource busy" error with respect to /sys/power/state.

I have read a Debian user report what appears to be the same bug but with SSHFS instead of NFS.

So, if this is a kernel bug, how do we proceed?  If not, where should I take my bug report?  Thanks, cheers.
Comment 6 Jeremy Murphy 2011-04-12 22:43:48 UTC
OK, I think I must have been really confused or tired because it looks like I posted my diagnostics to the wrong bug, sorry.  :\

Note You need to log in before you can comment on or make changes to this bug.