Package: linux-2.6
Severity: normal


On different machines (Dell Optiplex GX270, GX280, 390) with different
versions of the Kernel (x86 2.6.35, amd64 3.0.0) suspend from the kernel
fails if a user who's home directory is on a krb5/nfs4 server.

The kernel seems to be unable to freeze user tasks doing nfs ops.

Here's a bit of syslog that looks relevant:


Sep 22 12:49:45 medic kernel: [85320.038047] PM: Syncing filesystems ... done.
Sep 22 12:49:45 medic kernel: [85320.039687] PM: Preparing system for mem sleep
Sep 22 12:50:05 medic kernel: [85320.238666] Freezing user space processes ...
Sep 22 12:50:05 medic kernel: [85340.250049] Freezing of tasks failed after 20.01 seconds (3 tasks refusing to freeze, wq_busy=0):
Sep 22 12:50:05 medic kernel: [85340.250070] nm-applet D ffff88012666f060 0 4428 4332 0x00800004
Sep 22 12:50:05 medic kernel: [85340.250076] ffff88012666f060 0000000000000082 0000000000000003 0000000000000000
Sep 22 12:50:05 medic kernel: [85340.250089] ffff880126ee8870 0000000000012800 ffff880127e0ffd8 ffff880127e0ffd8
Sep 22 12:50:05 medic kernel: [85340.250092] 0000000000012800 ffff88012666f060 0000000000012800 0000000000012800
Sep 22 12:50:05 medic kernel: [85340.250095] Call Trace:
Sep 22 12:50:05 medic kernel: [85340.250101] [<ffffffff81071f28>] ? arch_local_irq_save+0x14/0x1d
Sep 22 12:50:05 medic kernel: [85340.250112] [<ffffffffa030723a>] ? rpc_queue_empty+0x28/0x28 [sunrpc]
Sep 22 12:50:05 medic kernel: [85340.250116] [<ffffffffa030726c>] ? rpc_wait_bit_killable+0x32/0x36 [sunrpc]
Sep 22 12:50:05 medic kernel: [85340.250120] [<ffffffff81335dec>] ? __wait_on_bit+0x3e/0x71
Sep 22 12:50:05 medic kernel: [85340.250122] [<ffffffff81335e8d>] ? out_of_line_wait_on_bit+0x6e/0x77
Sep 22 12:50:05 medic kernel: [85340.250126] [<ffffffffa030723a>] ? rpc_queue_empty+0x28/0x28 [sunrpc]
Sep 22 12:50:05 medic kernel: [85340.250129] [<ffffffff810600ad>] ? autoremove_wake_function+0x2a/0x2a
Sep 22 12:50:05 medic kernel: [85340.250133] [<ffffffffa0301c7a>] ? rpc_run_task+0xcc/0xd4 [sunrpc]
Sep 22 12:50:05 medic kernel: [85340.250141] [<ffffffffa0367e6a>] ? nfs4_run_open_task+0xdc/0x109 [nfs]
Sep 22 12:50:05 medic kernel: [85340.250149] [<ffffffffa03728be>] ? nfs4_get_open_state+0xdc/0x130 [nfs]
Sep 22 12:50:05 medic kernel: [85340.250155] [<ffffffffa036abd8>] ? nfs4_do_open.clone.26+0x149/0x38a [nfs]
Sep 22 12:50:05 medic kernel: [85340.250160] [<ffffffffa036ae38>] ? nfs4_atomic_open+0x1f/0x37 [nfs]
Sep 22 12:50:05 medic kernel: [85340.250165] [<ffffffffa0353a94>] ? nfs_open_revalidate+0xee/0x19d [nfs]
Sep 22 12:50:05 medic kernel: [85340.250167] [<ffffffff811051c9>] ? walk_component+0x249/0x3ce
Sep 22 12:50:05 medic kernel: [85340.250169] [<ffffffff81103b49>] ? exec_permission+0x1f/0x7d
Sep 22 12:50:05 medic kernel: [85340.250171] [<ffffffff8110620a>] ? link_path_walk+0x91/0x442
Sep 22 12:50:05 medic kernel: [85340.250173] [<ffffffff811057c6>] ? do_last+0xee/0x584
Sep 22 12:50:05 medic kernel: [85340.250175] [<ffffffff81106ece>] ? path_openat+0xc7/0x349
Sep 22 12:50:05 medic kernel: [85340.250180] [<ffffffffa035ccd4>] ? atomic_inc+0x4/0x4 [nfs]
Sep 22 12:50:05 medic kernel: [85340.250183] [<ffffffff810b6965>] ? __filemap_fdatawrite_range+0x4b/0x50
Sep 22 12:50:05 medic kernel: [85340.250186] [<ffffffff8103840a>] ? should_resched+0x5/0x24
Sep 22 12:50:05 medic kernel: [85340.250188] [<ffffffff8110717c>] ? do_filp_open+0x2c/0x72
Sep 22 12:50:05 medic kernel: [85340.250190] [<ffffffff813358d7>] ? _cond_resched+0x9/0x20
Sep 22 12:50:05 medic kernel: [85340.250193] [<ffffffff811aca91>] ? __strncpy_from_user+0x19/0x4a
Sep 22 12:50:05 medic kernel: [85340.250195] [<ffffffff811104ec>] ? alloc_fd+0x69/0x110
Sep 22 12:50:05 medic kernel: [85340.250198] [<ffffffff810fb41c>] ? do_sys_open+0x5f/0xe6
Sep 22 12:50:05 medic kernel: [85340.250200] [<ffffffff8133bd12>] ? system_call_fastpath+0x16/0x1b
Sep 22 12:50:05 medic kernel: [85340.250203] gnome-screensav D ffff880127134400 0 4447 1 0x00800004
Sep 22 12:50:05 medic kernel: [85340.250205] ffff880127134400 0000000000000086 ffff88012ec52800 ffff88012ec52800
Sep 22 12:50:05 medic kernel: [85340.250207] ffff880126b095d0 0000000000012800 ffff88011ff39fd8 ffff88011ff39fd8
Sep 22 12:50:05 medic kernel: [85340.250210] 0000000000012800 ffff880127134400 0000000000012800 0000000000012800
Sep 22 12:50:05 medic kernel: [85340.250212] Call Trace:
Sep 22 12:50:05 medic kernel: [85340.250214] [<ffffffff81071f28>] ? arch_local_irq_save+0x14/0x1d
Sep 22 12:50:05 medic kernel: [85340.250219] [<ffffffffa030723a>] ? rpc_queue_empty+0x28/0x28 [sunrpc]
Sep 22 12:50:05 medic kernel: [85340.250223] [<ffffffffa030726c>] ? rpc_wait_bit_killable+0x32/0x36 [sunrpc]
Sep 22 12:50:05 medic kernel: [85340.250225] [<ffffffff81335dec>] ? __wait_on_bit+0x3e/0x71
Sep 22 12:50:05 medic kernel: [85340.250227] [<ffffffff81335e8d>] ? out_of_line_wait_on_bit+0x6e/0x77
Sep 22 12:50:05 medic kernel: [85340.250231] [<ffffffffa030723a>] ? rpc_queue_empty+0x28/0x28 [sunrpc]
Sep 22 12:50:05 medic kernel: [85340.250233] [<ffffffff810600ad>] ? autoremove_wake_function+0x2a/0x2a
Sep 22 12:50:05 medic kernel: [85340.250237] [<ffffffffa0301c7a>] ? rpc_run_task+0xcc/0xd4 [sunrpc]
Sep 22 12:50:05 medic kernel: [85340.250243] [<ffffffffa036b7fd>] ? nfs4_do_close+0x182/0x1c0 [nfs]
Sep 22 12:50:05 medic kernel: [85340.250248] [<ffffffffa035575a>] ? __put_nfs_open_context+0x8e/0xb6 [nfs]
Sep 22 12:50:05 medic kernel: [85340.250253] [<ffffffffa0355eab>] ? nfs_release+0x7a/0x81 [nfs]
Sep 22 12:50:05 medic kernel: [85340.250255] [<ffffffff810fcc74>] ? fput+0xfa/0x1a2
Sep 22 12:50:05 medic kernel: [85340.250257] [<ffffffff810fa2d9>] ? filp_close+0x62/0x6a
Sep 22 12:50:05 medic kernel: [85340.250259] [<ffffffff810fa368>] ? sys_close+0x87/0xc4
Sep 22 12:50:05 medic kernel: [85340.250261] [<ffffffff8133bd12>] ? system_call_fastpath+0x16/0x1b
Sep 22 12:50:05 medic kernel: [85340.250264] dbus-daemon-lau D ffff880126a7cea0 0 4621 4620 0x00800004
Sep 22 12:50:05 medic kernel: [85340.250266] ffff880126a7cea0 0000000000000086 ffff880127e47fd8 ffffffff8126cfcd
Sep 22 12:50:05 medic kernel: [85340.250268] ffff880129899610 0000000000012800 ffff880127e47fd8 ffff880127e47fd8
Sep 22 12:50:05 medic kernel: [85340.250271] 0000000000012800 ffff880126a7cea0 0000000000012800 0000000000012800
Sep 22 12:50:05 medic kernel: [85340.250273] Call Trace:
Sep 22 12:50:05 medic kernel: [85340.250275] [<ffffffff8126cfcd>] ? kernel_sendmsg+0x31/0x3f
Sep 22 12:50:05 medic kernel: [85340.250277] [<ffffffff81071f28>] ? arch_local_irq_save+0x14/0x1d
Sep 22 12:50:05 medic kernel: [85340.250281] [<ffffffffa030723a>] ? rpc_queue_empty+0x28/0x28 [sunrpc]
Sep 22 12:50:05 medic kernel: [85340.250285] [<ffffffffa030726c>] ? rpc_wait_bit_killable+0x32/0x36 [sunrpc]
Sep 22 12:50:05 medic kernel: [85340.250288] [<ffffffff81335dec>] ? __wait_on_bit+0x3e/0x71
Sep 22 12:50:05 medic kernel: [85340.250291] [<ffffffff8104bc95>] ? _local_bh_enable_ip.clone.8+0x20/0x8c
Sep 22 12:50:05 medic kernel: [85340.250293] [<ffffffff81335e8d>] ? out_of_line_wait_on_bit+0x6e/0x77
Sep 22 12:50:05 medic kernel: [85340.250297] [<ffffffffa030723a>] ? rpc_queue_empty+0x28/0x28 [sunrpc]
Sep 22 12:50:05 medic kernel: [85340.250299] [<ffffffff810600ad>] ? autoremove_wake_function+0x2a/0x2a
Sep 22 12:50:05 medic kernel: [85340.250301] [<ffffffff81336c0c>] ? _raw_spin_lock_bh+0xe/0x1c
Sep 22 12:50:05 medic kernel: [85340.250306] [<ffffffffa0307e7b>] ? __rpc_execute+0xe5/0x27f [sunrpc]
Sep 22 12:50:05 medic kernel: [85340.250307] [<ffffffff81060070>] ? wake_up_bit+0x10/0x23
Sep 22 12:50:05 medic kernel: [85340.250311] [<ffffffffa0301c7a>] ? rpc_run_task+0xcc/0xd4 [sunrpc]
Sep 22 12:50:05 medic kernel: [85340.250314] [<ffffffffa0301d62>] ? rpc_call_sync+0x3b/0x5b [sunrpc]
Sep 22 12:50:05 medic kernel: [85340.250321] [<ffffffffa0369eeb>] ? _nfs4_proc_access+0xf2/0x147 [nfs]
Sep 22 12:50:05 medic kernel: [85340.250324] [<ffffffff812ea5f1>] ? unix_stream_recvmsg+0x46d/0x488
Sep 22 12:50:05 medic kernel: [85340.250330] [<ffffffffa0369f65>] ? nfs4_proc_access+0x25/0x4a [nfs]
Sep 22 12:50:05 medic kernel: [85340.250334] [<ffffffffa0353586>] ? nfs_do_access+0x181/0x3a2 [nfs]
Sep 22 12:50:05 medic kernel: [85340.250339] [<ffffffffa0353873>] ? nfs_permission+0xcc/0x16c [nfs]
Sep 22 12:50:05 medic kernel: [85340.250340] [<ffffffff81103b49>] ? exec_permission+0x1f/0x7d
Sep 22 12:50:05 medic kernel: [85340.250342] [<ffffffff8110620a>] ? link_path_walk+0x91/0x442
Sep 22 12:50:05 medic kernel: [85340.250344] [<ffffffff811066b9>] ? path_lookupat+0x52/0x335
Sep 22 12:50:05 medic kernel: [85340.250346] [<ffffffff810383fc>] ? need_resched+0x1a/0x23
Sep 22 12:50:05 medic kernel: [85340.250349] [<ffffffff8103840a>] ? should_resched+0x5/0x24
Sep 22 12:50:05 medic kernel: [85340.250351] [<ffffffff813358d7>] ? _cond_resched+0x9/0x20
Sep 22 12:50:05 medic kernel: [85340.250353] [<ffffffff811069b8>] ? do_path_lookup+0x1c/0x87
Sep 22 12:50:05 medic kernel: [85340.250354] [<ffffffff81106d9e>] ? user_path_at+0x46/0x78
Sep 22 12:50:05 medic kernel: [85340.250357] [<ffffffff81339aba>] ? do_page_fault+0x2d3/0x30e
Sep 22 12:50:05 medic kernel: [85340.250359] [<ffffffff810ed34e>] ? kmem_cache_free+0x2d/0x69
Sep 22 12:50:05 medic kernel: [85340.250362] [<ffffffff810ff2c9>] ? vfs_fstatat+0x40/0x6d
Sep 22 12:50:05 medic kernel: [85340.250364] [<ffffffff8110bdef>] ? dput+0xdb/0xea
Sep 22 12:50:05 medic kernel: [85340.250366] [<ffffffff810ff3fb>] ? sys_newstat+0x11/0x29
Sep 22 12:50:05 medic kernel: [85340.250368] [<ffffffff81111db9>] ? mnt_get_count+0x32/0x41
Sep 22 12:50:05 medic kernel: [85340.250370] [<ffffffff811110a8>] ? cpumask_next+0x18/0x1d
Sep 22 12:50:05 medic kernel: [85340.250372] [<ffffffff813370d5>] ? page_fault+0x25/0x30
Sep 22 12:50:05 medic kernel: [85340.250374] [<ffffffff8133bd12>] ? system_call_fastpath+0x16/0x1b
Sep 22 12:50:05 medic kernel: [85340.250376]
Sep 22 12:50:05 medic kernel: [85340.250376] Restarting tasks ... done.
Sep 22 12:50:05 medic kernel: [85340.282674] r8169 0000:04:00.0: eth0: link down
Sep 22 12:50:05 medic kernel: [85340.282680] r8169 0000:04:00.0: eth0: link down
Sep 22 12:50:05 medic kernel: [85340.282918] ADDRCONF(NETDEV_UP): eth0: link is not ready
Sep 22 12:50:07 medic kernel: [85342.043256] r8169 0000:04:00.0: eth0: link up
Sep 22 12:50:07 medic kernel: [85342.043630] ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
Sep 22 12:50:17 medic kernel: [85352.399328] eth0: no IPv6 routers present

