>>>>> " " == Rik van Riel <riel@nl.linux.org> writes:
> On Wed, 9 Feb 2000, Miklos Szeredi wrote:
>> bcica:~ # ps lw 7577 FLAGS UID PID PPID PRI NI SIZE RSS WCHAN
>> STA TTY TIME COMMAND 8100 10348 7577 1 0 0 3840 2284
>> rpc_execute D ? 0:00 ./gkeeper
>>
>> This is the second time in two days, that a process gets stuck
>> in rpc_execute. It is the same program, run as non-root, trying
>> to do an ordinary F_SETLKW fcntl() for a read lock.
> Let me guess, this happened at a time when there was heavy
> memory pressure?
Most of the code in then NFS/lockd/sunrpc uses the rpc_allocate()
function, which sleeps when memory is too low. Normally this sort of
thing should therefore not be a problem. There are a few exceptions
though (have a look at nlmproc_cancel() for a particulary evil
example)...
If something is sleeping in rpc_execute() though, the reasons are
likely to be more complex. rpc_execute() does not allocate any memory,
but is the main function for the SunRPC finite state machine. It may
be that the locking request is blocking for some reason. I'd need a
tcpdump and possibly a dump of the RPC debugging code in order to say
more.
Cheers,
Trond
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Tue Feb 15 2000 - 21:00:16 EST