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
signature.asc
Description: Digital signature