On Sun, 14 Jan 2007, 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.
Hi Florin, thanks a lot for the testing. Just to verify - what kernel is 'the same kernel' mentioned above? (just to isolate whether the problem is really somewhere between 2.6.19 and 2.6.20-rc2, as you stated in previous posts, or the situation has changed). > After recompiling, I moved over to the workstation to reboot it, but the > keyboard was not functioning ;( So this time the hang occured when the system was idle, not during the transfers, right? > 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. Could you please do alt-sysrq-t (or "echo t > /proc/sysrq-trigger" via ssh, when your keyboard is dead) to see the calltraces of the processes which are stuck inside kernel? You will probably get a lot of output after the sysrq, so please either put it somewhere on the web if possible, or just extract the interesting processes out of it (mainly the ones which are stuck). Thanks, -- Jiri Kosina - 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/
