[lkml]   [2007]   [Jan]   [14]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: heavy nfs[4]] causes fs badness Was: 2.6.20-rc4: known unfixed regressions (v2)
    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?


    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2007-01-15 01:39    [W:0.021 / U:2.296 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site