From owner-freebsd-stable@FreeBSD.ORG  Mon Aug 13 18:36:07 2007
Return-Path: <owner-freebsd-stable@FreeBSD.ORG>
Delivered-To: freebsd-stable@freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34])
	by hub.freebsd.org (Postfix) with ESMTP id 48D5416A418
	for <freebsd-stable@freebsd.org>; Mon, 13 Aug 2007 18:36:07 +0000 (UTC)
	(envelope-from hg@queue.to)
Received: from pickle.queue.to (pickle.queue.to [71.180.69.18])
	by mx1.freebsd.org (Postfix) with ESMTP id BCA6413C4DE
	for <freebsd-stable@freebsd.org>; Mon, 13 Aug 2007 18:36:06 +0000 (UTC)
	(envelope-from hg@queue.to)
Received: (qmail 36863 invoked from network); 13 Aug 2007 14:36:05 -0400
Received: from cally.queue.to (172.16.0.6)
	by pickle.queue.to with ESMTP; 13 Aug 2007 14:36:05 -0400
Message-ID: <46C0A495.4060706@queue.to>
Date: Mon, 13 Aug 2007 14:36:05 -0400
From: Howard Goldstein <hg@queue.to>
User-Agent: Thunderbird 2.0.0.6 (X11/20070802)
MIME-Version: 1.0
To: freebsd-stable@freebsd.org
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Subject: 3ware RAID ctrlr: twe0: twe_map_request: malloc failed.
 Informational or am I screwed?
X-BeenThere: freebsd-stable@freebsd.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Production branch of FreeBSD source code <freebsd-stable.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-stable>, 
	<mailto:freebsd-stable-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-stable>
List-Post: <mailto:freebsd-stable@freebsd.org>
List-Help: <mailto:freebsd-stable-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-stable>,
	<mailto:freebsd-stable-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Mon, 13 Aug 2007 18:36:07 -0000

Would someone confirm (or disabuse!) me of the belief that these 3ware
Escalade 8106-LP2 (2 port sata raid controllers) related messages are
informational and the UFS device is retrying after it sees ENOMEM
causing these?

Aug 13 10:29:48 cally kernel: twe0: twe_map_request: malloc failed
Aug 13 10:33:04 cally kernel: twe0: twe_map_request: malloc failed
Aug 13 11:05:37 cally kernel: twe0: twe_map_request: malloc failed
Aug 13 11:14:55 cally kernel: twe0: twe_map_request: malloc failed
Aug 13 12:07:44 cally kernel: twe0: twe_map_request: malloc failed
Aug 13 12:28:05 cally kernel: twe0: twe_map_request: malloc failed
Aug 13 14:29:59 cally kernel: twe0: twe_map_request: malloc failed

(Either way but particularly in the event the data are being lost is
there a sysctl or kernel build option to supply a bit more memory in
advance?)