From owner-freebsd-scsi@FreeBSD.ORG Fri Nov 9 14:18:14 2012 Return-Path: Delivered-To: freebsd-scsi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id B6322FAF; Fri, 9 Nov 2012 14:18:14 +0000 (UTC) (envelope-from prvs=1660defc6c=killing@multiplay.co.uk) Received: from mail1.multiplay.co.uk (mail1.multiplay.co.uk [85.236.96.23]) by mx1.freebsd.org (Postfix) with ESMTP id 1D4048FC15; Fri, 9 Nov 2012 14:18:13 +0000 (UTC) Received: from r2d2 ([188.220.16.49]) by mail1.multiplay.co.uk (mail1.multiplay.co.uk [85.236.96.23]) (MDaemon PRO v10.0.4) with ESMTP id md50001000534.msg; Fri, 09 Nov 2012 14:18:10 +0000 X-Spam-Processed: mail1.multiplay.co.uk, Fri, 09 Nov 2012 14:18:10 +0000 (not processed: message from valid local sender) X-MDRemoteIP: 188.220.16.49 X-Return-Path: prvs=1660defc6c=killing@multiplay.co.uk X-Envelope-From: killing@multiplay.co.uk Message-ID: <93175830FB964224A4A0B2C4A6C662B3@multiplay.co.uk> From: "Steven Hartland" To: , "John Baldwin" Subject: Re: Changing mfi max_cmds for new tbolt based cards? Date: Fri, 9 Nov 2012 14:18:17 -0000 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 X-BeenThere: freebsd-scsi@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: SCSI subsystem List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Nov 2012 14:18:14 -0000 I've been doing a lot of work over the past few weeks find and fixing bugs in the mfi driver. One of these fixes was to ensure that mfi_max_cmds is used consistently throughout the driver to ensure validation checks work as expected. During this I noticed that mfi_max_cmds is very low for current generation controllers. In my case 2208 based controller reports 1008 cmd slots, so quite a jump from the previous max which I believe was 256? I was wondering if we should look to change the how our sysctl is setup? Recently John you made the following comment: > Mess with mfi_max_cmds at your own risk. The limit was added to work around > broken mfi(4) firmware revisions that would lock up when the entire command > queue (256) was used. Just a suggestion to be cautious. It is probably > safe to use more than 128, but I would be wary of using all of the slots on > your adapter. (A verbose boost will show you the number of command slots your > firmware supports.) > http://lists.freebsd.org/pipermail/freebsd-current/2012-September/036639.html Do you have an information about this specifically:- 1. Which generation of controller? 2. Which controller firmware was effected? 3. Was there a reproducible scenario which triggered this behaviour? I'm going to test stability here but my current thinking is to change the default to -1 (controller limit) for new tbolt based controllers. N.B. Resent from correct list account, sorry for the duplicate John. Regards Steve ================================================ This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337 or return the E.mail to postmaster@multiplay.co.uk.