On 6/13/07, Steven Rostedt <rostedt@xxxxxxxxxxx> wrote:
> Heh, I spoke too soon. This patch doesn't seem to help my problem after all. :/ > Really? Darn. So it seemed to work? Just curious to why you thought it worked and but it didn't?
Yeah, I can't reproduce the problem at will, it takes from minutes to hours to happen. After a few hours of problem free operation with your patch I thought it was solved but then, the same problem. Applications accessing this nfs filesystem on this host will just hang and the df, lsof etc commands also started to hang. Other nfs clients have no problem accessing that filesystem its only this host, which is the only core2 (smp) box in the mix so the description you gave with the patch sounded pretty good to me. I'm not even sure it's a kernel problem, although I just updated my nfs user space stuff and half of user space that came along with it and still no luck. I've been using this nfs mount for years but I just changed the nfs exports slightly. I mounted and exported two other file systems under the original export. I added the 'nohide' export option and to my amazement these filesystems appeared on the client having only mounted the original export. I thought I was lucky, I didn't have to mount all these other sub-filesystems. I would summarize as: 2.6.21.4-rt13 core2, smp nfs client access hangs when using nohide export option So, smp and the more recent kernel seem to be suspect. Also cpufreq, which I just disabled. These UP clients have no problems accessing the same nfs export: celeronA - 2.6.21-rc5-rt11 pII - 2.6.17-rc6-mm1 I'll let you know if I am able to pin it down. Shane - To unsubscribe from this list: send the line "unsubscribe linux-rt-users" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