-- System Information:
Debian Release: 6.0.2
APT prefers stable
APT policy: (990, 'stable'), (500, 'stable-updates'), (500, 'unstable')
Architecture: amd64 (x86_64)

Kernel: Linux 3.0.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash



--
To UNSUBSCRIBE, email to debian-kernel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20110922110124.4859.66092.reportbug@medic.calvaedi .com">http://lists.debian.org/20110922110124.4859.66092.reportbug@medic.calvaedi .com

Hi John,

John Hughes wrote:

> On different machines (Dell Optiplex GX270, GX280, 390) with different
> versions of the Kernel (x86 2.6.35, amd64 3.0.0) suspend from the kernel
> fails if a user who's home directory is on a krb5/nfs4 server.
>
> The kernel seems to be unable to freeze user tasks doing nfs ops.

What are the oldest and newest kernels you've experienced this with
(you can get kernel versions from the string starting with "Debian" in
/proc/version, or from /var/log/dpkg.log)? Is this reproducible with
a squeeze (2.6.32.y) kernel (or in other words, is it a regression)?

Thanks for writing,
Jonathan



--
To UNSUBSCRIBE, email to debian-kernel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20110922173438.GA8656@elie">http://lists.debian.org/20110922173438.GA8656@elie

John Hughes wrote:

