On Mon, 5 Jul 2010 14:21:08 +0100 James Green <[email protected]> wrote:
> On 5 July 2010 14:04, Jeff Layton <[email protected]> wrote: > > 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. > > This doesn't quite feel right. I mean, why one day should an XP host > just stop responding at random to requests? I know it's Microsoft but > even so... > > I took a look at the Event Viewer and under Security there are > 0xC0000064 errors as smbfs makes it's accesses. Perhaps this is a > clue? > > Applying a patch might not be particularly easy as this box is stock > Ubuntu (excepting the upstream kernel) and I don't particularly want > to start compiling bits just to make phpunit run as it was a few days > ago. > You may be right, but unfortunately I can't do much beyond tell you what I think is happening now. It's certainly possible there was a change in the cifs code that is tickling a server-side bug. I think 0xC0000064 == NO_SUCH_USER, so there may be some sort of problem with authentication. -- Jeff Layton <[email protected]> -- To unsubscribe from this list: send the line "unsubscribe linux-cifs" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
