Bug 338691 - lockd hang in D state
lockd hang in D state
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
i686 Linux
low Severity medium
: ---
: ---
Assigned To: Kernel Maintainer List
Fedora Extras Quality Assurance
Depends On:
  Show dependency treegraph
Reported: 2007-10-18 15:45 EDT by David Rees
Modified: 2008-01-16 08:08 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2008-01-16 08:08:55 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description David Rees 2007-10-18 15:45:40 EDT
I had a NFS server's lockd process hang on D state today. It stopped responding.
kill -9 didn't affect the process. A reboot cleared it up. It's the first time
I've seen this happen.

I first noticed it when NFS clients lock requests stopped responding. Rebooting
the server cleared up the problem. Before rebooting the server, I used SysRq-W
to grab the blocked state of the lockd process.

This is on kernel, running on a Dell 1420 with dual Xeon
processors (HT disabled) and 4GB of ram. Let me know if I can provide any more
information. SysRq-W output below:

SysRq : Show Blocked State
  task                PC stack   pid father
lockd         D f7364d5c  2152  1694      2
       f7364d70 00000046 00000002 f7364d5c f7364d54 00000000 f7364000 00000001 
       00000000 f7a78c00 f7a78d9c c349fa80 00000001 c4395700 00000000 00000000 
       cad59b40 f799ce90 0885e879 cad59b40 e90f6a48 ffffffff 00000000 00000000 
Call Trace:
 [<c060d512>] __mutex_lock_slowpath+0x43/0x72
 [<c060d40b>] mutex_lock+0x26/0x29
 [<f8cae533>] fh_put+0x14e/0x15e [nfsd]
 [<f8bcdfb5>] nlmsvc_traverse_blocks+0x1d/0x81 [lockd]
 [<f8bcf06c>] nlmsvc_mark_host+0x0/0x7 [lockd]
 [<f8bcf06c>] nlmsvc_mark_host+0x0/0x7 [lockd]
 [<f8bcf226>] nlm_traverse_files+0x18f/0x1d9 [lockd]
 [<f8bcc3cb>] nlm_gc_hosts+0x47/0x183 [lockd]
 [<f8bcc881>] nlm_lookup_host+0xab/0x2af [lockd]
 [<f8bccab2>] nlmsvc_lookup_host+0x2d/0x33 [lockd]
 [<f8bce224>] nlmsvc_lock+0xc7/0x307 [lockd]
 [<f8bd169f>] nlm4svc_proc_lock+0x8b/0xd4 [lockd]
 [<f8c55682>] svc_process+0x33f/0x67d [sunrpc]
 [<f8c5825d>] svc_recv+0x326/0x395 [sunrpc]
 [<f8bcd240>] lockd+0x14a/0x222 [lockd]
 [<c0404e72>] ret_from_fork+0x6/0x1c
 [<f8bcd0f6>] lockd+0x0/0x222 [lockd]
 [<f8bcd0f6>] lockd+0x0/0x222 [lockd]
 [<c0405b6b>] kernel_thread_helper+0x7/0x10
Comment 1 Christopher Brown 2008-01-15 21:47:54 EST

I'm reviewing this bug as part of the kernel bug triage project, an attempt to
isolate current bugs in the Fedora kernel.


I am CC'ing myself to this bug and will try and assist you in resolving it if I can.

There hasn't been much activity on this bug for a while. Could you tell me if
you are still having problems with the latest kernel?

If the problem no longer exists then please close this bug or I'll do so in a
few days if there is no additional information lodged.
Comment 2 David Rees 2008-01-15 22:42:18 EST
I have not seen this issue since my original report. I'm not sure what state to
put it into since none of the resolved bugzilla states seem to fit the case of
"have not seen the bug again since reporting, may or may not be resolved" so I
have not resolved the bug.
Comment 3 Christopher Brown 2008-01-16 08:08:55 EST
Hi David,

Thanks for the update - as its been three months I'll close as INSUFFICIENT_DATA
but please re-open should it re-occur. Thanks for taking the time to file the
original report.


Note You need to log in before you can comment on or make changes to this bug.