On Thu, 9 Jun 2011 18:28:45 -0400
Jeff Layton<jlayton@xxxxxxxxxx> wrote:
On Fri, 03 Jun 2011 17:11:05 +0200
Helge Hafting<helge.hafting@xxxxxxx> wrote:
On 03. juni 2011 12:15, Suresh Jayaraman wrote:[Cc linux-cifs@xxxxxxxxxxxxxxx]
On 06/01/2011 03:41 PM, Helge Hafting wrote:At work I use cifs for accessing a windows server. This has worked fine
for a long time, up to and including Debian's 2.6.38-2.
I just installed Debians's 2.6.39-1, and had to give up on it.
Mounting CIFS works, and I can see the files. But if I
try to make a new file (with cp), I get a long delay.
What is the security mechanism you are using? If you seeing the problem
with ntlm, could you try using ntlmv2 and see whether the problem is
In the beginning, I did not specify the mechanism. So, whatever the
The fstab entry was like this:
\\servername\resource /mountpoint cifs
I looked at cifs options, and tried to add "sign" and "sec=ntlmv2i". It
made no difference. Still failure with 2.6.39, and mounting with these
new options works fine with 2.6.38
I think we need to understand what's happening on the wire. Are you
still able to reproduce this? If so, can you turn up debug logging and
reproduce this?. Instructions for how to do that are here:
Also, it looks like someone opened a bug at kernel.org too:
...so if you can attach the resulting log there, that would be great.
I think that this is probably due to the change that added the
page_mkwrite function to cifs.ko. Prior to that, cifs did single-page
writes on signed connections. Now we do multi-page writes and windows
servers apparently reject large write calls on signed connections.
One way to test this theory would be to set the wsize to something
smaller when you mount. For instance:
...assuming that doesn't go over the server's MaxBufferSize, then that
should act as a workaround. Can you try that and let me know if it