Date: Sun, 21 Apr 2013 14:59:59 +0300 From: Alexander Motin <mav@FreeBSD.org> To: Jeremy Chadwick <jdc@koitsu.org> Cc: freebsd-current@freebsd.org, freebsd-stable@freebsd.org, Matthias Andree <mandree@freebsd.org> Subject: Re: Any objections/comments on axing out old ATA stack? Message-ID: <CAO4K=PVd9fOAn3F_4u99MPkbBzJasFgSC188FBZu%2BMEZTcAGpw@mail.gmail.com> In-Reply-To: <20130421113220.GA34734@icarus.home.lan> References: <C699FE76-B456-49C7-8D3A-DD54F98DAFC1@samsco.org> <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> <20130421113220.GA34734@icarus.home.lan>
next in thread | previous in thread | raw e-mail | index | archive | help
ATA controller drivers are delaying conflicting commands, avoiding conflicts in device. 21.04.2013 14:32 =D0=CF=CC=D8=DA=CF=D7=C1=D4=C5=CC=D8 "Jeremy Chadwick" <jd= c@koitsu.org> =CE=C1=D0=C9=D3=C1=CC: > 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 doi= ng > > > 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 condition= s > > > occurring where the OS/ATA driver said "this NCQ write isn't workin= g > > > (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 | >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAO4K=PVd9fOAn3F_4u99MPkbBzJasFgSC188FBZu%2BMEZTcAGpw>