* Robert Watson <[EMAIL PROTECTED]> [20041025 14:24]: > > On Mon, 25 Oct 2004, Joan Picanyol wrote: > > > > Is there an response to the request? If not, that might suggest the > > > server is wedged, not the client. If you are willing to share the results > > > of a tcpdump -s 1500 -w <whatever> output from a few seconds during the > > > wedge, that would be very useful. > > > > Available at http://biaix.org/pk/debug/nfs/ These are from just after > > logging in to GNOME until gconfd-2 goes to nfsfsync, and the nfs server > > not responding messages start appearing. >
[snip *much* appreciated detailed analysis] > So if possible, I might try some of the following: [...] > - I think someone already suggested disabling hardware checksumming, but > if you haven't tried that, it would be worth trying it. No difference. > - It would be useful to see if less complicated NFS meta-transactions than > "Start GTK" can trigger the problem. For example, doing a large dd to a > file in NFS, varying the blocksize to see if you can find useful > thresholds that trigger the problem. I see a lot of successful 512 byte > writes in the trace, but larger datagram sizes of 8192 for writes seem > to have problems. Now this is interesting: dd if=/dev/urandom of=/fs/bulk/mount/dummy bs=512 count=14 wedges the NFS mount point 100% of the times. Lowering the count to 13 doesn't reproduce the hang. An another possibly interesting data point is that NFS over TCP works ok. For this I'm particularly grateful, since I can now mount my /home fs and do my work. Am I the only one seeing this? tks -- pica _______________________________________________ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
