Hang in NFS client operation
Mohan Srinivasan
mohan_srinivasan at yahoo.com
Wed Jun 1 16:17:45 GMT 2005
Hello,
The process is waiting for the NFS reply.
If you're running NFS/TCP, do you have the latest fixes to
nfs_socket.c in -current ?
As rwatson mentioned, a network trace would be very helpful.
We can tell whether the client is retrying the request and
whether the server responds from the trace.
mohan
--- Jun Kuriyama <kuriyama at imgsrc.co.jp> wrote:
>
> Since 2005-04-09 (*), my (-current) box sometimes hang at NFS client
> operation (usually CVS update from readonly NFS mounted repository.
> Server is 5.3R).
>
> Is there something I can help debugging about this issue?
>
> -----
> db> ps
> pid proc uid ppid pgrp flag stat wmesg wchan cmd
> 7778 c3b73e00 103 7776 7767 0004000 [SLPQ nfsreq 0xc3d87e80][SLP] cvs
> ...
> db> trace 7778
> Tracing pid 7778 tid 100124 td 0xc3b6b300
> sched_switch(c3b6b300,0,1) at sched_switch+0x14f
> mi_switch(1,0,c3b6b300,1,c3b6b300) at mi_switch+0x1ba
> sleepq_switch(c3d87e80) at sleepq_switch+0x133
> sleepq_wait(c3d87e80,0,c3bc5298,0,c3d87e80) at sleepq_wait+0xb
> msleep(c3d87e80,c0721a60,53,c06c28fc,0) at msleep+0x356
> nfs_reply(c3d87e80,0,f,0,c3b6b300) at nfs_reply+0x23c
> nfs_request(c4d69aa0,c3eb1200,3,c3b6b300,c3bf0d80) at nfs_request+0x3c1
> nfs_lookup(ecf93bd8) at nfs_lookup+0x2d8
> VOP_LOOKUP_APV(c06f8ba0,ecf93bd8) at VOP_LOOKUP_APV+0x38
> lookup(ecf93c68,ecf93c14,0,c3b6b300,ecf93c90) at lookup+0x431
> namei(ecf93c68,c3bf0d80,c3dd8e00,80c3080,0) at namei+0x396
> kern_access(c3b6b300,80c3080,0,4,ecf93d30) at kern_access+0x6a
> access(c3b6b300,ecf93d04,2,2d7,286) at access+0x15
> syscall(3b,bfbf003b,bfbf003b,80c3080,80de8c0) at syscall+0x2b3
> Xint0x80_syscall() at Xint0x80_syscall+0x1f
> --- syscall (33, FreeBSD ELF32, access), eip = 0x282e6bc7, esp = 0xbfbfe47c, ebp = 0xbfbfe498
> ---
>
>
> -----
> (*) I tried to find actual commit by using binary search:
> <http://lists.freebsd.org/pipermail/cvs-src/2005-April/044449.html>
>
> > Modified files:
> > sys/kern vfs_lookup.c
> > Log:
> > - If we vrele() a dvp while the child is locked we can potentially
> > deadlock
> > when vrele() acquires the directory lock in the wrong order. Fix
> > this
> > via the following changes:
> > ...
>
>
> --
> Jun Kuriyama <kuriyama at imgsrc.co.jp> // IMG SRC, Inc.
> <kuriyama at FreeBSD.org> // FreeBSD Project
> _______________________________________________
> freebsd-current at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscribe at freebsd.org"
>
More information about the freebsd-current
mailing list