Gnome-Do Preventing Suspend

[Bart Rose]

Binary package hint: gnome-do

After updating to gnome-do 8.2 I have not been able to suspend. The system attempts to suspend but times out at 20 seconds and reports that gnome-do was unable to freeze. If I manually exit gnome-do before suspending, this process runs smoothly. This was not an issue with prior versions. I have forced an older version of gnome-do to install and the problem goes away. I am running Jaunty 2.6.28-13 on an Acer Aspire One with all current updates from proposed. Interestingly, this is not an issue on my other laptop running gnome-do 8.2.

**Update**
Seems to be related to "files and folders" plugin. If plugin disabled then no problem with suspend.

[Bart Rose (jbrose3)]

 Also, if indexing kept to 2 levels or less then no problem. It seems to be related to the size of the index. Perhaps this is not an issue on my thinkpad due to processor speed and the rate at which it is able to re-index. Hope this is making some sense.

[Nick B. (futurepilot)]

I'm seeing this problem too on 2 different computers. I'll test disabling the files and folders plugin and see what happens.

[Nick B. (futurepilot)]

Sorry it's taken so long. I disabled the files and folders plugin and haven't had any problems with suspend since. I'll mark this as confirmed.

[d0gmatic (d0gmaticx2x)]

i also am running into this problem (sorry for the confusion about marking the gnome-do 'incomplete'... new at using launchpad. it is definitely the 'files and folder' plugin.

[Bart Rose (jbrose3)]

Continues to be an issue on Karmic. In fact, can now only index one folder level without affecting suspend.

[sickanimations (email-timcinel)]

I'm running 9.04 on Acer Aspire One and also see the same issue. It's interesting that once I try to suspend using GDo, I can't suspend until I kill it. If I relaunch it I can suspend via keyboard or other methods, just not through GDo. Hope this helps. My File and Folder index has about 5,000 files.

[Robert Dyer (psybers)]

The inability to suspend via Do was recently fixed. I think there will be an update to the karmic package soon.

The other problem (suspend not working unless you kill Do) is easily fixed by lowering how many files are watched. Disable that plugin or limit how many folders are watched, it goes away as commented above.

[Cuco3 (wadecounty)]

I'm getting the same problem. Ubuntu Jaunty.

[Dmik (dmik-for-maillists)]

The problem is still there in Lucid. I have to close Gnome Do before each suspend.

[sickanimations (email-timcinel)]

I'm running 10.04 and the problem's definitely still there - do will prevent suspend about 2/3 of the time. Killing gnome-do is the only way to suspend reliably.

[Julien (jul-cornu)]

I confirm that on Ubuntu 10.04, the bug is still there.
I also confirm it is related to the file indexing level: I have quite a nested tree of folders with few files in them, but quite a big depth (~10), I had to reduce the indexing level from 10 to 2, which makes the indexing useless for me (and maybe gnome-do as well).

[Mario B. (boonekamp-deactivatedaccount-deactivatedaccount)]

Still the same on Ubuntu 11.04. Any progress would be greatly appreciated. Some output of dmesg after turning on pm_trace (echo 1 > /sys/power/pm-trace):

[ 1168.500933] PM: Syncing filesystems ... done.
[ 1168.503670] PM: Preparing system for mem sleep
[ 1168.715991] Freezing user space processes ...
[ 1188.725230] Freezing of tasks failed after 20.01 seconds (1 tasks refusing to freeze, wq_busy=0):
[ 1188.725274] gnome-do D c10665ab 0 1699 1467 0x00800004
[ 1188.725278] efea1d9c 00200086 efea1d2c c10665ab f74c8000 efea1d2c ed039bcc c1879680
[ 1188.725282] 948dec8c 0000010f ed039bc8 c1879680 c1879680 f7807680 ed039940 c1766f60
[ 1188.725285] edf64a64 efea1d74 fa84d6a3 edf64800 f6d14004 efea1d88 fa84b52d 00200246
[ 1188.725288] Call Trace:
[ 1188.725294] [<c10665ab>] ? lock_timer_base.clone.21+0x2b/0x50
[ 1188.725303] [<fa84d6a3>] ? __rpc_sleep_on+0x93/0x110 [sunrpc]
[ 1188.725309] [<fa84b52d>] ? xs_tcp_send_request+0x4d/0x140 [sunrpc]
[ 1188.725312] [<c10359b8>] ? default_spin_lock_flags+0x8/0x10
[ 1188.725315] [<c15325ef>] ? _raw_spin_lock_irqsave+0x2f/0x50
[ 1188.725321] [<fa84ce9e>] rpc_wait_bit_killable+0x1e/0x40 [sunrpc]
[ 1188.725323] [<c1530ecd>] __wait_on_bit+0x4d/0x70
[ 1188.725327] [<fa84ce80>] ? rpc_wait_bit_killable+0x0/0x40 [sunrpc]
[ 1188.725332] [<fa84ce80>] ? rpc_wait_bit_killable+0x0/0x40 [sunrpc]
[ 1188.725334] [<c1530f51>] out_of_line_wait_on_bit+0x61/0x70
[ 1188.725337] [<c1076e20>] ? wake_bit_function+0x0/0x60
[ 1188.725341] [<fa84d515>] __rpc_execute+0xd5/0x1b0 [sunrpc]
[ 1188.725346] [<fa84d9e8>] rpc_execute+0x38/0x40 [sunrpc]
[ 1188.725350] [<fa847314>] rpc_run_task+0xa4/0xe0 [sunrpc]
[ 1188.725355] [<fa84744c>] rpc_call_sync+0x3c/0x60 [sunrpc]
[ 1188.725362] [<fb0f8c67>] nfs3_rpc_wrapper.clone.7+0x37/0x60 [nfs]
[ 1188.725367] [<fb0f9c9d>] nfs3_proc_getattr+0x3d/0x80 [nfs]
[ 1188.725372] [<fb0ea269>] __nfs_revalidate_inode+0xa9/0x200 [nfs]
[ 1188.725375] [<c113efda>] ? user_path_at+0x4a/0x80
[ 1188.725380] [<fb0ea50f>] nfs_revalidate_inode+0x2f/0x50 [nfs]
[ 1188.725384] [<fb0ea5d6>] nfs_getattr+0x56/0x110 [nfs]
[ 1188.725387] [<c1136a32>] vfs_getattr+0x42/0x70
[ 1188.725391] [<fb0ea580>] ? nfs_getattr+0x0/0x110 [nfs]
[ 1188.725393] [<c1136acd>] vfs_fstatat+0x6d/0x90
[ 1188.725395] [<c1136b40>] vfs_stat+0x20/0x30
[ 1188.725397] [<c1136eb6>] sys_stat64+0x16/0x30
[ 1188.725399] [<c1133ccd>] ? fput+0x1d/0x30
[ 1188.725401] [<c1130a0e>] ? filp_close+0x4e/0x70
[ 1188.725403] [<c105e29e>] ? sys_time+0x1e/0x60
[ 1188.725405] [<c100ab5f>] sysenter_do_call+0x12/0x28

[Robert Dyer (psybers)]

As we already stated, this problem can be worked around by decreasing the nesting depth in the Files&Folders plugin. Then your system will suspend fine. This is a valid workaround and probably the only thing that you can do until Chris gets around to completely changing how Do indexes items.

[Mario B. (boonekamp-deactivatedaccount-deactivatedaccount)]

Hi Robert,

unfortunately I can't confirm the workaround. My setup consists of 3 entrys: /home (1), /home/mario (2) and /media (1). Funny enough I can't reproduce the issue 100%. But: if the problem occurs I can reproduce it a few times and it disappears immediately if I deactivate the Files and Folders plugin.

I'm going to try a custom hook soon. Maybe it helps to shutdown Do before suspending and restart it after resume.

[Chris Halse Rogers (raof)]

There seems to be a pattern here - everyone with problems seems to be
indexing files NFSv3 mounts, and this is where the kernel trace shows
suspend is dying.

I'm not really sure what we could be doing to make NFS unhappy, though,
and it's not a setup that I personally have.

I suspect that this is an NFS bug we're hitting, but I'm not sure how or
what.

[Mario B. (boonekamp-deactivatedaccount-deactivatedaccount)]

Good point, Chris! Indeed, I've had an entry in my setup that pointed to an NFS location. First I tried to unmount the NFS share before suspending with no avail. After kicking the NFS entry out of the Files and Folders plugin I am not able to reproduce the suspend issue. If I add the NFS share the issue is back again.

[Mario B. (boonekamp-deactivatedaccount-deactivatedaccount)]

Forgot to say that this seems to be not an NFS bug in my opinion. E.g. I am able to play mp3 files with totem via NFS. While listening I can suspend and resume without problems. Totem even continues playing at that point of the song where it stopped. So it's not a problem in general that an NFS share is in use.