Re: kernel 3.1.1 - cifs issue - ls: cannot access /cifs_mnt: Cannot allocate memory

Re: kernel 3.1.1 - cifs issue - ls: cannot access /cifs_mnt: Cannot allocate memory

[Suresh Jayaraman]

[Cc linux-cifs-u79uwXL29TY76Z2rM5mHXA@public.gmane.org]

On 11/15/2011 12:34 AM, Justin Piszcz wrote:
> Hi,
> 
> CIFS "works" when I mount a Windows 7 host from my Linux host (3.1.1-x86_64)
> but if I turn my machine off (Windows) and turn it back on, I get the
> following error, is this normal? With NFS as a hardmount it just recovers,
> with CIFS do I need to setup some sort of canary to unmount/remount?
> 
>  $ ls /cifs_mnt
> ls: cannot access /cifs_mnt: Cannot allocate memory
> 

This looks like a problem specific to Windows 7 or above. Quick tests on
my test machines shows that cifs attempts to connect, times out,
attempts to reconnect and gets -EHOSTUNREACH in case of both Windows
Servers and Samba Servers. This is the expected behavior.

OTOH, this sounds like a problem related to an error due to the Windows
server being unable to allocate from the system nonpaged pool (seen in
the past). Do you see anything that is related to the error in Windows
Event viewer?


-Suresh

RE: kernel 3.1.1 - cifs issue - ls: cannot access /cifs_mnt: Cannot allocate memory

[Justin Piszcz]

-----Original Message-----
From: Suresh Jayaraman [mailto:sjayaraman-IBi9RG/b67k@public.gmane.org] 
Sent: Tuesday, November 15, 2011 8:33 AM
To: Justin Piszcz
Cc: linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org; ap-SDpCatL+S6WaMJb+Lgu22Q@public.gmane.org; linux-cifs
Subject: Re: kernel 3.1.1 - cifs issue - ls: cannot access /cifs_mnt: Cannot
allocate memory

[Cc linux-cifs-u79uwXL29TY76Z2rM5mHXA@public.gmane.org]

On 11/15/2011 12:34 AM, Justin Piszcz wrote:
> Hi,
> 
> CIFS "works" when I mount a Windows 7 host from my Linux host
(3.1.1-x86_64)
> but if I turn my machine off (Windows) and turn it back on, I get the
> following error, is this normal? With NFS as a hardmount it just recovers,
> with CIFS do I need to setup some sort of canary to unmount/remount?
> 
>  $ ls /cifs_mnt
> ls: cannot access /cifs_mnt: Cannot allocate memory
> 

This looks like a problem specific to Windows 7 or above. Quick tests on
my test machines shows that cifs attempts to connect, times out,
attempts to reconnect and gets -EHOSTUNREACH in case of both Windows
Servers and Samba Servers. This is the expected behavior.

OTOH, this sounds like a problem related to an error due to the Windows
server being unable to allocate from the system nonpaged pool (seen in
the past). Do you see anything that is related to the error in Windows
Event viewer?

Hi,

Yes, you are correct--

The server was unable to allocate from the system nonpaged pool because the
server reached the configured limit for nonpaged pool allocations.

Justin.

Re: kernel 3.1.1 - cifs issue - ls: cannot access /cifs_mnt: Cannot allocate memory

[Suresh Jayaraman]

On 11/16/2011 12:57 AM, Justin Piszcz wrote:
> 
> 
> -----Original Message-----
> From: Suresh Jayaraman [mailto:sjayaraman-IBi9RG/b67k@public.gmane.org] 
> Sent: Tuesday, November 15, 2011 8:33 AM
> To: Justin Piszcz
> Cc: linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org; ap-SDpCatL+S6WaMJb+Lgu22Q@public.gmane.org; linux-cifs
> Subject: Re: kernel 3.1.1 - cifs issue - ls: cannot access /cifs_mnt: Cannot
> allocate memory
> 
> [Cc linux-cifs-u79uwXL29TY76Z2rM5mHXA@public.gmane.org]
> 
> On 11/15/2011 12:34 AM, Justin Piszcz wrote:
>> Hi,
>>
>> CIFS "works" when I mount a Windows 7 host from my Linux host
> (3.1.1-x86_64)
>> but if I turn my machine off (Windows) and turn it back on, I get the
>> following error, is this normal? With NFS as a hardmount it just recovers,
>> with CIFS do I need to setup some sort of canary to unmount/remount?
>>
>>  $ ls /cifs_mnt
>> ls: cannot access /cifs_mnt: Cannot allocate memory
>>
> 
> This looks like a problem specific to Windows 7 or above. Quick tests on
> my test machines shows that cifs attempts to connect, times out,
> attempts to reconnect and gets -EHOSTUNREACH in case of both Windows
> Servers and Samba Servers. This is the expected behavior.
> 
> OTOH, this sounds like a problem related to an error due to the Windows
> server being unable to allocate from the system nonpaged pool (seen in
> the past). Do you see anything that is related to the error in Windows
> Event viewer?
> 
> Hi,
> 
> Yes, you are correct--
> 
> The server was unable to allocate from the system nonpaged pool because the
> server reached the configured limit for nonpaged pool allocations.
> 

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


- Suresh

Re: kernel 3.1.1 - cifs issue - ls: cannot access /cifs_mnt: Cannot allocate memory

[David Balažic]

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 ?

Regards,
David

Re: kernel 3.1.1 - cifs issue - ls: cannot access /cifs_mnt: Cannot allocate memory

[Steve French]

On Fri, Sep 21, 2012 at 6:05 PM, David Balažic <xerces9-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> 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).



--
Thanks,

Steve



--
Thanks,

Steve

Re: kernel 3.1.1 - cifs issue - ls: cannot access /cifs_mnt: Cannot allocate memory

[David Balažic]

On 22 September 2012 02:02, Steve French <smfrench-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>
>
> On Fri, Sep 21, 2012 at 6:05 PM, David Balažic <xerces9-Re5JQEeQqe8@public.gmane.orgm> 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

Re: kernel 3.1.1 - cifs issue - ls: cannot access /cifs_mnt: Cannot allocate memory

[Jeff Layton]

On Sun, 23 Sep 2012 18:02:58 +0200
David Balažic <xerces9-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:

> On 22 September 2012 02:02, Steve French <smfrench-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> >
> >
> > On Fri, Sep 21, 2012 at 6:05 PM, David Balažic <xerces9@gmail.com> 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)

These errors are typically indicative of problems on the *server*.
There's really little the linux side can do other than obey the limits
that the server advertises (which it already does). Upgrading the
kernel is unlikely to make any difference.

-- 
Jeff Layton <jlayton-eUNUBHrolfbYtjvyW6yDsg@public.gmane.org>

Re: kernel 3.1.1 - cifs issue - ls: cannot access /cifs_mnt: Cannot allocate memory

[Steve French]

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-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> On 22 September 2012 02:02, Steve French <smfrench-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>>
>>
>> On Fri, Sep 21, 2012 at 6:05 PM, David Balažic <xerces9@gmail.com> 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

Re: kernel 3.1.1 - cifs issue - ls: cannot access /cifs_mnt: Cannot allocate memory

[David Balažic]

On 24 September 2012 02:03, Steve French <smfrench-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> 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?

I tested with Windows 7 (Professional SP1 64-bit, up to date, mostly
default options).

As a user, I just want my gear to work, without needing to google for
tweaks and hacks.

Is it possible that SystemRescueCd uses some strange (kernel)
configuration that causes problems?
Because with Ubuntu as client I has fewer problems (but it might just
be chance, I only did a few quick tests).

Regards,
David