On May 11, 2009, at 10:39 AM, Frans Pop wrote:

On Monday 11 May 2009, you wrote:

quoted

On May 10, 2009, at 8:48 PM, Frans Pop wrote:

quoted

After switching from 2.6.29.2 to 2.6.30-rc5 I get this new message
during boot of my home server:
 svc: failed to register lockdv1 RPC service (errno 97).

Is this the only instance of this message, or do you see it several
times?

It's the only one.

quoted

quoted

This looks to be the result of the following commit:
commit 363f724cdd3d2ae554e261be995abdeb15f7bdd9
Author: Chuck Lever [off-list ref]
  SUNRPC: rpcb_register() should handle errors silently
  Move error reporting for RPC registration to rpcb_register's
caller.

Question is: do I really want to know this? I assume the "failure"
happened with previous kernels too, but silently.

The point of that commit was to report errors _less_ frequently.

:-)

quoted

The server-side RPC code is attempting to be more automatic about
which address families are supported by kernel NFS services.  This
message tells us that some particular case is not handled yet.  I
suspect you weren't seeing this error in the past at all.

Correct. Neither this exact error, nor anything remotely similar.

No, I meant that whether or not you saw an error message, the  
underlying condition probably was not occurring before 2.6.30.

quoted

Can you report more about your server configuration?  What
distribution is this?

Debian stable (Lenny).
nfs-common and nfs-kernel-server (1.1.2)

I'm using nfs4. rpc.statd is not running; rpc.mountd and rpc.idmapd  
are.

The NFS client and server appear to start lockd listeners for NFSv4.   
They probably don't need to.  But that's a separate issue.

quoted

Does user space have portmapper or rpcbind?

portmap (6.0)

quoted

Are you blacklisting ipv6.ko?

No, the server has IPv6 enabled.
I'm using NFS mainly from my laptop though, which does not have an  
IPv6
address for my home network.

quoted

What's the output of "rpcinfo" on your server after it has started  
NFSD?

I guess you mean the -p option?

$ rpcinfo -p
  program vers proto   port
   100000    2   tcp    111  portmapper
   100000    2   udp    111  portmapper
   100003    2   udp   2049  nfs
   100003    3   udp   2049  nfs
   100003    4   udp   2049  nfs
   100021    1   udp  47955  nlockmgr
   100021    3   udp  47955  nlockmgr
   100021    4   udp  47955  nlockmgr
   100021    1   tcp  41860  nlockmgr
   100021    3   tcp  41860  nlockmgr
   100021    4   tcp  41860  nlockmgr
   100003    2   tcp   2049  nfs
   100003    3   tcp   2049  nfs
   100003    4   tcp   2049  nfs
   100005    1   udp  40032  mountd
   100005    1   tcp  40623  mountd
   100005    2   udp  40032  mountd
   100005    2   tcp  40623  mountd
   100005    3   udp  40032  mountd
   100005    3   tcp  40623  mountd
   391002    2   tcp    792  sgi_fam

In this case, it looks like the message can be treated as a notice.  I  
think in general we could safely make that a dprintk, but I'd like to  
wait a bit more to see if we catch any bad behavior.

--
Chuck Lever
chuck[dot]lever[at]oracle[dot]com