From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S1752199Ab1LIRuU (ORCPT <rfc822;w@1wt.eu>);
	Fri, 9 Dec 2011 12:50:20 -0500
Received: from mail.vyatta.com ([76.74.103.46]:35190 "EHLO mail.vyatta.com"
	rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP
	id S1750836Ab1LIRuR convert rfc822-to-8bit (ORCPT
	<rfc822;linux-kernel@vger.kernel.org>);
	Fri, 9 Dec 2011 12:50:17 -0500
Date: Fri, 9 Dec 2011 09:50:14 -0800
From: Stephen Hemminger <shemminger@vyatta.com>
To: starlight@binnacle.cx, Sony Chacko <sony.chacko@qlogic.com>,
        Rajesh Borundia <rajesh.borundia@qlogic.com>
Cc: linux-kernel@vger.kernel.org, netdev <netdev@vger.kernel.org>
Subject: Re: kernel 3.1.1 message:  <IRQ> warn_alloc_failed
Message-ID: <20111209095014.14a647cd@nehalam.linuxnetplumber.net>
In-Reply-To: <6.2.5.6.2.20111208210303.03a06228@flumedata.com>
References: <6.2.5.6.2.20111208210303.03a06228@flumedata.com>
Organization: Vyatta
X-Mailer: Claws Mail 3.7.10 (GTK+ 2.24.8; x86_64-pc-linux-gnu)
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 8BIT
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On Thu, 08 Dec 2011 21:10:02 -0500
starlight@binnacle.cx wrote:

> Hello.
> 
> FYI saw several of these when running
> multiple 'rcp' commands copying multi-gigabyte
> files to/from system.
> 
> 'rcp' target files were all on an encrypted
> mirrored USB3-attached pair of 3TB hard
> drives.
> 
> One outgoing 'rcp' was to a system with
> a much slower disk (due to a USB2 attachment)
> and that transfer was putting back-pressure
> on the connection.
> 
> Kernel is running on a CentOS 6.0
> distribution.
> 
> Not subscribing to the lists, so please
> CC me with any queries.  Please note that
> email originating from most non-US MTAs
> will bounce, but I will check the list
> archives if I see any.
> 
> Can't spend a lot of time on this but am
> willing to answer a few questions.  Hopefully
> the call stack will tell the story well
> enough.

You are seeing memory allocation failures because device
is allocating a 16K (order 2) size socket buffer. You are using
netxen device, and it looks like the problem.

>>From reading the netxen driver source. The LRO buffers in this device
are very large (8060+skb overhead).
Until the driver is fixed to use fragmented page size memory,
I recommend turning off LRO.