Very many thanks to the following in helping to sort this out.
Randall S. Winchester <rsw_at_Glue.umd.edu>
Aidan Williams <aidan_at_cse.unsw.edu.au> (amd-workers mailing list)
Neil Brown <neilb_at_cse.unsw.edu.au> (amd-workers mailing list)
Soon after posting it became apparent that it was the linker that was
at fault and it could happen with any langauge not just fortran90.
Randell gave me the good news that the amd-workers mailing list
is active and an NFSV3 version in alpha trsting.
Following a similar post to the amd mailing list Aiden and Neil
replied that they had found the cause of the problem to be a bug in
DU4.0 NFS client code when a remote filesystem is mounted
"nintr" ( which is the default for amd ). Aiden provided a short
script that demonstates the problem without amd.
Can anyone explain what are the differences in practice in using
intr or nintr on NFS mounts?
I have logged a call with DEC but in the meantime the workagound is to
use the "intr" option in amd.
Many thanks to everyone.
Tim Janes | e-mail : janes_at_signal.dra.hmg.gb
Defence Research Agency | tel : +44 1684 894100
Malvern Worcs | fax : +44 1684 895103
Gt Britain | #include <std/disclaim.h>
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Original Question:
> Hello all,
>
> We seem to have a problem with amd (upl102) and DEC f90.
>
> If we try and compile and link even a 10 line program with f90 (V4.1)
> on DU4.0B when the source is on an amd mounted disk from another DU4.0
> system it usually brings our whole network to a grinding halt.
>
> Here is a portion of output from monitor on the machine doing the
> compiling - notice the 11,000 output packets/sec. This continues until
> the machine is rebooted.
>
> Net: ipkts ierrs opkts oerrs collis
> fta0 213.9 0.0 11085.1 0.0 0.0
> sl0 0.0 0.0 0.0 0.0 0.0
> lo0 17.7 0.0 17.7 0.0 0.0
>
> All this traffic is the following:-
>
> 15:18:23.733267 byron.dra.hmg.gb.7388a6e0 > milne.dra.hmg.gb.nfs-v2: 128 call re
> move OSF/1 fh 8,6/1.30 ".nfs5744"
> 15:18:23.733267 byron.dra.hmg.gb.7388a6e0 > milne.dra.hmg.gb.nfs-v2: 128 call re
> move OSF/1 fh 8,6/1.30 ".nfs5744"
>
> Here is a complete dump of a similar packet:-
>
> 12:31:59.866216 byron.dra.hmg.gb.50ace4e4 > milne.dra.hmg.gb.nfs-v2: 128 call re
> move OSF/1 fh 8,6/1.16959 ".nfs7B31"
> aaaa 0300 0000 0800 4500 009c 4ff4 0000
> 1e11 3b02 c13d c779 c13d c766 03f0 0801
> 0088 9fe0 50ac e4e4 0000 0000 0000 0002
> 0001 86a3 0000 0002 0000 000a 0000 0001
> 0000 002c 3352 15af 0000 0010 6279 726f
> 6e2e 6472 612e 686d 672e 6762 0000 01c2
> 0000 000f 0000 0002 0000 000f 0000 03eb
> 0000 0000 0000 0000 0600 8000 0100 0000
> 0c00 0000 3f42 0000 ef47 ac32 0c00 0000
> 0200 0000 0562 762f 0000 0008 2e6e 6673
> 3742 3331
>
> The example program does link with NAG ( I do not know if this is
> relevent) and does occasionally compile + link OK. It is also OK if
> compiled with f77 or if the source is on any hard mounted disk ( local,
> NFSV3 or NFSV2). ( All filesystems are UFS)
>
> Some time ago I tried to subscribe to the amd developers mailing list without
> success. Does a developers community still exist?
>
> Is amd effectively dead (except on platforms such as NetBSD, FreeBSD,
> Linux) ? Certainly support for NFSV3 has been long overdue.
>
> It would be very sad to loose all the extra features of amd and I
> certainly hope the the DEC automounter has improved in reliability
> since the Ultrix 4.0 era if we are forced to change back.
>
> Any Ideas?
>
> Tim Janes
>
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Randall S. Winchester
> To subscribe to amd-workers mail "majordomo_at_majordomo.umd.edu" with
> the line "subscribe amd-workers" in the mail message (not the subject).
>
> Development on AMD in currently quite active. NFS Version 3 support should
> be publicly avaliable in the near future. It is running on my osf3.2,
> DU4.0B, NetBSD1.2*, and Solaris2.5 machines. The work of several
> contibutors needs to be merged before a general release.
>
> I will try to duplicate your bug report, as well as forwarding this to the
> list.
>
> Randall
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Neil Brown:-
: We had this too. Beat our head against a brick wall, and a brick 'dec
: service engineer' for a while..
:
: Eventually discovered that if you mount with the 'intr' flag (default
: with /sbin/mount, but not with amd, the problem magically goes away.
:
: We told DEC. They said 'Ah, you have a work around. Good. We will
: close the call.' Nothing about fixing it ofcourse.
:
: So add 'opts:=intr' and it should be fine.
:
: NeilBrown
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Aiden Williams:-
#!/bin/sh -x
#
# This script demonstrates a bug in the NFS client code
# in the DU4.0 kernel. The bug appears to be tripped by
# the use of non-interruptible nfs mounts, and exists in
# both nfsv2 and nfsv3.
#
# Aidan Williams,
# School of Computer Science and Eng.
# University of New South Wales
# Sydney, Australia.
# Email: aidan_at_cse.unsw.EDU.AU
#
#
# nfs client is running DU4.0
#
mntpt=/mnt
#
# nfs server running DU3.2C, Solaris 2.5, doesn't matter what..
#
server=your_server:/exported_dir
[ ! -d $mntpt ] && mkdir $mntpt
# nfsv2 or nfsv3 both trip bug, we happen to use nfsv2
mount -o nfsv2,nintr $server $mntpt
echo 'int clog;' > /tmp/dummy.c
echo 'main(){}' >> /tmp/dummy.c
cd $mntpt
/usr/ucb/cc -c /tmp/dummy.c
# This causes the hang. Temporary files are created on the nfs
# filesystem. A file "l.out" is created, hardlinked to "a.out" and then
# l.out is removed (resulting in l.out being renamed to .nfs1a2f..),
# thereafter a stream of unlink requests nfs requests are made for the
# .nfs file. Use the DU4.0 version of tcpdump to get a protocol trace
# (it decodes nfs rpc requests/replies).
/usr/lib/cmplrs/cc/ld /usr/lib/cmplrs/cc/crt0.o dummy.o -lm -lc
echo No hang..
cd /; umount /mnt
Received on Wed May 07 1997 - 23:20:49 NZST