Sorry to ressurect an old thread, but I did all of this but the problem
still persisted.
I have some 25+ clients connected to NFS server.
When i dug into the clients, it was 2 of them with connection failures
(one on the eth card, another the cable was damaged)...
When I corrected those
I confirm also that the proposed kernel changes #56 fixes this issue.
Problem still occurs with #55. See attached package versions which work.
Sorry, took me ages to work out how to install proposed kernel changes
to test this. :-)
** Attachment added: Unbutu Server 14.04 Linux Package versions
Using henrix's -proposed kernel appears to resolve the issue for me.
Under 3.13.0-32-generic #56-Ubuntu, Kworker is no longer running away,
whereas before under *.30-generic #55 it was.
My setup is a server with a nfs client on a KVM VM coming in over
openvswitch. Restarting the NFS client VM
tags:added: verification-done-trusty
** Tags removed: verification-needed-trusty
** Tags added: verification-done-trusty
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1322407
Title:
Thanks, Andrew, for testing and for updating the tags. I have just
tested the -proposed kernel and can confirm the fix, too. You beat me by
an hour or so in adding verification-done-trusty.
Mark
--
You received this bug notification because you are a member of Kernel
Packages, which is
** Branch linked: lp:ubuntu/trusty-proposed/linux-keystone
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1322407
Title:
NFS kernel server creates a kworker with 100% CPU usage, then
I have the same issue on Ubuntu 12.04 LTS using Trusty kernel:
Linux version 3.13.0-29-generic (buildd@roseapple) (gcc version 4.6.3
(Ubuntu/Linaro 4.6.3-1ubuntu5) ) #53~precise1-Ubuntu SMP Wed Jun 4
22:06:25 UTC 2014
Distributor ID: Ubuntu
Description:Ubuntu 12.04.4 LTS
Release:
This bug is awaiting verification that the kernel in -proposed solves
the problem. Please test the kernel and update this bug with the
results. If the problem is solved, change the tag 'verification-needed-
trusty' to 'verification-done-trusty'.
If verification is not done by 5 working days from
** Branch linked: lp:ubuntu/precise-proposed/linux-lts-trusty
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1322407
Title:
NFS kernel server creates a kworker with 100% CPU usage, then
It might be a bit unclear but the main task is fix released because Utopic
(14.10 and current trunk) is based on 3.15 right now (will move to 3.16 before
release). So Utopic is ok. For Trusty this is still in the mill. The patches
have references to this report. So you should see an automatic
I appear to still having this issue, despite the fix being release.
3.13.0-29-generic
Happy to provide more details.
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1322407
Title:
NFS
Problem exists on 3.13.0-29-generic. Clean 14.04 server install. Export
of root sub folder. NFSv4. Client 12.04 mount. Kworker 100% every time
the folder is accessed. Testing on a single server and single client.
--
You received this bug notification because you are a member of Kernel
Packages,
Linux 3.13.0-29-generic #53-Ubuntu SMP Wed Jun 4 21:00:20 UTC 2014
x86_64 x86_64 x86_64 GNU/Linux
I have this problem. Any suggestion how to fix it? Do this require
upgrading to newer version of kernel?
--
You received this bug notification because you are a member of Kernel
Packages, which is
Any confirmed release date for the fixed kernel? I'm using Stefan's
custom build which fixes the problem.
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1322407
Title:
NFS kernel server
FIX CONFIRMED. I can confirm that Stefan's fix in #18 resolves my issue,
and is unrelated to Trados.
Many thanks Stefan.
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1322407
Title:
Thanks Mark. I will propose those for 14.04 (Trusty) then.
** Also affects: linux (Ubuntu Trusty)
Importance: Undecided
Status: New
** Changed in: linux (Ubuntu Trusty)
Importance: Undecided = High
** Changed in: linux (Ubuntu Trusty)
Status: New = In Progress
** Changed
The fix-released for the development kernel is based on both patches
being in the 3.14.4 upstream stable tree.
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1322407
Title:
NFS kernel
FIX CONFIRMED. We have been operating with the new NFS server for
several days, and the runaway kworker has not reappeared. Not even once.
The NFS daemon has never hung during these days.
I'd say this is it. Thanks, Stefan.
--
You received this bug notification because you are a member of
Preliminary results: This fixed it.
I say preliminary, because we tested it only for a short moment. After
some heavy Trados use yesterday, the NFS kernel daemon hung again (rpc
timeout, probably choked on its own connect/reconnect state queue), I
installed the kernel packages you prepared. We
Deeper inspection of the logs looks like the problem is some connection
attempt when xprt is not connected. Part of that procedure is to re-use
the connection which forces the xprt to disconnect (so the socket can be
re-used). This triggers a state change (TCP_CLOSE) and wakes up the task
waiting
** Tags removed: kernel-key
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1322407
Title:
NFS kernel server creates a kworker with 100% CPU usage, then hangs
randomly
Status in
Now this also explains why I had a hard time (iow was not being able to)
reproducing this here. Since this indeed is a rather unusual corner
case, I can put it a little lower on the list. Still I would try to
understand the debug output enough to have some better idea about how
that windows app is
Well, I am game.
I'll safely assume that Trados is rather one of the less-frequently used
programs in this community, so it is obviously up to me to run the
actual tests. If you could help me by suggesting debugging functions or
actions, I'll gladly provide more information.
--
You received
If /proc/mounts shows nvsvers=4 I would assume as well that nfsv4 is
used. Formally I had the feeling that the examples looked like for
really using nfsv4 one would need to have one entry in /etc/exports
declaring a fsid=0 (iow the root) and then clients would ask for paths
relative to that root.
I saw the thread with the /etc/exports entry that has fsid=0 (export
filesystem root), and, of course, I tried that. Somehow, I did not get
any valid exports when, for example, using
/home 192.168.1.0/255.255.255.0(rw,fsid=0,root_squash,no_subtree_check)
/home/samba
I made one more observation, and it is fully reproducible. Frankly, it
would appear that the bug may not be as impactful as originally though
(if this is a bug, to begin with). Here it is:
On one of the Linux clients, Windows runs in Virtualbox. The NFS share
is mounted within the Linux host, and
OK -- bug can be reproduced. Here is an interesting observation: When a
*second* nfs server is connected to the network , the bug seems to be
suppressed, for what it's worth. This one really puzzles me. The runaway
kworker appeared only after I shut down the old server.
As for debugging, the
One more observation that I'll post here as *TENTATIVE*. All clients
are , as I wrote earlier, 12.04 clients. The bug, as described above,
occurs whenever one of the client's fstab entry uses the nfs filesystem:
192.168.1.2:/home /marcato/home nfs
Strike #11 above. Observation is not correct. The runaway kworker
appears even when all clients use nfs4.
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1322407
Title:
NFS kernel
Funny you should mention timing... right now, the server does not show
the runaway kworker. nfds faithfully spits out a few debug messages per
second, but acts normally otherwise. I have put the server back in
production, see if I can catch the runaway kworker when I have more
users -- I'll get
Probably the relevant part I missed initially is that probably this involves
connections going on and succeeding for a bit and fail at some point. Where it
is unclear how many connections have been going on and so on.
The function tracing you did does show that there is some kind of loop going
A few bits for clarification before I get started: (1) Your suggested
value, 524287, clearly is 0x7. This is (RPCDBG_ALL | 0x78000), i.e.,
with four extra bits, correct?
(2) I guess I can harvest the debug messages from /var/log/syslog,
correct? Meaning, once the kworker runs amok, I simply
Oh, sorry, actually it was just me hitting too many Fs. So 32767
(0x7fff) should be enough. I guess the other value is ok, too just sets
too many bits in the mask.
Yes, the messages should end up in syslog. With all debugging turned on
there will be quite a bit of logging going on. Hope this does
** Changed in: linux (Ubuntu)
Importance: Undecided = High
** Tags added: kernel-key
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1322407
Title:
NFS kernel server creates a
Can you be more specific about the configuration of the server
(/etc/exports,/etc/defaul/nfs-*) and what kind of client you use. I just
tried this on two VMs and saw not issues (at least with a basic NFSv4
setup).
--
You received this bug notification because you are a member of Kernel
Packages,
/etc/exports has one line that is not a comment:
/home 192.168.1.0/255.255.255.0(rw,sync,root_squash,no_subtree_check)
/etc/defaults/nfs-common:
NEED_STATD=no
# Options for rpc.statd.
STATDOPTS=
# Do you want to start the gssd daemon? It is required for Kerberos mounts.
NEED_GSSD=no
Oh, and maybe of less relevance, but to keep it complete, here is the
output of top:
top - 13:46:47 up 5 days, 56 min, 2 users, load average: 1.00, 0.97, 1.01
Tasks: 172 total, 2 running, 170 sleeping, 0 stopped, 0 zombie
%Cpu(s): 0.0 us, 12.0 sy, 0.0 ni, 83.3 id, 0.0 wa, 4.8 hi, 0.0
37 matches
Mail list logo