> Redhat has a similar sounding bug:
> https://bugzilla.redhat.com/show_bug.cgi?id=717735
>
> With a patch.
>
> I'll see if I can test it.

Thanks! That bug log has a message:

| seems to be fixed in 3.1.0-0.rc6.git0.0.fc16.x86_64

and I don't see any relevant patches in the Fedora tree at
<http://pkgs.fedoraproject.org/gitweb/?p=kernel.git;a=tree>. So it
could be worth testing 3.1-rc6 from experimental, too.



--
To UNSUBSCRIBE, email to debian-kernel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20110922174215.GB8656@elie">http://lists.debian.org/20110922174215.GB8656@elie

On 22/09/11 19:34, Jonathan Nieder wrote:

Hi John,

John Hughes wrote:



On different machines (Dell Optiplex GX270, GX280, 390) with different
versions of the Kernel (x86 2.6.35, amd64 3.0.0) suspend from the kernel
fails if a user who's home directory is on a krb5/nfs4 server.

The kernel seems to be unable to freeze user tasks doing nfs ops.


What are the oldest and newest kernels you've experienced this with



I'm seeing it with:

Linux version 2.6.32-5-686 (Debian 2.6.32-35squeeze2) (dannf@debian.org)
(gcc version 4.3.5 (Debian 4.3.5-4) ) #1 SMP Fri Sep 9 20:51:05 UTC 2011


