Messages in this thread | | | Date | Sun, 14 Jan 2007 17:58:17 -0600 | Subject | heavy nfs[4]] causes fs badness Was: 2.6.20-rc4: known unfixed regressions (v2) | From | (Florin Iucha) |
| |
On Sun, Jan 14, 2007 at 04:57:01PM -0600, wrote: > On Wed, Jan 10, 2007 at 10:54:34AM -0500, Alan Stern wrote: > > It's still possible that this is hardware related; perhaps some component > > just began to wear out. If you return to an earlier kernel, does the > > problem go away? > > As reported in my original e-mail and verified just minutes ago, the > copy succeeds with 2.6.19 (kernel.org vanilla, compiled with the same > config as 2.6.20-rcX). I will begin bisecting between .19 and .20-rc1 > after re-reading Jiri's messages.
All the testing was done via a ssh into the workstation. The console was left as booted into, with the gdm running. The remote nfs4 directory was mounted on "/mnt".
After copying the 60+ GB and testing that the keyboard was still functioning, I did not reboot but stayed in the same kernel and pulled the latest git then started bisecting. After recompiling, I moved over to the workstation to reboot it, but the keyboard was not functioning ;(
I ran "lsusb" and it displayed all the devices. "dmesg" did not show any oops, anything for that matter. I have unplugged the keyboard and run "lsusb" again, but it hang. I ran "ls /mnt" and it hang as well. Stracing "lsusb" showed it hang (entered the kernel) at opening the device that used to be the keyboard. Stracing "ls /mnt" showed that it hang at "stat(/mnt)". Both processes were in "D" state. "ls /root" worked without problem, so it appears that crossing mountpoints causes some hang in the kernel.
Based on this info, I think we can rule out any USB. I will try testing with NFS3 to see if the problem persists. Unfortunately there is no oops or anything in "dmesg".
florin
-- Bruce Schneier expects the Spanish Inquisition. http://geekz.co.uk/schneierfacts/fact/163 [unhandled content-type:application/pgp-signature] | |