kernel 3.1.1 - cifs issue - ls: cannot access /cifs_mnt: Cannot allocate memory
Subsystems (2)
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
Justin.
Hi,
Unmount/remount fails, a reboot appears to be the only way to fix:
[72000.638947] INFO: task cp:29420 blocked for more than 120 seconds. [72000.638949] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. [72000.638950] cp D c32cfdb8 0 29420 1 0x00000000 [72000.638954] c334f150 00200086 00000002 c32cfdb8 00000008 00000000 c1679000 0443da4c [72000.638959] c334f2b8 f77cc900 00000020 c14a8c15 00000000 00000003 f5c240c0 f5ed5a80 [72000.638964] f5ed5a88 00011200 f5ed5a90 00000000 00011200 f5ed5a40 00011200 f5c240c0 [72000.638969] Call Trace: [72000.638973] [<c14a8c15>] ? cache_alloc_refill+0x6a/0x428 [72000.638976] [<c11c3ef5>] ? wait_for_free_request+0x85/0x110 [72000.638979] [<c10467b0>] ? abort_exclusive_wait+0x90/0x90 [72000.638982] [<c11c4a0f>] ? SendReceive+0x7f/0x2d0 [72000.638985] [<c11ac973>] ? CIFSSMBQPathInfo+0x123/0x240 [72000.638988] [<c11bea9e>] ? cifs_get_inode_info+0x29e/0x3d0 [72000.638992] [<c11b6d8c>] ? build_path_from_dentry+0x10c/0x230 [72000.638995] [<c10a4cb8>] ? do_path_lookup+0x28/0x80 [72000.638998] [<c11c0288>] ? cifs_revalidate_dentry_attr+0x118/0x1b0 [72000.639001] [<c11c0370>] ? cifs_revalidate_dentry+0x20/0x20 [72000.639004] [<c11c03be>] ? cifs_getattr+0x4e/0x110 [72000.639016] [<c11c0370>] ? cifs_revalidate_dentry+0x20/0x20 [72000.639019] [<c109d139>] ? vfs_getattr+0x19/0x40 [72000.639021] [<c109d1bd>] ? vfs_fstatat+0x5d/0x80 [72000.639024] [<c109d218>] ? vfs_stat+0x18/0x20 [72000.639027] [<c109d47e>] ? sys_stat64+0xe/0x30 [72000.639031] [<c10899d7>] ? remove_vma+0x37/0x50 [72000.639035] [<c108a80a>] ? do_munmap+0x16a/0x2b0 [72000.639038] [<c1003930>] ? math_state_restore+0x40/0x40 [72000.639042] [<c1009b23>] ? fpu_finit+0x23/0x70 [72000.639046] [<c1009bb9>] ? init_fpu+0x49/0x150 [72000.639049] [<c101f3f0>] ? vmalloc_sync_all+0x140/0x140 [72000.639053] [<c14af310>] ? sysenter_do_call+0x12/0x26 [72000.639057] INFO: task cp:29422 blocked for more than 120 seconds. [72000.639059] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. [72000.639062] cp D c3199db8 0 29422 1 0x00000000 [72000.639067] c334ee00 00200082 00000002 c3199db8 00000008 00000000 c1679000 0443dcf6 [72000.639076] c334ef68 f77cca00 00000021 c14a8c15 00000000 00000003 f5c240c0 f5ed5a80 [72000.639086] f5ed5a88 00011200 f5ed5a90 00000000 00011200 f5ed5a40 00011200 f5c240c0 [72000.639095] Call Trace: [72000.639099] [<c14a8c15>] ? cache_alloc_refill+0x6a/0x428 [72000.639104] [<c11c3ef5>] ? wait_for_free_request+0x85/0x110 [72000.639109] [<c10467b0>] ? abort_exclusive_wait+0x90/0x90 [72000.639113] [<c11c4a0f>] ? SendReceive+0x7f/0x2d0 [72000.639116] [<c11ac973>] ? CIFSSMBQPathInfo+0x123/0x240 [72000.639121] [<c11bea9e>] ? cifs_get_inode_info+0x29e/0x3d0 [72000.639125] [<c11b6d8c>] ? build_path_from_dentry+0x10c/0x230 [72000.639129] [<c10a4cb8>] ? do_path_lookup+0x28/0x80 [72000.639133] [<c11c0288>] ? cifs_revalidate_dentry_attr+0x118/0x1b0 [72000.639138] [<c11c0370>] ? cifs_revalidate_dentry+0x20/0x20 [72000.639141] [<c11c03be>] ? cifs_getattr+0x4e/0x110 [72000.639145] [<c11c0370>] ? cifs_revalidate_dentry+0x20/0x20 [72000.639149] [<c109d139>] ? vfs_getattr+0x19/0x40 [72000.639153] [<c109d1bd>] ? vfs_fstatat+0x5d/0x80 [72000.639157] [<c109d218>] ? vfs_stat+0x18/0x20 [72000.639160] [<c109d47e>] ? sys_stat64+0xe/0x30 [72000.639164] [<c10899d7>] ? remove_vma+0x37/0x50 [72000.639168] [<c108a80a>] ? do_munmap+0x16a/0x2b0 [72000.639172] [<c1003930>] ? math_state_restore+0x40/0x40 [72000.639176] [<c1009b23>] ? fpu_finit+0x23/0x70 [72000.639179] [<c1009bb9>] ? init_fpu+0x49/0x150 [72000.639183] [<c101f3f0>] ? vmalloc_sync_all+0x140/0x140 [72000.639187] [<c14af310>] ? sysenter_do_call+0x12/0x26 [72012.028045] CIFS VFS: Server 192.168.0.20 has not responded in 300 seconds. Reconnecting... [104345.704201] CIFS VFS: Send error in SessSetup = -12 [104345.704235] CIFS VFS: cifs_mount failed w/return code = -12 [104361.549636] CIFS VFS: Send error in SessSetup = -12 [104361.549726] CIFS VFS: cifs_mount failed w/return code = -12
Justin.
[Cc [email protected]]
Quoted 10 lines · Justin Piszcz
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
-----Original Message-----
From: Suresh Jayaraman [mailto:sjayaraman-IBi9RG/[email protected]]
Sent: Tuesday, November 15, 2011 8:33 AM
To: Justin Piszcz
Cc: [email protected]; [email protected]; linux-cifs
Subject: Re: kernel 3.1.1 - cifs issue - ls: cannot access /cifs_mnt: Cannot
allocate memory
[Cc [email protected]]
Quoted 3 lines · Justin Piszcz
Hi,
CIFS "works" when I mount a Windows 7 host from my Linux host
(3.1.1-x86_64)
Quoted 7 lines
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.
Quoted 35 lines · Justin Piszcz
-----Original Message-----
From: Suresh Jayaraman [mailto:sjayaraman-IBi9RG/[email protected]]
Sent: Tuesday, November 15, 2011 8:33 AM
To: Justin Piszcz
Cc: [email protected]; [email protected]; linux-cifs
Subject: Re: kernel 3.1.1 - cifs issue - ls: cannot access /cifs_mnt: Cannot
allocate memory[Cc [email protected]]
Quoted 3 lines · Justin Piszcz
Hi,
CIFS "works" when I mount a Windows 7 host from my Linux host
(3.1.1-x86_64)
Quoted 7 lines
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 memoryThis 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
-EHOSTUNREACHin 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?
Quoted 7 lines
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
Quoted 4 lines · Suresh Jayaraman
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
A message that is not in the archive (sent off-list or not yet received): CAH2r5msw6r9N2WQAVX+iHGMy++=wp4qUU1k_F+N93xLsZ9i1zg@mail.gmail.com
A message that is not in the archive (sent off-list or not yet received): CAH2r5msw6r9N2WQAVX+iHGMy++=wp4qUU1k_F+N93xLsZ9i1zg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org
Quoted 27 lines · David Balažic
Quoted 5 lines · Suresh Jayaraman
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.
Quoted 9 lines
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
Quoted 45 lines · Steve French
Quoted 27 lines · David Balažic
Quoted 5 lines · Suresh Jayaraman
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.Quoted 9 lines
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).
Quoted 5 lines
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
A message that is not in the archive (sent off-list or not yet received): CAPJ9Yc-FKLzH_BK++iL4uV59gy-dVCDGYs=ZFfsJVimWfGKdbw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org
Quoted 52 lines · On Sun, 23 Sep 2012 18:02:58 +0200 David Balažic…
Quoted 45 lines · Steve French
Quoted 27 lines · David Balažic
Quoted 5 lines · Suresh Jayaraman
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.Quoted 9 lines
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).
Quoted 5 lines
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).
Quoted 5 lines
I tried setting the
cifs_max_pendingmodule parameter, also kernel 3.4.9It 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.
Signature · 1 line
Jeff Layton <[email protected]>
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?
Quoted 60 lines · David Balažic
Quoted 45 lines · Steve French
Quoted 27 lines · David Balažic
Quoted 5 lines · Suresh Jayaraman
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.Quoted 9 lines
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).
Quoted 5 lines
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_pendingmodule parameter, also kernel 3.4.9It is better, but there are still some errors 12.
Any recommendations? (besides trying a newer kernel)
Regards,
David
Signature · 3 lines
Thanks, Steve
A message that is not in the archive (sent off-list or not yet received): CAH2r5msLRvtFOzEVR3g8Tq+j+k9D4SurBPOeez=DOL7d3_uTDg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org
Quoted 10 lines · Steve French
If it still fails with
max_pendingset 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