(My original bug report was wrong, I mis-read 2.6.32-5 as 2.6.35).

Also on:

Linux version 3.0.0-1-amd64 (Debian 3.0.0-4) (ben@decadent.org.uk) (gcc
version 4.5.3 (Debian 4.5.3-9) ) #1 SMP Tue Sep 20 07:03:13 UTC 2011


(installed on squeeze)



--
To UNSUBSCRIBE, email to debian-kernel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 4E7C35B2.9000202@Calva.COM">http://lists.debian.org/4E7C35B2.9000202@Calva.COM

On 22/09/11 19:42, Jonathan Nieder wrote:

Thanks! That bug log has a message:

| seems to be fixed in 3.1.0-0.rc6.git0.0.fc16.x86_64

and I don't see any relevant patches in the Fedora tree at
<http://pkgs.fedoraproject.org/gitweb/?p=kernel.git;a=tree>. So it
could be worth testing 3.1-rc6 from experimental, too.



Ah, I didn't see that message. I'll try that.






--
To UNSUBSCRIBE, email to debian-kernel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 4E7C35EF.2060901@Calva.COM">http://lists.debian.org/4E7C35EF.2060901@Calva.COM

On 23/09/11 09:31, John Hughes wrote:

On 22/09/11 19:42, Jonathan Nieder wrote:

