From owner-svn-src-stable-8@FreeBSD.ORG Thu Feb 18 16:05:27 2010 Return-Path: Delivered-To: svn-src-stable-8@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 501CE10656AA; Thu, 18 Feb 2010 16:05:27 +0000 (UTC) (envelope-from mj@feral.com) Received: from ns1.feral.com (ns1.feral.com [192.67.166.1]) by mx1.freebsd.org (Postfix) with ESMTP id 27CBA8FC14; Thu, 18 Feb 2010 16:05:26 +0000 (UTC) Received: from [192.168.0.101] (m206-63.dsl.tsoft.com [198.144.206.63]) by ns1.feral.com (8.14.3/8.14.3) with ESMTP id o1IFr7OB079807; Thu, 18 Feb 2010 07:53:07 -0800 (PST) (envelope-from mj@feral.com) Message-ID: <4B7D626A.9040301@feral.com> Date: Thu, 18 Feb 2010 07:53:14 -0800 From: Matthew Jacob User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.7) Gecko/20100111 Thunderbird/3.0.1 MIME-Version: 1.0 To: Lawrence Stewart References: <201002141938.o1EJcRpx065470@svn.freebsd.org> <4B7D4962.8070706@freebsd.org> In-Reply-To: <4B7D4962.8070706@freebsd.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender DNS name whitelisted, not delayed by milter-greylist-4.2.3 (ns1.feral.com [192.67.166.1]); Thu, 18 Feb 2010 07:53:07 -0800 (PST) Cc: svn-src-stable@FreeBSD.org, svn-src-all@FreeBSD.org, src-committers@FreeBSD.org, svn-src-stable-8@FreeBSD.org Subject: Re: svn commit: r203889 - in stable/8/sys: cam cam/ata cam/scsi dev/ahci dev/asr dev/ata dev/ciss dev/hptiop dev/hptrr dev/mly dev/mpt dev/ppbus dev/siis dev/trm dev/twa dev/usb/storage X-BeenThere: svn-src-stable-8@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SVN commit messages for only the 8-stable src tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Feb 2010 16:05:27 -0000 Just a total swag here, but reduce the openings via camcontrol to < 32, or even < 16 > > 1. Any thoughts on how to resolve the regression in the mpt driver > with the r203889 commit? > > 2. Any thoughts on the behaviour I'm seeing with the mpt_cam_event > messages? Is it possible it's just a driver issue? Is the hardware > likely bad? I'm really hoping they'll go away once the driver issue is > resolved as the freezes are fairly unacceptable on a production > machine and the hardware appears to pass all checks I've done so far. > > Cheers, > Lawrence