From Bugzilla Helper: User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; InfoPath.1) Description of problem: We have a RHEL client that is mounting some shares from a NAS device via NFS (version 3). The client has been running various flavors of RHEL 3 for a couple of years now without issue. We recently upgraded to RHEL4 (u4) with all applicable patches and now we see the NFS mount freeze up after a period of time (usually overnight). If we kill the processes trying to access the mounts, unmount, and remount the shares, everything is fine until the next occurence. The only error message we see in /var/log/messages is: kernel: RPC: error 512 connecting to server xxx.xxx.xxx.xxx Version-Release number of selected component (if applicable): kernel-2.6.9-42.0.3 How reproducible: Always Steps to Reproduce: 1.Mount an NFS share using the default options plus intr. 2.Have some process access the share over a period of time. 3. Actual Results: After a period of time, data on the mounts cannot be accessed. Expected Results: Additional info: This seems similar to a problem that was discussed in the NFSv4 mailing list even though we are not trying to use NFSv4. The discussion referenced bugzilla bug 194793 but I was unable to get access to that particular bug id when I logged in to bugzilla. Also, I am running the EL.SMP version of the kernel (2 CPUS). Our remaining clients which are still running RHEL3 (update 6) are not experiencing this issue even though they are mounting the same shares and running the same processes.
This sort of thing works for me. I do it all of the time. Perhaps a stacktrace of all of the processes in the system, when the hangs occurs could be attached, please?
Same Problem here. A long tcpdump reveiled outgoing TCP Connects from NFS Client Port 664, but no answers from the server. Research pointed to an IPMI Card see http://lkml.org/lkml/2006/10/10/239
You can fix this using sysctl root@host:~> sysctl -w sunrpc.min_resvport=665 to make it permanent add the following line to /etc/sysctl.conf sunrpc.min_resvport = 665
Changing the default setting for xprt_min_resvport does seem like a good thing to do. Changing the default would also match the RHEL-5 kernel as well as upstream.
Created attachment 143922 [details] Proposed patch
Mike, can you tell if this is the problem that you are seeing?
This request was evaluated by Red Hat Product Management for inclusion in a Red Hat Enterprise Linux maintenance release. Product Management has requested further review of this request by Red Hat Engineering, for potential inclusion in a Red Hat Enterprise Linux Update release for currently deployed products. This request is not yet committed for inclusion in an Update release.
(In reply to comment #2) > Same Problem here. A long tcpdump reveiled outgoing TCP Connects from NFS Client > Port 664, but no answers from the server. > Research pointed to an IPMI Card see http://lkml.org/lkml/2006/10/10/239 Clarification: The IPMI Board swallows all packages directed to Port 664 (used by ipmi for RPC calls). All Server answers will be hidden from the Client OS. Problem hast been fixed in linux Kernels starting with 2.6.19 by raising the minimum RPC port used by NFS to Port 665.
QE ack for RHEL4.5.
Posted to rhkernel-list.
committed in stream U5 build 45. A test kernel with this patch is available from http://people.redhat.com/~jbaron/rhel4/
looks like the fix for this one is in -48, there is nothing in sysctl.conf on this system that would be setting min_resvport. [root@dhcp58-247 sunrpc]# cat min_resvport 665 [root@dhcp58-247 sunrpc]# cat max_resvport 1023
An advisory has been issued which should help the problem described in this bug report. This report is therefore being closed with a resolution of ERRATA. For more information on the solution and/or where to find the updated files, please follow the link below. You may reopen this bug report if the solution does not work for you. http://rhn.redhat.com/errata/RHBA-2007-0304.html