Date: Thu, 28 Mar 2013 09:31:26 -0600 From: Scott Long <scottl@samsco.org> To: Ian Lepore <ian@FreeBSD.org> Cc: Alexander Motin <mav@FreeBSD.org>, freebsd-current@FreeBSD.org, freebsd-stable@FreeBSD.org, Adrian Chadd <adrian@FreeBSD.org> Subject: Re: Any objections/comments on axing out old ATA stack? Message-ID: <B236C7CE-FCDF-4F2B-8480-1CEFE549171C@samsco.org> In-Reply-To: <1364479253.36972.77.camel@revolution.hippie.lan> 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>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mar 28, 2013, at 8:00 AM, Ian Lepore <ian@FreeBSD.org> wrote: > 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. >>>=20 >>> It'd be nice if we could slim down the CAM stack a bit first; it = makes >>> embedding it on the smaller devices really freaking painful. >>=20 >> Are there many boards now with ATA, but without USB? But I agree, it=20= >> should be checked. >>=20 >=20 > It's not necessarily what the boards have but how they're used. We = use > industrial SBCs at work that have ata compact flash sockets on the = board > which we do use, and usb interfaces which we don't use. >=20 > 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 = code > 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 = figure > 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 = such > 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 The legacy ATA code was hard to maintain, very buggy (as you point out), = and is essentially unmaintained. Also, IIRC, the legacy stack simply cannot = support NCQ tagged queueing. I think that Alexander has done a superb job with both developing and = supporting the CAM_ATA stack. Scott
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?B236C7CE-FCDF-4F2B-8480-1CEFE549171C>