From owner-freebsd-current@FreeBSD.ORG Sun Apr 21 12:00:00 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 99277BF7; Sun, 21 Apr 2013 12:00:00 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-pb0-x22c.google.com (mail-pb0-x22c.google.com [IPv6:2607:f8b0:400e:c01::22c]) by mx1.freebsd.org (Postfix) with ESMTP id 689C610E5; Sun, 21 Apr 2013 12:00:00 +0000 (UTC) Received: by mail-pb0-f44.google.com with SMTP id wz17so21054pbc.31 for ; Sun, 21 Apr 2013 05:00:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=UC9vfEGLpseabSkmPl+neUyWUV3NryfJ02XyI6Xy23k=; b=eJsfv5fS2SEaIFIUQGBt21CuYZ6VwaITMPXTkD3VI+ZQYDd6dNkxB0R8eV+2xgDQLP PfTA1SPyu/6fzXF8+JmWKb/9lsP38bn/gRf5UzPBhKdNxZx2CG51Lcpub1oAvYwyvM6s uQL/69yH55+5k///lMLrOdrpxnyZVhJjtYj4YU8Ic1rAZEi071JmysLnw0sBud8hA/0U h0zlVLR2ewjz7UNSNQIaHVePIVtKdQaSMZWW0pO8imaaNuGaROOmozilfyUUT5NkZzVY tyPzsztqHV01DCv8FHijC6l0KvDeOn4hw5YTeG8PFNBxy9P5bHlAHkNdANZ+DfNYdhBQ OvUQ== MIME-Version: 1.0 X-Received: by 10.68.170.228 with SMTP id ap4mr26964495pbc.209.1366545600098; Sun, 21 Apr 2013 05:00:00 -0700 (PDT) Sender: mavbsd@gmail.com Received: by 10.68.211.103 with HTTP; Sun, 21 Apr 2013 04:59:59 -0700 (PDT) Received: by 10.68.211.103 with HTTP; Sun, 21 Apr 2013 04:59:59 -0700 (PDT) In-Reply-To: <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> <20130421113220.GA34734@icarus.home.lan> Date: Sun, 21 Apr 2013 14:59:59 +0300 X-Google-Sender-Auth: 0mfE0dhdJeGAIYUBwXCrPG9FjSc Message-ID: Subject: Re: Any objections/comments on axing out old ATA stack? From: Alexander Motin To: Jeremy Chadwick Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.14 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 12:00:00 -0000 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" =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 | >