on nfs_wait_bit_uninterruptible. There is no further communication
between the client and the server.
--
Leszek Urbanski
http://monolight.cc/
--
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http
20100802115021.ga13...@moo.pl; from Leszek Urbanski on Mon, Aug 02, 2010 at
13:50:21 +0200
20100727153041.ga5...@galadriel.inutil.org; from Moritz Muehlenhoff on Tue,
Jul 27, 2010 at 11:30:41 -0400
It should be applied upstream, before we can pull it into the Debian
kernel (ideally
20100727153041.ga5...@galadriel.inutil.org; from Moritz Muehlenhoff on Tue,
Jul 27, 2010 at 11:30:41 -0400
It should be applied upstream, before we can pull it into the Debian
kernel (ideally through 2.6.32.x).
https://bugzilla.kernel.org/show_bug.cgi?id=16056#c18
Comment #18 From Trond
There is a new (less invasive) patch available.
https://bugzilla.kernel.org/attachment.cgi?id=27235 (for mainline)
https://bugzilla.kernel.org/attachment.cgi?id=27246 (for 2.6.32.x)
--
Leszek Tygrys Urbanski, SCSA, SCNA
Unix-to-Unix Copy Program; said PDP-1. You will never find a more
Package: linux-2.6
Version: 2.6.32-15
Severity: important
This bug in present in all 2.6.32.x, 33.x and 34.x kernels.
It is a regression in NFS code. When copying a large file (larger than
the amount of available physical memory) to an NFS-mounted filesystem,
swapper and rpciod on the client
I'm experiencing the same problem on multi-vcpu domUs. The dom0 and domUs are
2.6.26-17lenny2 on amd64 or i386. When a domU hangs it's stuck in r state
on at least one vcpu, the network stack and the console are unresponsive.
--
Leszek Urbanski
--
To UNSUBSCRIBE, email to debian-kernel-requ
6 matches
Mail list logo