So it
could be worth testing 3.1-rc6 from experimental, too.


Ah, I didn't see that message. I'll try that.


Nothing later than 3.1-rc4 in experimental that I can see.

And that behaves in exactly the same way.




--
To UNSUBSCRIBE, email to debian-kernel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 4E7C5191.9000105@Calva.COM">http://lists.debian.org/4E7C5191.9000105@Calva.COM

On 22/09/11 19:42, Jonathan Nieder wrote:

So it
could be worth testing 3.1-rc6 from experimental, too.



I built my own kernel from github (3.1-rc7).

Linux version 3.1.0-rc7 (john@medic) (gcc version 4.4.5 (Debian 4.4.5-8)
) #1 SMP Fri Sep 23 12:15:59 CEST 2011


Same problem.

[ 95.568860] PM: Syncing filesystems ... done.
[ 95.569423] PM: Preparing system for mem sleep
[ 95.798364] Freezing user space processes ...
[ 115.809770] Freezing of tasks failed after 20.01 seconds (3 tasks refusing to freeze, wq_busy=0):
[ 115.809789] nm-applet D ffff880125306970 0 2230 2122 0x00800004
[ 115.809795] ffff880125306970 0000000000000086 ffff88012ec12f80 ffff880125377790
[ 115.809801] 0000000000012f80 ffff88012465ffd8 ffff88012465ffd8 0000000000012f80
[ 115.809813] ffff880125306970 ffff88012465e010 ffff88012ec12f80 ffffffff81044162
[ 115.809816] Call Trace:
[ 115.809822] [<ffffffff81044162>] ? ttwu_do_wakeup+0x51/0xc8
[ 115.809832] [<ffffffffa03137dc>] ? rpc_queue_empty+0x26/0x26 [sunrpc]
[ 115.809837] [<ffffffffa031380b>] ? rpc_wait_bit_killable+0x2f/0x33 [sunrpc]
[ 115.809840] [<ffffffff81346f79>] ? __wait_on_bit+0x3e/0x6f
[ 115.809841] [<ffffffff81347018>] ? out_of_line_wait_on_bit+0x6e/0x77
[ 115.809845] [<ffffffffa03137dc>] ? rpc_queue_empty+0x26/0x26 [sunrpc]
[ 115.809848] [<ffffffff81063bf7>] ? autoremove_wake_function+0x2a/0x2a
[ 115.809852] [<ffffffffa030db02>] ? rpc_run_task+0x71/0x79 [sunrpc]
[ 115.809860] [<ffffffffa038242f>] ? nfs4_run_open_task+0xde/0x10b [nfs]
[ 115.809867] [<ffffffffa039174d>] ? nfs4_get_open_state+0x154/0x1ac [nfs]
[ 115.809873] [<ffffffffa0383041>] ? nfs4_do_open+0x11a/0x33a [nfs]
[ 115.809878] [<ffffffffa0314b14>] ? put_rpccred+0x35/0x11b [sunrpc]
[ 115.809883] [<ffffffffa038327c>] ? nfs4_atomic_open+0x1b/0x33 [nfs]
[ 115.809887] [<ffffffffa036cd2b>] ? nfs_open_revalidate+0x113/0x1db [nfs]
[ 115.809890] [<ffffffff8110b174>] ? walk_component+0x26c/0x3cb
[ 115.809892] [<ffffffff8110b3c8>] ? do_last+0xf5/0x56a
[ 115.809895] [<ffffffff8110bdaa>] ? path_openat+0xce/0x31f
[ 115.809897] [<ffffffff8110c0c8>] ? do_filp_open+0x2c/0x72
[ 115.809899] [<ffffffff81115a34>] ? alloc_fd+0x69/0x10b
[ 115.809901] [<ffffffff810ff715>] ? do_sys_open+0x61/0xe8
[ 115.809904] [<ffffffff8134d252>] ? system_call_fastpath+0x16/0x1b
...




