I have a machine in my network which is frequently unreachable because it is only responsible for periodic processing and suspends itself until needed.  This machine NFS exports one of it's trees.

On my workstation, I have a few of the dirs in that tree in my gnome "bookmarks".  Inevitably, gnome-panel will end up blocked trying to stat one of those dirs.  When blocked, it's kernel stack looks like:

[441564.401013]  [<f8288dcc>] rpc_wait_bit_killable+0x1c/0x40 [sunrpc]
[441564.401013]  [<c058b7fd>] __wait_on_bit+0x4d/0x70
[441564.401013]  [<f8288db0>] ? rpc_wait_bit_killable+0x0/0x40 [sunrpc]
[441564.401013]  [<f8288db0>] ? rpc_wait_bit_killable+0x0/0x40 [sunrpc]
[441564.401013]  [<c058b8cb>] out_of_line_wait_on_bit+0xab/0xc0
[441564.401013]  [<c0167850>] ? wake_bit_function+0x0/0x50
[441564.401013]  [<f828950b>] __rpc_execute+0xdb/0x280 [sunrpc]
[441564.401013]  [<c058cdbd>] ? _spin_lock+0xd/0x10
[441564.401013]  [<f82896cc>] rpc_execute+0x1c/0x20 [sunrpc]
[441564.401013]  [<f828299f>] rpc_run_task+0x2f/0x60 [sunrpc]
[441564.401013]  [<f8282ace>] rpc_call_sync+0x3e/0x60 [sunrpc]
[441564.401013]  [<f8c8ce46>] T.1082+0x36/0x60 [nfs]
[441564.401013]  [<f8c8d6f7>] nfs3_proc_access+0xa7/0x170 [nfs]
[441564.401013]  [<c058cdbd>] ? _spin_lock+0xd/0x10
[441564.401013]  [<c021ae6c>] ? d_lookup+0x3c/0x50
[441564.401013]  [<c021965e>] ? __d_free+0x2e/0x50
[441564.401013]  [<c02196bf>] ? d_free+0x3f/0x50
[441564.401013]  [<c058cdbd>] ? _spin_lock+0xd/0x10
[441564.401013]  [<f828abac>] ? rpcauth_lookup_credcache+0x12c/0x1d0 [sunrpc]
[441564.401013]  [<f8c7905d>] nfs_do_access+0x7d/0xc0 [nfs]
[441564.401013]  [<f8c79129>] nfs_permission+0x89/0x1b0 [nfs]
[441564.401013]  [<c022098f>] ? mntput_no_expire+0x1f/0xe0
[441564.401013]  [<c0212f2c>] __link_path_walk+0x7c/0xca0
[441564.401013]  [<c0213d64>] path_walk+0x54/0xc0
[441564.401013]  [<c0213ee9>] do_path_lookup+0x59/0x90
[441564.401013]  [<c0214a31>] user_path_at+0x41/0x80
[441564.401013]  [<c020c89a>] vfs_fstatat+0x3a/0x70
[441564.401013]  [<c020c930>] vfs_lstat+0x20/0x30
[441564.401013]  [<c020c959>] sys_lstat64+0x19/0x30
[441564.401013]  [<c02141fd>] ? sys_renameat+0x20d/0x240
[441564.401013]  [<c01033ec>] syscall_call+0x7/0xb

Probably nothing surprising there.  Also, while gnome-panel is blocked, attaching a strace to it and then waking up the suspended machine yields:

Process 10315 attached - interrupt to quit
lstat64("/video/mythvideo", {st_mode=S_IFDIR|0777, st_size=4096, ...}) = 0
lstat64("/data/mp3/library", 0xbfa6a26c) = -1 ENOENT (No such file or directory)
lstat64("/video/mythtv", {st_mode=S_IFDIR|0777, st_size=69632, ...}) = 0
lstat64("/mnt/cooker", {st_mode=S_IFDIR|0755, st_size=1024, ...}) = 0

The strace of course blocks after the "Process 10315 attached - interrupt to quit" and then resumes when the suspended machine wakes up and the 'lstat64("/video/mythvideo", ...)' completes and gnome-panel becomes unblocked.

Any thoughts on how to prevent this problem, other than the two obvious solutions: (a) don't suspend the machine exporting /video or (b) don't bookmark dirs in /video?