From owner-freebsd-stable@FreeBSD.ORG Thu Mar 28 15:31:28 2013 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id D9048147; Thu, 28 Mar 2013 15:31:28 +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 8DA41EDC; Thu, 28 Mar 2013 15:31:28 +0000 (UTC) Received: from [127.0.0.1] (Scott4long@pooker.samsco.org [168.103.85.57]) (authenticated bits=0) by pooker.samsco.org (8.14.5/8.14.5) with ESMTP id r2SFVQhk046128; Thu, 28 Mar 2013 09:31:26 -0600 (MDT) (envelope-from scottl@samsco.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) Subject: Re: Any objections/comments on axing out old ATA stack? From: Scott Long In-Reply-To: <1364479253.36972.77.camel@revolution.hippie.lan> Date: Thu, 28 Mar 2013 09:31:26 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: References: <51536306.5030907@FreeBSD.org> <5153EE86.8000801@FreeBSD.org> <1364479253.36972.77.camel@revolution.hippie.lan> To: Ian Lepore X-Mailer: Apple Mail (2.1503) X-Spam-Status: No, score=-50.0 required=3.8 tests=ALL_TRUSTED, T_RP_MATCHES_RCVD autolearn=unavailable version=3.3.0 X-Spam-Checker-Version: SpamAssassin 3.3.0 (2010-01-18) on pooker.samsco.org Cc: Alexander Motin , freebsd-current@FreeBSD.org, freebsd-stable@FreeBSD.org, Adrian Chadd X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Mar 2013 15:31:28 -0000 On Mar 28, 2013, at 8:00 AM, Ian Lepore 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