From owner-freebsd-stable@FreeBSD.ORG Thu Apr 29 13:47:35 2010 Return-Path: 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 CC07D1065672; Thu, 29 Apr 2010 13:47:35 +0000 (UTC) (envelope-from rnoland@FreeBSD.org) Received: from gizmo.2hip.net (gizmo.2hip.net [64.74.207.195]) by mx1.freebsd.org (Postfix) with ESMTP id 89F798FC1F; Thu, 29 Apr 2010 13:47:35 +0000 (UTC) Received: from [10.170.20.44] (nat-170-142-177-44.tn.gov [170.142.177.44]) (authenticated bits=0) by gizmo.2hip.net (8.14.3/8.14.3) with ESMTP id o3TDlVWa018098 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 29 Apr 2010 09:47:32 -0400 (EDT) (envelope-from rnoland@FreeBSD.org) Message-ID: <4BD98DE2.8020703@FreeBSD.org> Date: Thu, 29 Apr 2010 08:47:14 -0500 From: Robert Noland Organization: FreeBSD User-Agent: Thunderbird 2.0.0.19 (X11/20090218) MIME-Version: 1.0 To: Scott Long References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=0.8 required=5.0 tests=AWL, BAYES_00, FH_DATE_PAST_20XX, RDNS_DYNAMIC,SPF_SOFTFAIL autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on gizmo.2hip.net Cc: freebsd-scsi@FreeBSD.org, Alexander Motin , FreeBSD Stable , Andy Farkas , Pete French Subject: Re: MFC of "Large set of CAM improvements" breaks I/O to Adaptec 29160 SCSI controller X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Apr 2010 13:47:35 -0000 Scott Long wrote: > On Apr 29, 2010, at 2:50 AM, Pete French wrote: > >>> Thanks. First step successful - I can steadily reproduce problem on >>> CURRENT. raidtest with 200 I/O streams over gmirror of two disks on same >>> channel triggers issue in seconds. Any I/O on channel dying after both >>> disks report "Queue full" error same time. The rest of system works >>> fine. If I preliminarily manually adjust queue depth of one disk - >>> everything works fine. I'll investigate it tomorrow. >> Glad you have managed to dupliate it - the queue depth thing is >> inetersting, what changes did you make ? I can try them here and see >> if they improve the situation on either of my two machines. >> > > For the record, queue-full is a common, expected condition in CAM. It's not something that should be avoided =-) Should we maybe have a counter in sysctl rather than flooding the console with these messages then? robert. > Scott > > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org"