On Sun, 2009-08-16 at 23:40 +0100, Daniel J Blueman wrote: > After losing and regaining ethernet link a few times with 2.6.31-rc5 > [1], I've hit an oops in the NFS4 client manager kthread [2] on my > client with NFS4 homedir mount. > > Do you have a frequent test-case for when the client's manager kthread > gets invoked (with and without succeeding callbacks, due to eg a > firewall)? Server here is unpatched 2.6.30-rc6; I recall seeing > problems when the manager kthread gets invoked, across quite a few > kernel releases, just wasn't lucky enough to catch an oops. > > Oppsing in allow_signal() suggests task state corruption perhaps? I'm > downloading the debug kernel to match up the disassembly and line > numbers, if that helps? This time, the client had no firewall (but > have seen other issues when the callback has failed due to the > firewall). Those aren't Oopses. They are 'soft lockup' warnings. Basically, they're saying that the CPU is getting stuck waiting for a spin lock or a mutex. In this case, it is probably the fact that the state manager is going nuts trying to recover, while the connection to the server keeps coming up and going down. What does 'netstat -t' say when you get into this situation? Cheers 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
