> This bug has turned out to be quite puzzling, as it should have been very easy
> to fix. To summarize the behavior:
>
> (1) There are only a small number of servers in use that demand longword-sized
> RPC messages, but for them the current NFS client is 100% broken.
>
> (2) Adding pad bytes fixes the garbage args messages from such servers and
> allows them to work with the Linux client.
>
> (3) The error reports associated with adding pad bytes seem to occur only under
> dynamic conditions. If the server were applying some tests to the incoming
> packets and discarding them, this should show up as consistent failures. (FWIW,
> I haven't seen any problems with either knfsd or unfsd.)
>
> (4) By code inspection of the tcp sendmsg paths, putting additional bytes in an
> iovec is equivalent to copying the original data to a longword-sized buffer,
> which is what the 2.0.xx NFS client does.
>
> So if the patch really is causing some kind of problem, it would appear that
> either the padding calculation is wrong under some circumstances, or else the
> presence of extra pad bytes or an extra iovec is triggering some other bug in
> the RPC or networking layer. In the latter case, it's more important that we
> track down the true problem, as otherwise it will likely reappear in a different
> guise. In my experience the value of fixing a minor bug is increased if it
> exposes a more serious problem.
I think, you are right. It is not a problem was happens all the time,
but only under special conditions. I can access the server with the
unpatchjed kernel happily on small files and small load. But if I
start doing something heavy xemacs-gnus over nfs e.g. it fails.
Here are some more Errors:
I am running 2.1.87 with your patch and padding enable. Now I can use
2.1 the first time, but I get:
Feb 23 09:08:13 kernel: NFS: server hp, readdir reply truncated
Feb 23 09:08:13 kernel: NFS: nr=170, slots=3, len=7
Feb 23 12:51:57 kernel: autofs: lookup failure on existing dentry, status = -2, name = clearcase.expview.vobs.sl
Feb 23 12:51:57 kernel: autofs: trying to recover, but prepare for Armageddon
[...]
Feb 26 12:08:21 kernel: nfs_lookup: myname/Mail failed, error=-116
Feb 26 12:08:21 kernel: nfs_lookup: myname/Mail failed, error=-116
Feb 26 12:08:31 kernel: nfs: RPC call returned error 111
Feb 26 12:08:31 kernel: RPC: task of released request still queued!
Feb 26 12:08:31 kernel: RPC: (task is on xprt_pending)
Feb 26 12:08:31 kernel: nfs_lookup: myname/Mail failed, error=-111
Feb 26 12:08:41 kernel: nfs: RPC call returned error 111
Feb 26 12:08:41 kernel: RPC: task of released request still queued!
Feb 26 12:08:41 kernel: RPC: (task is on xprt_pending)
[...] more of these
Please note that the newer message come from another HP-UX server (not
the one logged first).
Hope it helps
Christoph
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu