On Thu, 2011-01-13 at 18:25 -0800, Andy Isaacson wrote: > On Wed, Jan 05, 2011 at 09:53:13AM -0500, Trond Myklebust wrote: > > > There was a bug in at least -rc5[1] that was considered already fixed in > > > -rc4[2]. The later announcements didn't mention it anymore. > > > > > > > I don't know why it's stopped producing the errors, although once it > > > > went I never investigated it any further (was far too busy trying to > > > > get AMBA DMA support working.) > > > It seems it was fixed for most users though. Trond? > > > > As I said, I can't reproduce it. > > > > I'm seeing a lot of mention of ARM above. Is anyone seeing this bug on > > x86, or does it appear to be architecture-specific? > > I'm seeing processes stuck in D with "fileid changed" in dmesg, on > x86_64 (both server and client). The repro testcase is to run an > executable off of NFS, recompile it on the server, and then try to tab > complete the executable name. The client prints > > NFS: server <hostname> error: fileid changed > fsid 0:18: expected fileid 0x107aa4a, got 0x107ad3e > > and /bin/zsh hangs in D. > > My server is running 2.6.36.1, filesystem is ext3 on sda3 on AHCI, > client is currently running 2.6.37-rc1. I'm assuming that 37a09f will > fix it. Why are you sticking to 2.6.37-rc1 when the final 2.6.37 is out? There have been several readdir bugfixes merged in the months since -rc1 came out. Trond -- Trond Myklebust Linux NFS client maintainer NetApp Trond.Myklebust@xxxxxxxxxx www.netapp.com -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
