On Thu, Nov 15, 2007 at 08:51:36AM +0100, Christian Kujau wrote:
> [] mutex_lock_nested+0xcc/0x2c0
> [] do_lookup+0xa4/0x190
> [] __link_path_walk+0x749/0xd10
> [] link_path_walk+0x44/0xc0
> [] path_walk+0x18/0x20
> [] do_path_lookup+0x78/0x1c0
> [] __user_walk_fd+0x38/0x60
> [] vfs_stat_fd+0x21/0
On Thu, 15 Nov 2007, Christian Kujau wrote:
Upon accessing the /data/sub part of the CIFS share, the client hung, waiting
for the server to respond (the [cifs] kernel thread on the client was
spinning, waiting for i/o). On the server, similar things as with the nfsd
processes happened
Turns o
On Thu, November 15, 2007 08:51, Christian Kujau wrote:
> Since NFS was not working (the nfsd processes were already in D state),
> to mount a CIFS share from the very same server (and the same client).
That should read:
Since NFS was not working (the nfsd processes were already in D state), I
de
On Wed, 14 Nov 2007, Christian Kujau wrote:
Yes, the nfsd process only got stuck when I did ls(1) (with or without -l) on
a NFS share which contained a XFS partition.
Since NFS was not working (the nfsd processes were already in D state), to
mount a CIFS share from the very same server (and th
4 matches
Mail list logo
