From owner-freebsd-scsi@FreeBSD.ORG Thu Apr 29 14:21:42 2010 Return-Path: Delivered-To: freebsd-scsi@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1DE43106566B for ; Thu, 29 Apr 2010 14:21:42 +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 CBDB88FC17 for ; Thu, 29 Apr 2010 14:21:41 +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 , Pete French Subject: Re: MFC of "Large set of CAM improvements" breaks I/O to Adaptec 29160 SCSI controller X-BeenThere: freebsd-scsi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SCSI subsystem List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Apr 2010 14:21:42 -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"