From mboxrd@z Thu Jan 1 00:00:00 1970 From: Steve French Subject: Re: Kernel 3.0: Instant kernel crash when mounting CIFS (also crashes with linux-3.1-rc2 Date: Thu, 18 Aug 2011 12:25:50 -0500 Message-ID: References: <20110815064734.403b630f@corrin.poochiereds.net> <3300.1313637592@jrobl> <20110818091140.385a9455@barsoom.rdu.redhat.com> <20110818130408.71c55b96@barsoom.rdu.redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Cc: Jeff Layton , "J. R. Okajima" , Jesper Juhl , linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Alan Piszcz , Steve French , linux-cifs-u79uwXL29TY76Z2rM5mHXA@public.gmane.org To: Justin Piszcz Return-path: In-Reply-To: Sender: linux-cifs-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org List-ID: On Thu, Aug 18, 2011 at 12:16 PM, Justin Piszcz wrote: > > > On Thu, 18 Aug 2011, Jeff Layton wrote: > >> On Thu, 18 Aug 2011 09:15:36 -0400 (EDT) >> Justin Piszcz wrote: >> >>> >>> >>> On Thu, 18 Aug 2011, Jeff Layton wrote: >>> >>>> On Thu, 18 Aug 2011 08:22:44 -0400 (EDT) >>>> Justin Piszcz wrote: >>>> >>>>> Justin. >>>>> >>>> >>>> To be clear -- incoming in this case is reads or writes? >>> >>> Reading from the CIFS share (Windows 7). >>> >>>> >>>> Up until 3.0 cifs.ko didn't parallelize writes from a single thread. In >>>> 3.0 I added a patchset to increase the allowable wsize and to allow the >>>> kernel to issue writes in parallel. >>> >>> Ahh, good to know, have not tried writes yet. >>> >>>> >>>> Reads still suffer from the same problem however. I'm working on a >>>> patchset that should do the same thing for them, but it requires a >>>> fairly substantial overhaul of the receive codepaths. >>> >>> Ok, that explains it then, thanks. > > > Hi, > > Watching the rsync, it ran for a while, then: > > rsync: send_files failed to open "/cifs/w1/r1/data/hs12/f4_0.JPG": Cannot > allocate memory (12) > rsync: send_files failed to open "/cifs/w1/r1/data/hs12/f4_1.JPG": Cannot > allocate memory (12) > rsync: send_files failed to open "/cifs/w1/r1/data/hs12/f4_2.JPG": Cannot > allocate memory (12) > rsync: send_files failed to open "/cifs/w1/r1/data/hs12/f4_0.JPG": Cannot > allocate memory (12) When we were testing async write to Windows 7 Pavel mentioned to me another WIndows 7 bug - which may be what you are hitting. Under stress of simultaneous operations, Windows 7 server will sometimes start responding with STATUS_INSUFF_SERVER_RESOURCES error code (mapped to posix error ENOMEM by the Linux cifs kernel client) He solved it by setting MaxWorkItems to 4096 in the Windows 7 registry. If anyone knows whether Microsoft has fixed this or has a bug #, let us know because it is easier to hit with Linux kernel 3.0 and later (to Windows 7 server). -- Thanks, Steve From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752746Ab1HRRZy (ORCPT ); Thu, 18 Aug 2011 13:25:54 -0400 Received: from mail-qw0-f46.google.com ([209.85.216.46]:49496 "EHLO mail-qw0-f46.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752439Ab1HRRZv (ORCPT ); Thu, 18 Aug 2011 13:25:51 -0400 MIME-Version: 1.0 In-Reply-To: References: <20110815064734.403b630f@corrin.poochiereds.net> <3300.1313637592@jrobl> <20110818091140.385a9455@barsoom.rdu.redhat.com> <20110818130408.71c55b96@barsoom.rdu.redhat.com> Date: Thu, 18 Aug 2011 12:25:50 -0500 Message-ID: Subject: Re: Kernel 3.0: Instant kernel crash when mounting CIFS (also crashes with linux-3.1-rc2 From: Steve French To: Justin Piszcz Cc: Jeff Layton , "J. R. Okajima" , Jesper Juhl , linux-kernel@vger.kernel.org, Alan Piszcz , Steve French , linux-cifs@vger.kernel.org Content-Type: text/plain; charset=ISO-8859-1 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Aug 18, 2011 at 12:16 PM, Justin Piszcz wrote: > > > On Thu, 18 Aug 2011, Jeff Layton wrote: > >> On Thu, 18 Aug 2011 09:15:36 -0400 (EDT) >> Justin Piszcz wrote: >> >>> >>> >>> On Thu, 18 Aug 2011, Jeff Layton wrote: >>> >>>> On Thu, 18 Aug 2011 08:22:44 -0400 (EDT) >>>> Justin Piszcz wrote: >>>> >>>>> Justin. >>>>> >>>> >>>> To be clear -- incoming in this case is reads or writes? >>> >>> Reading from the CIFS share (Windows 7). >>> >>>> >>>> Up until 3.0 cifs.ko didn't parallelize writes from a single thread. In >>>> 3.0 I added a patchset to increase the allowable wsize and to allow the >>>> kernel to issue writes in parallel. >>> >>> Ahh, good to know, have not tried writes yet. >>> >>>> >>>> Reads still suffer from the same problem however. I'm working on a >>>> patchset that should do the same thing for them, but it requires a >>>> fairly substantial overhaul of the receive codepaths. >>> >>> Ok, that explains it then, thanks. > > > Hi, > > Watching the rsync, it ran for a while, then: > > rsync: send_files failed to open "/cifs/w1/r1/data/hs12/f4_0.JPG": Cannot > allocate memory (12) > rsync: send_files failed to open "/cifs/w1/r1/data/hs12/f4_1.JPG": Cannot > allocate memory (12) > rsync: send_files failed to open "/cifs/w1/r1/data/hs12/f4_2.JPG": Cannot > allocate memory (12) > rsync: send_files failed to open "/cifs/w1/r1/data/hs12/f4_0.JPG": Cannot > allocate memory (12) When we were testing async write to Windows 7 Pavel mentioned to me another WIndows 7 bug - which may be what you are hitting. Under stress of simultaneous operations, Windows 7 server will sometimes start responding with STATUS_INSUFF_SERVER_RESOURCES error code (mapped to posix error ENOMEM by the Linux cifs kernel client) He solved it by setting MaxWorkItems to 4096 in the Windows 7 registry. If anyone knows whether Microsoft has fixed this or has a bug #, let us know because it is easier to hit with Linux kernel 3.0 and later (to Windows 7 server). -- Thanks, Steve