--
To UNSUBSCRIBE, email to debian-kernel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 4E7C76B0.6020702@Calva.COM">http://lists.debian.org/4E7C76B0.6020702@Calva.COM

Well, after minor modifications (needed to include freezer.h in
fs/nfs/inode.c and net/sunrpc/sched.c) I've installed Jeff Layton's
patch from https://bugzilla.redhat.com/show_bug.cgi?id=717735 in my
3.1-rc7 kernel...


... and it seems to work.

Or at least it works a lot better.

I've suspended and restarted many times without problems.

This is on the Dell Optiplex 390 (x86_64 processor).

I will build a kernel and try on the Optiplex GX270 (x86 processor).




--
To UNSUBSCRIBE, email to debian-kernel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 4E7C980C.8050103@Calva.COM">http://lists.debian.org/4E7C980C.8050103@Calva.COM

On Fri, 23 Sep 2011 16:30:36 +0200
John Hughes <john@Calva.COM> wrote:

> Well, after minor modifications (needed to include freezer.h in
> fs/nfs/inode.c and net/sunrpc/sched.c) I've installed Jeff Layton's
> patch from https://bugzilla.redhat.com/show_bug.cgi?id=717735 in my
> 3.1-rc7 kernel...
>
> ... and it seems to work.
>
> Or at least it works a lot better.
>
> I've suspended and restarted many times without problems.
>
> This is on the Dell Optiplex 390 (x86_64 processor).
>
> I will build a kernel and try on the Optiplex GX270 (x86 processor).
>

Thanks for testing them. I actually have a revised version that
includes the right header and also fixes some other cases where the NFS
code can sleep like this. I'll see if I can get something together for
3.2.

--
Jeff Layton <jlayton@redhat.com>



--
To UNSUBSCRIBE, email to debian-kernel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20110923104030.00ada6fd@tlielax.poochiereds.net">h ttp://lists.debian.org/20110923104030.00ada6fd@tlielax.poochiereds.net

On 23/09/11 16:40, Jeff Layton wrote:

On Fri, 23 Sep 2011 16:30:36 +0200
John Hughes<john@Calva.COM> wrote:



Well, after minor modifications (needed to include freezer.h in
fs/nfs/inode.c and net/sunrpc/sched.c) I've installed Jeff Layton's
patch from https://bugzilla.redhat.com/show_bug.cgi?id=717735 in my
3.1-rc7 kernel...



Thanks for testing them. I actually have a revised version that
includes the right header and also fixes some other cases where the NFS
code can sleep like this. I'll see if I can get something together for
3.2.



Could you send me the revised version - I thought I saw one problem when
I started testing, but wrote it off to having the wrong kernel.


Anyway, thanks for the patch.





--
To UNSUBSCRIBE, email to debian-kernel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 4E7C9F40.3030303@Calva.COM">http://lists.debian.org/4E7C9F40.3030303@Calva.COM