lkml.org 
[lkml]   [2001]   [Sep]   [3]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
Subject[bug report] NFS and uninterruptable wait states
Date
The other day I was trying to set up an NFS mount to my room mate's system, 
and ran into what I at least, call a bug. When I tried to mount his NFS
export, the mount command locked up, and would not die. Not even a SIGKILL
would do any good. According to ps, the mount process was in the 'D' -
uninterruptable wait state. It also looked like the WCHAN was rpc_
something. I think it was waiting for an rpc call to return in the D state,
and it never did return. The bug here is that it should NOT be waiting in
the D state for something that could never happen. For that matter, why
should anything ever need to wait in an uninterruptable state? Whenever you
wait, you should expect the possibility of being interrupted, check for that
when you wake up, and if you were, clean up and return so the signal can be
processed.

Anyhow, about an hour later ( the mount process still stuck ) I figured out
that the other machine was not running rpc.nfsd, though it was running
rpc.mountd. Once I started rpc.nfsd on the machine, the mount on my box
finally returned ( and was terminated by the SIGKILL that I sent it an hour
before ).

Could someone confirm that this is a bug, and explain why anything should
ever need to wait in that state?

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 13:02    [W:0.212 / U:1.320 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site