If it still fails with max_pending set to 9 or 10 (on the client) - then you are stuck with having to fix the server (there were a couple of registry parms which can be set in Windows, mentioned in earlier posts which apparently resolve this). ( had trouble reproducing this with max pending set low. We may want to enable SMB2 dialect (SMB2.1 dialect is currently enabled in linux-next, but not SMB2.0 dialect which Vista uses) if Vista fails (was this Vista or Windows 7) - since SMB2 uses a different crediting mechanism? On Sun, Sep 23, 2012 at 11:02 AM, David Balažic <xerces9@xxxxxxxxx> wrote: > On 22 September 2012 02:02, Steve French <smfrench@xxxxxxxxx> wrote: >> >> >> On Fri, Sep 21, 2012 at 6:05 PM, David Balažic <xerces9@xxxxxxxxx> wrote: >>> >>> Suresh Jayaraman <sjayaraman@...> writes: >>> >>> > Ah, ok. In case if you have not figured out how to overcome this >>> > problem, take a look at >>> > >>> > >>> > http://alan.lamielle.net/2009/09/03/windows-7-nonpaged-pool-srv-error-2017 >>> >>> (I'm not subscribed, so please CC me) >>> >>> Hi! >>> >>> I also encountered this error 12 accessing a shared folder on a Windows 7 >>> Pro >>> SP1 64-bit "server", client being SystemRescueCd 3.0.0 with kernel version >>> 3.2.28 32 bit. It also happens with other kernels (RipLinux 13.7, kernel >>> 3.2.1). >>> >>> >>> I got the error when copying a single large file to the shared folder. >>> The registry tweaks at that URL mitigates the problem. >>> But I changed it back to do some research. >>> When accessing the same shared folder from a Windows 7 Home Premium SP1 >>> x64 >>> client, there is no problem. >>> >>> When I tried with Linux just before posting this, I got error 12 right >>> when >>> mounting, before doing any file operations. >>> >>> Is this because linux-cifs does not respect the MaxReq parm that the >>> server >>> sends, as suggested in this post: >>> http://article.gmane.org/gmane.linux.kernel.cifs/4294 ? >>> >> >> We were able to reproduce this problem to Windows, even when >> the (Windows Vista/Windows 7) server was configured for 50 requests, >> but current cifs.ko (3.4 kernels and later) does respect the servers >> MaxReq parameter (maximum simultaneous requests limit). >> >> To servers, like Samba, which can handle much more than 50 >> simultaneous requests, note that the server's limit can be configured >> (increased) in the server's smb.conf file beyond the typical default >> (50 for most server's and clients - thus the reason cifs client >> simply defaulted to 50 prior to 3.4). > > I tried setting the cifs_max_pending module parameter, also kernel 3.4.9 > > It is better, but there are still some errors 12. > > Any recommendations? (besides trying a newer kernel) > > Regards, > David -- Thanks, Steve -- 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
