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.
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.
(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.
(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.
Ok, please ignore the bug report. After reinstalling the kernel package and the pm-utils package, the problem went away. :|
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.
OK, I think I must have been really confused or tired because it looks like I posted my diagnostics to the wrong bug, sorry. :\