Date: Sun, 31 Mar 2013 00:33:30 +0100 From: Matthias Andree <mandree@FreeBSD.org> To: freebsd-stable@freebsd.org Subject: Re: Any objections/comments on axing out old ATA stack? Message-ID: <5157764A.7010106@FreeBSD.org> In-Reply-To: <B236C7CE-FCDF-4F2B-8480-1CEFE549171C@samsco.org> References: <51536306.5030907@FreeBSD.org> <CAJ-Vmon-8FaLa-=F=Z3dL85FPoRr%2Bp3kt%2Btr1fo7AkOV9hhyCA@mail.gmail.com> <5153EE86.8000801@FreeBSD.org> <1364479253.36972.77.camel@revolution.hippie.lan> <B236C7CE-FCDF-4F2B-8480-1CEFE549171C@samsco.org>
next in thread | previous in thread | raw e-mail | index | archive | help
This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig7B7EFE9BC7265771E3F3A6D8 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Am 28.03.2013 16:31, schrieb Scott Long: >=20 > On Mar 28, 2013, at 8:00 AM, Ian Lepore <ian@FreeBSD.org> wrote: >=20 >> On Thu, 2013-03-28 at 09:17 +0200, Alexander Motin wrote: >>> On 28.03.2013 02:43, Adrian Chadd wrote: >>>> My main concern with the new stuff is that it requires CAM and that'= s >>>> reasonably big compared to the standalone ATA code. >>>> >>>> It'd be nice if we could slim down the CAM stack a bit first; it mak= es >>>> embedding it on the smaller devices really freaking painful. >>> >>> Are there many boards now with ATA, but without USB? But I agree, it = >>> should be checked. >>> >> >> It's not necessarily what the boards have but how they're used. We us= e >> industrial SBCs at work that have ata compact flash sockets on the boa= rd >> which we do use, and usb interfaces which we don't use. >> >> I've never tested the new ata+cam stuff on some of these boards, most >> based on Cyrix, Via, Geode, and VortexD86 chipsets. The older ata cod= e >> works, but not always very well -- for example, we usually have to set= >> hw.ata.ata_dma=3D0 for absolutely no reason we've ever been able to fi= gure >> out except that if we leave it enabled we get DMA errors and panics on= >> some CF cards and not on others. I have no idea whether to expect suc= h >> things to be better, worse, or no different by changing to the ata+cam= >> way of doing things (but I don't really have time to do extensive >> testing right now either). >> >=20 >=20 > The legacy ATA code was hard to maintain, very buggy (as you point out)= , and > is essentially unmaintained. Also, IIRC, the legacy stack simply canno= t support > NCQ tagged queueing. =2E..which is exactly why it currently is the only way to get certain Samsung drives to cooperate reliably, without stalling the kernel for prolonged times (minutes) making the computer essentially unusable once it gets under I/O load (such as "make -C /usr/src -j4 buildworld") - as the new ahci+ata+cam+... would. Details including PR reference in my other message in this thread. --------------enig7B7EFE9BC7265771E3F3A6D8 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with undefined - http://www.enigmail.net/ iEYEARECAAYFAlFXdkoACgkQvmGDOQUufZUe1wCgxo8Z7qss5JWRjr4Uqou89vLH faoAoIR/piaEP+X6umVJ9NpFnbsZBiYA =DJRN -----END PGP SIGNATURE----- --------------enig7B7EFE9BC7265771E3F3A6D8--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?5157764A.7010106>