On Tue, 5 Nov 2013 20:34:52 -0800 Neil Sikka <neilsikka@xxxxxxxxx> wrote: > Here are the ping statistics where I starting pinging before I started > a "cp" of a 32KB file and ending after VFS hung in the copy process: > 170 packets transmitted, 170 received, 0% packet loss, time 169241ms > rtt min/avg/max/mdev = 120.447/158.142/397.196/36.544 ms > > The network connection seems fine--there were no dropped packets. > > Although 3.2 is old, it is still more recent than the link i shared > where they first reported this bug. I would have thought they would > have fixed this bug or something. Does anyone on this list know the > what happened to the bug reported > here (https://bugzilla.redhat.com/show_bug.cgi?id=522867)? > > > The bug got autoclosed because no one bothered to keep it going (see comment #5 in that bug). comment #4 in that bug strongly suggests that the problem was with the lower-level networking and not really with cifs, per-se. Your problem may or may not be different. You'll have to do some investigation to be sure. cifs.ko's usage of the networking layer is very userland-like. It really doesn't do much special there. You have these lines in the log you posted: [ 2294.192963] CIFS VFS: sends on sock ffff88020e477d40 stuck for 15 seconds [ 2294.192971] CIFS VFS: Error -11 sending data on socket to server Basically that means that kernel_sendmsg is continually returning -EAGAIN. That likely means that the socket send buffer is full, typically because the server can't be reached or isn't ACK'ing TCP packets. If pinging works ok, then your problem may be at the TCP layer. Possibly a problem related to bufferbloat given that you are running this over a long-haul link: http://en.wikipedia.org/wiki/Bufferbloat ...but it could be something else entirely. -- Jeff Layton <jlayton@xxxxxxxxxx> -- To unsubscribe from this list: send the line "unsubscribe linux-cifs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
