Date: Sat, 5 Sep 2009 13:05:14 -0600 From: Scott Long <scottl@samsco.org> To: Alexander Motin <mav@freebsd.org> Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org, Ivan Voras <ivoras@freebsd.org>, John Baldwin <jhb@freebsd.org> Subject: Re: svn commit: r196777 - head/sys/dev/ahci Message-ID: <A21313CC-49DB-4F0A-B2DF-71FB13C1D8F5@samsco.org> In-Reply-To: <4AA20249.9000301@FreeBSD.org> References: <200909031237.n83CbIgk032551@svn.freebsd.org> <20090903114121.C20031@pooker.samsco.org> <9bbcef730909031245o7c380925sd29b2cc976c4d7dd@mail.gmail.com> <200909031602.01222.jhb@freebsd.org> <4AA20249.9000301@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?A21313CC-49DB-4F0A-B2DF-71FB13C1D8F5>