In the last episode (Mar 14), Steve Sizemore said: > > That's ... odd. However, the Solaris rpc.lockd does some strange caching > > that can lead to asymmetric behavior. > > > > In addition, you are running Solaris 2.5 which qualifies as practically > > prehistoric in computer time. That's going to activate some old > > mechanisms which FreeBSD may or may not support. > > OK, that was a typo - it's really 2.6. Not quite so ancient. However, > I also have a Solaris 8 machine that has the same behavior, so I've > used it to generate the requested output.
Oops. You appended a decoded dump again. I should have told you how to generate a raw tcpdump log. Add "-s 1500 -w file.pcap" to the tcpdump commandline. You won't get any output to the screen, but the raw packet contents will get written to the file. You can replay it with tcpdump -r, or load it into ethereal and view the packets in the GUI. > > Several areas are suspect: > > > > 1) RPC can't agree on a protocol version with Solaris 2.5 > > 2) NFS can't agree on a protocol version with Solaris 2.5 > > 3) The lock attempt itself is broken Judging by the truss, I'd say #3 > Note that the program now has been simplified to do only the lock, > since it's no longer necessary to unlock the file to get it to hang. > Here's the demo program - Runs fine on my Solaris 2.6 and 2.7 machines, so it's not a Solaris->FreeBSD specific problem. > open("/home/cosmology/steve/lock_file", O_RDWR) = 3 > fstat(3, 0x000C0A2C) = 0 > fcntl(3, F_SETFD, 0x00000001) = 0 > llseek(3, 0, SEEK_CUR) = 0 > Received signal #2, SIGINT, in fcntl() [default] > fcntl(3, F_SETLKW, 0xFFBEF790) Err#4 EINTR > *** process killed *** Ok, it definitely dies trying to lock the file. Check to make sure that rpc.lockd is still running on the FreeBSD server. I have seen it coredump on a couple of my 4.5 servers and the result was what you're seeing here (lock attempts hang). -- Dan Nelson [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message