Date: Wed, 23 Apr 2014 14:05:40 +0800 From: Marcelo Araujo <araujobsdport@gmail.com> To: Rick Macklem <rmacklem@uoguelph.ca> Cc: "freebsd-fs@freebsd.org" <freebsd-fs@freebsd.org> Subject: Re: NFSv4: prob err=10036 Message-ID: <CAOfEmZh058hhMHvbeOQPCeVUJPn37mGKNeN0vd5xA6Ody=DBrA@mail.gmail.com> In-Reply-To: <1786007789.11586463.1397595681788.JavaMail.root@uoguelph.ca> References: <CAOfEmZg9ejea%2B8Ab-cHS4Y99HZK-pK3kHD3o_Gih0y%2BQY0niJg@mail.gmail.com> <1786007789.11586463.1397595681788.JavaMail.root@uoguelph.ca>
next in thread | previous in thread | raw e-mail | index | archive | help
2014-04-16 5:01 GMT+08:00 Rick Macklem <rmacklem@uoguelph.ca>: > > Well, I looked at the packet trace and it is weird. > > One field (the NFSv4 operation #) is incorrect in the packet. > It should have been 33 (0x21), which is PUTROOTFH and instead > it is 39 (0x27), which is RELEASELOCKOWNER. > All the arguments after the operation # are correct for the > RPC, if that operation# was 33 (PUTROOTFH). > > Since the call looks like this (around line#4303 in > sys/fs/nfsclient/nfs_clrpcops.c): > > nfscl_reqstart(nd, NFSPROC_PUTROOTFH, nmp, NULL, 0, &opcntp, NULL); > > I can't imagine how NFSPROC_PUTROOTFH became NFSPROC_RELEASELCKOWN? > (Btw, there is a mapping from NFSPROC_xxx to NFSV4OP_xxx that occurs, > so these arguments are 33 and 34 respectively and not 33 and 39.) > > So, somehow the argument gets incremented by one when it is on the > stack for the call. (It would be 34 in nfscl_reqstart(), since the > tag is "Rellckown" and not "Dirpath" in the packet header. This tag > is for debugging only and doesn't affect the RPC's semantics. For > once, it was useful;-) So, this isn't some data error later, such as > "on the wire". > > All I can suggest is that something is stomping on this field on > the stack or there is a memory problem where this stack argument > sits? > > Aren't computers fun? rick > > Hello Rick, First of all, thank you so much, once again with your help I could solve the weird situation. Actually the problem was related with a VAAI implementation in the server side that I was making the test, the VAAI implementation on that server move one bit ahead for the NFSPROC operations and make my client totally confused. I made a fix on my NFSv4 client and now everything works properly. I don't think make much sense send back this patch, as in my case here, this VAAI implementation is not too much portable. Once again, thank you so much, you have done an amazing working on NFS. Best Regards, -- Marcelo Araujo araujo@FreeBSD.org
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAOfEmZh058hhMHvbeOQPCeVUJPn37mGKNeN0vd5xA6Ody=DBrA>