From owner-freebsd-current@FreeBSD.ORG Sun Apr 21 11:32:22 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 8D1E7652 for ; Sun, 21 Apr 2013 11:32:22 +0000 (UTC) (envelope-from jdc@koitsu.org) Received: from qmta01.emeryville.ca.mail.comcast.net (qmta01.emeryville.ca.mail.comcast.net [IPv6:2001:558:fe2d:43:76:96:30:16]) by mx1.freebsd.org (Postfix) with ESMTP id 6EC5D1032 for ; Sun, 21 Apr 2013 11:32:22 +0000 (UTC) Received: from omta18.emeryville.ca.mail.comcast.net ([76.96.30.74]) by qmta01.emeryville.ca.mail.comcast.net with comcast id SbNX1l0031bwxycA1bYM2N; Sun, 21 Apr 2013 11:32:21 +0000 Received: from koitsu.strangled.net ([67.180.84.87]) by omta18.emeryville.ca.mail.comcast.net with comcast id SbYL1l00R1t3BNj8ebYMSE; Sun, 21 Apr 2013 11:32:21 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id 8EF0773A33; Sun, 21 Apr 2013 04:32:20 -0700 (PDT) Date: Sun, 21 Apr 2013 04:32:20 -0700 From: Jeremy Chadwick To: Alexander Motin Subject: Re: Any objections/comments on axing out old ATA stack? Message-ID: <20130421113220.GA34734@icarus.home.lan> References: <515B25D8.7050902@FreeBSD.org> <515BF5AE.4050804@FreeBSD.org> <515CAA04.1050108@FreeBSD.org> <20130403233815.GA65719@icarus.home.lan> <515CC704.90302@FreeBSD.org> <20130404010526.GA66858@icarus.home.lan> <515D3312.3010109@FreeBSD.org> <20130420212957.GA19158@icarus.home.lan> <5173C948.1010906@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5173C948.1010906@FreeBSD.org> User-Agent: Mutt/1.5.21 (2010-09-15) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1366543941; bh=hNAAmIq1FsQGNZRcQdNFKg2nvznNfAnPfi4itRI9ABQ=; h=Received:Received:Received:Date:From:To:Subject:Message-ID: MIME-Version:Content-Type; b=quG1breRMAzDjoEKCUz69QtYJq4Ho/r13W1z0vKgWBUTtC7z0sK4QvRHDP8+1C7AL HiNmHdmLE2Ib7QMbXA6M2jVvGV6dz2h4zYt73xIeFee+1rFQveHVVCa+ZWT6Or11ph TcYZNOrG07bgZ9x9q09ayAM902SkoimkotYmFlmnKO2LWuPAzurUe9sctQIZ3Flovm rHCD4KBMO/RjBMjFvoO95Y86AdW6QsCmZIYvjoqcVeLTWuDPLaUby/PaNdE/X1iWfI bWuedOTNzLunSeiC2eTywUEUpNyw2xRjnarpzMjnCUAd4WutYXaGhJTFNxCdABPauh aRZUqDZ+0m46A== X-Mailman-Approved-At: Sun, 21 Apr 2013 11:58:25 +0000 Cc: freebsd-current@freebsd.org, freebsd-stable@freebsd.org, Matthias Andree X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Apr 2013 11:32:22 -0000 On Sun, Apr 21, 2013 at 02:11:04PM +0300, Alexander Motin wrote: > On 21.04.2013 00:29, Jeremy Chadwick wrote: > >- The ATA commands which lead up to the error also vary. Many are for > > write requests, and from some entries I can see that the OS was doing > > NCQ writes (WRITE FPDMA QUEUED) and then suddenly decided to do a > > classic 28-bit LBA write (WRITE DMA). I'm not sure why an OS would do > > this (there's nothing optimal about it) unless there were conditions > > occurring where the OS/ATA driver said "this NCQ write isn't working > > (timeout, etc.), let me retry with a classic 28-bit LBA write". > > ATA disk driver in CAM inserts non-queued command every several > seconds of continuous load to limit possible command starvation > inside the disk. SCSI driver does alike things, but inserts ordered > command flag, that does not exist in SATA, instead of different > command. Thanks for the insights Alexander, greatly appreciated. I'm a little confused by your description, because if I'm reading it right, it sounds like it conflicts with what the ACS-2 spec states. Quoting T13/2015-D rev 3 (I'm aware it's a working draft), section 4.16.1: "If the device receives a command that is not an NCQ command while NCQ commands are in the queue, then the device shall return command aborted for the new command and for all of the NCQ commands that are in the queue." I assume this means ABRT status is returned to the host controller; if so (and by design of course), how do we differentiate between that condition and any other I/O condition that induces ABRT? Possibly in the answer is in this admission: I should probably get around to reading ATA8-AST sometime. :-) -- | Jeremy Chadwick jdc@koitsu.org | | UNIX Systems Administrator http://jdc.koitsu.org/ | | Mountain View, CA, US | | Making life hard for others since 1977. PGP 4BD6C0CB |