Comment 8 for bug 19196

(In reply to comment #7)
> > What did you see in the tcpdump session which showed that it was nfsmount and
> > not the kernel which was responsible for the traffic?
>
> the client was connecting to the server, the server was answering and the client
> did timeout.

There are two clients involved: the nfsmount userland program, and the kernel.
Which one was involved in a transaction when you observed this behaviour?

> > Adding a sleep before attempting the NFS mount, as I have done to work around
> > this problem, is not the correct solution.
>
> nfsmount in klibc, simply timesout too fast. It attempts 3 times very fast to
> mount /
> and fails immediatly with the timeout error. A normal nfs client does a few
attempts
> with longer "sleeps" between attempts.

That isn't what I see in the code:

#define TIMEOUT_MS 3000
#define MAX_TRIES 100
[...]
        for (i = 0; i < MAX_TRIES; i++) {
                int timeout_ms = TIMEOUT_MS + (lrand48() % (TIMEOUT_MS / 2));

Furthermore, I don't think that nfsmount prints any error messages about
timeouts, unless debugging is enabled:

                                DEBUG(("Timeout #%d\n", i + 1));

The error message "%s: server %s not responding, still trying" (which is the one
that I see) is written to the console by Linux, and not by any part of klibc.