Hello,

I'm fighting for a while with using NFSv4 provided by HP-UX 11.31 (ONCplus 
B.11.31.04 (ONC+ 2.3)) on a SLES10 SP1 (x86_64) client. HP's NFS is basically that 
from Sun. The problems are:

Mounting the filesystems as NFSv3 causes no problems at all, using NFSv4 makes 
every file open() attempt to hang hard. I must "kill -9" the processes. Even 
"umount -vat nfs4" hangs on umount().

The only messages I get when trying an open is
kernel: Error: state recovery failed on NFSv4 server 192.168.0.20 with error 5

For umount the error message seems to be
rksapas08 kernel: Error: state recovery failed on NFSv4 server 192.168.0.20 with 
error 2

On the HP-UX server I see messages like these, but I'm unsure whether they are 
related to Linux:
vmunix: NOTICE: sec_clnt_geth: unknown authflavor 2037596260, trying AUTH_NONE
vmunix: NOTICE: sec_clnt_geth: unknown authflavor 10, trying AUTH_NONE

When HP-UX uses NFSv4 (same software as quoted above), no such problems appear. 
The server is a four-core Itanium2 (IA64) machine.

I'd appreciate any help towards understanding the error messages and debugging the 
problem.

Regards,
Ulrich
P.S. Not subscribed, so please CC:

--

[ message continues ]

Sorry, but this mailinglist would be appropriate only if this happens 
still with current vanilla kernel.

Otherwise, you should report this problem to your vendor (Novell bugzilla 
in this case).

-- 
Jiri Kosina
SUSE Labs

--

[ message continues ]

Hi!

(ingoring the fact your opinion may be influenced by SUSE/Novell)

Are you saying that SUSE/Novell added bugs regarding NFS4 that are not present in 
the vanilla kernel, or are you saying that the vanilla kernel may have fixed NFSv4 
bugs that SUSE/Novell did not fix? Why shouldn't anybody be interested in the fact 
that there are problems?

Regards,
Ulrich

--

[ message continues ]

In what sense? Do you think I am trying to direct as much bugs as possible 

linux-kernel malinglist is focused on vanilla kernel development. i.e. all 
the bugs that are present in the current version of the code are very 
welcome to be reported here.

SLES10 is based on 2.6.16 kernel, which has little interest for vanilla 
kernel developers. The bug you might be seeing could be caused by some 
SLES-specific patch (which is not probable, there are not many out-of-tree 
patches really), could have been fixed already a long time ago in upstream 
kernel version, or could be still present. Upstream kernel developers are 
interested only in the latest case. Otherwise, it's up to your distro 
kernel vendor to provide support.

-- 
Jiri Kosina
SUSE Labs
--

[ message continues ]