would it be possible to post a b2zip ethetreal trace
of the hang?

Created attachment 110617 [details]
tethereal log

Not that familiar with ethereal. This is a tethereal log for about
45seconds of the hang. 192.9.23.74 is the SCO server, 192.9.23.12 is
my FC3 machine. Hope this helps.

Created attachment 110622 [details]
Begining to end hang

Here is a log from the start to the finish of a hang, about 2 mins.
I greped the SCO server IP address.

hmm... there definitely appears to be a large number of 
retransmission....

To get a better look would you mind creating a binary capture
file by using the -w flag to tethereal similar to:
    tethereal -w /tmp/trace.pcap host server and host client
I should have been more explicit in my original request... 
my bad... :)

Also would it be possible to post the netstat -c stats from the 
client side and the netstat -s from the server side....

Finally, when the process hangs on the client, could you get a 
system wide trace by "echo t > /proc/sysrq-trigger", then posting 
the relevant parts from /var/log/messages....

Created attachment 110647 [details]
tethereal -w hang

Created attachment 110648 [details]
/var/log/messages

This is all that came out in /var/log/messages

Created attachment 110650 [details]
netstat -c

Created attachment 110652 [details]
netstat -s

Thanks for the info.... 

So is it valid to say this hang only happen on the v2 filesystems
and not on v3 mounted filesystems.

Yes, other nfs mounts that are exported from newer linux boxes do not
suffer from this problem. Everyone in the company that uses FC suffers
from this with our sco machines. I also saw a usenet post that someone
else was having the same problem with SCO exports.(dont know if I can
find it again).  I cant say if its a SCO specific problem or not I'm a
little suspicious though.  Older RedHat Linux versions dont seem to
have this problem, nor do our Enterprise servers that mount from SCO.

Bart

There seems to be a number of nfs mount bugs like this that
need info about the server and if it provides NFS via udp, tcp, both.
For me the older servers do not provide tcp and mount and autofs
both appear to hang.  Apparently there is a problem checking for services
and the 'wrong' type of connection is tried and hangs.
For me the critical info is 'rpcinfo'.....

  $ rpcinfo -p troubleserver | grep nfs
    100003    2   udp   2049  nfs
    100003    3   udp   2049  nfs
  $ rpcinfo -p happyserver | grep nfs
    100003    4   tcp   2049  nfs

Older Linux and older appliance software wuold be involved.
    100003    3   tcp   2049  nfs
    100003    2   tcp   2049  nfs
    100003    3   udp   2049  nfs
    100003    2   udp   2049  nfs

Our current work arround is to specify tcp/udp to match the server in the 
mount line and mount maps.

In my case the server is not SCO but an older RH release.. 
(Kernel... 2.4.20-28.8bigmem)
(the other bugzillas that might match what I see are 140631, 144556, 144758)

Could you please try the util-linux in 

http://people.redhat.com/steved/bz152956

It fixes a problem that appears to be simlar to this one... 

It does help here.....

I installed the new rpm in a safe place so I could compare and contrast....

testing with old code: $ rpm -q --file `which mount`
util-linux-2.12a-21

# mount  bxtop:/export/files /tmp/MMM
mount to NFS server 'bxtop' failed: server is down.  # yep my problem...

Now with mount from the new rpm as per steved above... I installed it in
/tmp/MMMroot and testing it looks good....
[root@box tmp]# /tmp/MMMroot/bin/mount  bxtop:/export/files /tmp/MMM
[root@box tmp]#                <--- Most excelent silence is golden
[root@box tmp]#
[root@box tmp]# df  # Now check...
Filesystem           1K-blocks      Used Available Use% Mounted on
/dev/hda3             22928148  10042224  11721212  47% /
none                    513108         0    513108   0% /dev/shm
bxtop:/export/files 222029360  90235928 131793432  41% /tmp/MMM
# and Yes it mounted...

So yes this does help my observed problem.

*** This bug has been marked as a duplicate of 152956 ***

Thank you for your feedback!

didnt fix our sco problem.

You said:

"This just started happening at the same time i had to start putting
the nfsvers=2 option in /etc/fstab. It seems the more you use it, the
less likely it is to hang."

and I'm sure I understand what you mean. Are you saying that 
using v2 causes the hang or does not cause the hang?

We used rh 9 for a while then upgraded our workstations to FC3 and we couldnt
mount anything via nfs. Then we figured out we had to add nfsvers=2 to
/etc/fstab in order to get our machines to mount the exported nfs directory. I
guess what i was saying in a round about way was that it was not broken in
previous releases of 
RedHat and I figured that there was a big update to the nfs stuff that caused it
to break because I now had to specify the nfs version in addition to the hang. I
have backed my workstation up to RHEL3WS and the nfs works flawlessly.  We do
still have a couple of FC3 machines in place if you need any output from one of
them. I will be spending the rest of the day upgrading my machine to RHEL4WS.
I'll let you know if its in there too.

Bart 

I have the same problem - Can't mount an SCO - 
OpenServer(TM) Release 5 (scosysv 3.2 5.0.5 i386)) 
export (exported with "/   -access=access=bu-fs-n:rmt-fs,root=bu-fs-n:rmt-fs").

If the /etc/fstab line does NOT contains "nfsver=2", I get the message:
mount to NFS server 'bu-sdr' failed: server is down.
When it DOES contain "nfsver=2" the system crashes.

Fedora Core 3 is now maintained by the Fedora Legacy project for security
updates only. If this problem is a security issue, please reopen and
reassign to the Fedora Legacy product. If it is not a security issue and
hasn't been resolved in the current FC5 updates or in the FC6 test
release, reopen and change the version to match.

Thank you!

Works OK in kernel 2.6.17-1.2145_FC5.
Previous kernels (2.6.15) had problems when trying to mount more than 1 NFS disk.