> On Feb 8, 2019, at 7:01 AM, Benjamin Coddington <bcodding@xxxxxxxxxx> wrote: > > > On 7 Feb 2019, at 10:25, Jason Tibbitts wrote: > >>>>>>> "BC" == Benjamin Coddington <bcodding@xxxxxxxxxx> writes: >> >> BC> -10063 is -NFS4ERR_SEQ_MISORDERED.. I wonder why the >> BC> trace_nfs4_sequence_done() in nfs41_sequence_process() isn't showing >> BC> up in the trace? Ah.. my fault - add "nfs4:*" to the set_events. >> >> OK, attached is another trace. Here's the same sequence I snipped >> previously: > > So the client is calling SEQ over and over.. xs_stream_read_data sees > -EAGAIN.. I'm not an expert here, and not seeing what's going wrong. <wag> The server is returning SEQ_MISORDERED to a singleton SEQUENCE. That suggests the client is trying to re-establish its lease but is sending a slot nr the server doesn't recognize for the virtual slot used for this purpose. Could be a problem on either side, and I don't know enough to say how this loop could have started. </wag> > Hmm.. commit c443305529d1d3d3bee0d68fdd14ae89835e091f changed > xs_read_stream_reply() to return recv.copied instead of "ret" to > xprt_complete_rqst().. > > You could try reverting that commit and see if the problem goes away.. > > Ben -- Chuck Lever
