Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!timbuk!cs.umn.edu!ub.d.umn.edu!uwvax!dip.cs.wisc.edu!cole
From: cole@dip.cs.wisc.edu (Bruce Cole)
Newsgroups: comp.unix.ultrix
Subject: Re: nfs_subr.o
Message-ID: <11720@spool.cs.wisc.edu>
Date: 14 Nov 90 05:17:55 GMT
References: <29379@boulder.Colorado.EDU> <29458@boulder.Colorado.EDU> <1990Nov9.144151.9514@ux1.cso.uiuc.edu>
Sender: news@spool.cs.wisc.edu
Distribution: comp
Organization: U of Wisconsin CS Dept
Lines: 83

In article <1990Nov9.144151.9514@ux1.cso.uiuc.edu> steven@pacific.csl.uiuc.edu writes:
>|> The nfs_subr.o file for Ultrix 4.0 was mailed to me - several other
>|> people requested it, so I'll post it.
>
>Does anybody have a VAX/4.0 version?

You shouldn't need a patch to nfs_subr.o to use AMD on an Ultrix VAXen.  The
bug is MIPS specific.  Here are the original messages.  The second message
tells you where you can get new .o files to patch your MIPS kernel.

From: cole@cs.wisc.edu (Bruce Cole)
To: amd-workers@acl.lanl.gov
Cc: cole@cs.wisc.edu
Subject: The reason why amd has problems on Ultrix MIPS processors
Date: Wed, 24 Oct 90 15:33:15 -0500

     In /usr/include/fs/nfs/nfs.h, the structure declaration for NFS file
handles (fhandle_t) is incorrect.  This causes sizeof(struct fhandle_t) to
yield 36 instead of the proper size (32).  The Ultrix kernel code that handles
the caching of NFS file handles depends upon this size and because of the
mis-declaration, it breaks when amd is used.
     Fixing this problem fixes the mount point traversing behavior under 
Ultrix.

Workarounds:

     For Ultrix 3.1, change the rfind() routine in sys/fs/nfs/nfs_subr.c to
use the proper file handle size.

*** /tmp/,RCSt1a09412   Wed Oct 24 15:14:09 1990
--- /tmp/,RCSt2a09412   Wed Oct 24 15:14:14 1990
***************
*** 748,754 ****
--- 748,760 ----
        for (gp = ih->gh_chain[0]; gp != (struct gnode *)ih; gp = gp->g_forw) {
                if (gno == gp->g_number && fsid == gp->g_dev) {

+ #ifdef UW
+                       /* For the MIPS architecture, sizeof(*fh) = 36,
+                          instead of the expected 32. */
+                       if (bcmp(vtofh((struct vnode *)gp), fh, NFS_FHSIZE)) {
+ #else
                        if (bcmp(vtofh((struct vnode *)gp), fh, sizeof(*fh))) {
+ #endif UW
  if (cachedebug) printf("rfind: rejected stale gnode, #%d, 0x%x\n",
  gp->g_number, gp);
                                continue;

For Ultrix 4.0, make the equivalent change to the nfs_match() routine in
sys/fs/nfs/nfs_subr.c:

*** /tmp/,RCSt1a09579   Wed Oct 24 15:27:21 1990
--- nfs_subr.c  Wed Oct 24 15:25:25 1990
***************
*** 607,613 ****
--- 607,619 ----
        struct rnode_data *rdp;
  {
        return(!bcmp(vtofh((struct vnode *)gp), rdp->rn_fh,
+ #ifdef UW
+                    /* For the MIPS architecture, sizeof(*fh) = 36,
+                       instead of the expected 32. */
+                    NFS_FHSIZE));
+ #else
                sizeof(fhandle_t)));
+ #endif UW
  }

  /*

From: cole@cs.wisc.edu (Bruce Cole)
To: arons@ash.eecs.ucdavis.edu
Cc: cole@cs.wisc.edu, amd-workers%acl@LANL.GOV, grunwald@foobar.Colorado.EDU
Subject: Re: The reason why amd has problems on Ultrix MIPS processors 
Date: Wed, 24 Oct 90 22:04:17 -0500

Okay, on dip.cs.wisc.edu I have made available for anonymous ftp
	pub/nfs_subr.o-3.1  (For Ultrix 3.1 -- probably breaks with 3.1C/D)
	pub/nfs_subr.o-4.0  (For Ultrix 4.0, rev 179)
--
Bruce Cole
Computer Sciences Department
U. of Wisconsin - Madison