On Sun, 2007-01-14 at 17:58 -0600, Florin Iucha wrote: > 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".
Did you try an 'echo t > /proc/sysrq-trigger' in order to find out where the stat process is hanging? Trond - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
