On Mon, 5 Jul 2010 10:14:29 +0100 James Green <james.mk.green@xxxxxxxxx> wrote: > Sorry I meant this to go to the list rather than solely to Jeff personally. > > On 2 July 2010 19:16, Jeff Layton <jlayton@xxxxxxxxxx> wrote: > > On Fri, 2 Jul 2010 16:39:06 +0100 > > James Green <james.mk.green@xxxxxxxxx> wrote: > > > >> Jul 2 16:14:58 ubuntu kernel: [ 1378.833956] CIFS VFS: No response > >> for cmd 50 mid 11112 > > > > The client is sending a SMB_COM_TRANSACTION2 and isn't getting a > > response. You might want to sniff traffic and identify calls that > > aren't getting responses. If there is some commonality between them > > then that may point to where the problem is. > > Jeff, > > I fear I'm looking for a needle in a haystack, and I've no idea what > the needle looks like. > > I ran Wireshark on my XP host and repeatedly ran the phpunit tests observing: > > 1. There really is an awful lot of FIND_FIRST2, Pattern: <blah>, > followed immediately by FIND_FIRST2, Files: <blank>. I assume this to > be normal. > > 2. Occassionally and on a random Pattern argumen, a FIND_FIRST2 or > QUERY_PATH_INFO is followed immediately not by an SMB level response > but by a TCP "microsoft-ds" ACK. The Len is 0 and all other arguments > have values. Can't be certain without seeing the capture, but it sounds like a "normal" TCP ACK. That means that the server has acknowledged that it received the packet. > At this point there may be several seconds of delay > before SMB re-establishes with a Session Set AndX Request, User: > \jgreen then a Tree Connect AndX Request for the mount point being > used. > > It feels as though the XP host itself is simply not returning a > response some of the time. Other than changing my password and > rebooting the whole lot I can't think of anything I might have done. > > If you have any further tests you'd like me to perform I'll try to > oblige as this is killing my workflow. > Yep, sounds like the server just isn't responding here. When that happens, cifs currently forces a reconnect after the call times out. Ugly and I believe unnecessary...when the server ACKs the response we shouldn't force a reconnect just because the server is taking a while to respond. Right now though we don't change the mid state to show that the call was successfully sent, so that probably ought to be fixed so we can deal with that differently. It's possible that by making the client wait indefinitely, the server will eventually respond. It's also possible however that the server is just dropping these calls on the floor for some reason and will never respond. Hard to say which it is. Shirish was working recently on fixing the "hard" mount option for cifs. It might be worth trying out his patches. Shirish, any thoughts? -- Jeff Layton <jlayton@xxxxxxxxx> -- 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
