From owner-svn-src-all@FreeBSD.ORG Sat Sep 5 19:05:18 2009 Return-Path: Delivered-To: svn-src-all@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 665C71065692; Sat, 5 Sep 2009 19:05:18 +0000 (UTC) (envelope-from scottl@samsco.org) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.freebsd.org (Postfix) with ESMTP id 13BDF8FC17; Sat, 5 Sep 2009 19:05:17 +0000 (UTC) Received: from [IPv6:::1] (pooker.samsco.org [168.103.85.57]) (authenticated bits=0) by pooker.samsco.org (8.14.2/8.14.2) with ESMTP id n85J5Emn011253; Sat, 5 Sep 2009 13:05:14 -0600 (MDT) (envelope-from scottl@samsco.org) Mime-Version: 1.0 (Apple Message framework v1075.2) Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes From: Scott Long In-Reply-To: <4AA20249.9000301@FreeBSD.org> Date: Sat, 5 Sep 2009 13:05:14 -0600 Content-Transfer-Encoding: 7bit Message-Id: References: <200909031237.n83CbIgk032551@svn.freebsd.org> <20090903114121.C20031@pooker.samsco.org> <9bbcef730909031245o7c380925sd29b2cc976c4d7dd@mail.gmail.com> <200909031602.01222.jhb@freebsd.org> <4AA20249.9000301@FreeBSD.org> To: Alexander Motin X-Mailer: Apple Mail (2.1075.2) X-Spam-Status: No, score=-2.5 required=3.8 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.1.8 X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) on pooker.samsco.org Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org, Ivan Voras , John Baldwin Subject: Re: svn commit: r196777 - head/sys/dev/ahci X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Sep 2009 19:05:18 -0000 On Sep 5, 2009, at 12:16 AM, Alexander Motin wrote: > John Baldwin wrote: >> On Thursday 03 September 2009 3:45:07 pm Ivan Voras wrote: >>> But ciss doesn't reference it at all so either it deviously >>> assumes it >>> or is independent of it. >> >> Actually, it may be much worse, it may be that the author of ciss >> (4) new that >> ciss(4)'s largest supported I/O size was larger than 128k so they >> didn't >> bother handling the limit at all giving the false impression the >> hardware has >> no limit. > > In cases of ATA and CAM infrastructures it was is so, that if driver > does not sets max_iosize or maxio respectively, it uses DFLTPHYS. So > problem is only about non-ATA/CAM RAIDs or cases where wrong value > could > be specified explicitly. > > ciss(4) driver was explicitly limited to 64K, until somebody could > review it's capabilities. > Right, but I don't want people blindly changing this in any of the CAM drivers without understanding what is going on. Also, there are plenty of non-CAM block drivers that haven't been audited very well yet, if at all. Scott