Return-Path: linux-nfs-owner@vger.kernel.org Received: from mx12.netapp.com ([216.240.18.77]:52108 "EHLO mx12.netapp.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S935661Ab3DPPhM convert rfc822-to-8bit (ORCPT ); Tue, 16 Apr 2013 11:37:12 -0400 From: "Myklebust, Trond" To: Joakim Tjernlund CC: "linux-nfs@vger.kernel.org" Subject: Re: NFS loop on 3.4.39 Date: Tue, 16 Apr 2013 15:36:55 +0000 Message-ID: <1366126613.12556.18.camel@leira.trondhjem.org> References: In-Reply-To: Content-Type: text/plain; charset=US-ASCII MIME-Version: 1.0 Sender: linux-nfs-owner@vger.kernel.org List-ID: On Tue, 2013-04-16 at 12:41 +0200, Joakim Tjernlund wrote: > Here we go again, this time i happened while browsing the Boston news on > www.dn.se > Now gvfsd-metadata is turned off(not running at all) and I get: > 10:28:44.616146 IP 192.168.201.44.nfs > 172.20.4.10.3671768838: reply ok > 52 getattr ERROR: unk 10024 Part of the reason why you are getting no response to these posts is that you are posting tcpdump-decoded data. Tcpdump still has no support for NFSv4, and therefore completely garbles the output by trying to interpret it as NFSv2/v3. In general, if you are posting network traffic, please record it as binary raw packet data (using the '-w' option on tcdump) so that we can look at the full contents. Either include it as an attachment, or provide us with details on how to download it from an http server. Other information that is needed in order to make sense of NFS bug reports includes: - client OS (non-linux) or kernel version (linux) - mount options on the client - server OS (non-linux) or kernel version (linux) - type of exported filesystem on the server - contents of /etc/exports on the server Please ensure that you always include those in your emails. -- Trond Myklebust Linux NFS client maintainer NetApp Trond.Myklebust@netapp.com www.netapp.com