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