From owner-freebsd-questions@FreeBSD.ORG Fri Feb 15 06:02:57 2013 Return-Path: Delivered-To: freebsd-questions@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 61002E32 for ; Fri, 15 Feb 2013 06:02:57 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-ia0-x229.google.com (mail-ia0-x229.google.com [IPv6:2607:f8b0:4001:c02::229]) by mx1.freebsd.org (Postfix) with ESMTP id 365903F8 for ; Fri, 15 Feb 2013 06:02:57 +0000 (UTC) Received: by mail-ia0-f169.google.com with SMTP id j5so3020034iaf.14 for ; Thu, 14 Feb 2013 22:02:57 -0800 (PST) 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=7XQ9DWdCm5ZCN66R5tfcctYOl6GIEqdtX7WuZ7Ds8D4=; b=SPKYk/Ll8ly0ZfYGlIyPi2CTMrQVt36u7UFX6KUMug7UvHdaBwz8UmRT9+zpw9Ffip d8vaxqpS4ijns1iJw6M9tyjyZfm/qOO3OMC3zFW77E6g01HtL3AYLdPCgyCCpVch3S+m biQygsW358l63tPJCRgn961bK1uTkP/+oSfi/v3pknDqStzKSsduk3D+zdI41jdmQkp0 m9KBuNTI9PL5rOCUBs8dw3Ma5EyA5QvH5nILadGG7hWkurEIq1S6GqjOXXGCL7RTACqH HJD+AK+eFM2MvfIV+8ewBhhea64xWhqkVMXJJavIfTmPxRevEsSF2sNQU7QMQni31MQP S4zw== MIME-Version: 1.0 X-Received: by 10.50.237.6 with SMTP id uy6mr1704504igc.31.1360908176839; Thu, 14 Feb 2013 22:02:56 -0800 (PST) Sender: mavbsd@gmail.com Received: by 10.231.140.72 with HTTP; Thu, 14 Feb 2013 22:02:56 -0800 (PST) Received: by 10.231.140.72 with HTTP; Thu, 14 Feb 2013 22:02:56 -0800 (PST) In-Reply-To: <20130215011341.GA96241@icarus.home.lan> References: <20130215011341.GA96241@icarus.home.lan> Date: Fri, 15 Feb 2013 08:02:56 +0200 X-Google-Sender-Auth: 6luJqsLt5yO0T27E7vRPXPzIfk0 Message-ID: Subject: Re: Is this an SSD problem or a controller problem? From: Alexander Motin To: Jeremy Chadwick X-Mailman-Approved-At: Fri, 15 Feb 2013 06:34:37 +0000 Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: freebsd-questions@freebsd.org, fusionfoto@gmail.com X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Feb 2013 06:02:57 -0000 The analysis done by Jeremy is probably right. The device return errors in response to commands disabling capability that it reported as suppoted and enabled. That is not fatal, but just annoying. Send me please output of the 'camcontrol identify ada15 -v' to check. In case of smartctl I guess there is some more problem causing command timeout and following device reinitialization with the same errors. That may already be fixed in 9-stable branch. 15.02.2013 3:13 =D0=CF=CC=D8=DA=CF=D7=C1=D4=C5=CC=D8 "Jeremy Chadwick" =CE=C1=D0=C9=D3=C1=CC: > (Please keep me CC'd as I am not subscribed to this list) > > (Also CC'ing mav@ since he can shed some light on this too) > > Re: > http://lists.freebsd.org/pipermail/freebsd-questions/2013-February/249183= .html > > It is neither an SSD problem nor a controller problem. > > FreeBSD is issuing a specific ATA CDB command to the SSD, and the SSD > rejects this request, returning ABRT status. This is perfectly normal > per ATA specification; the "error" is harmless. > > You should open a PR on this matter, as FreeBSD should be adjusted in > some manner to deal with this situation, either via appropriate > workarounds or a drive quirk. mav@ would know what's best. > > You will need to provide output from the following commands in your PR: > > * dmesg > * camcontrol identify ada15 > * pciconf -lvcb > * Same lines you did in your Email > > Further technical details, which you can put into the PR if you want: > > Looking at src/sys/cam/ata/ata_all.c we can see that the output of the > ACB is in bytes, output per ata_cmd_string(). Thus: > > > ACB: ef 90 00 00 00 40 00 00 00 00 02 00 > > Decoding per T13/2015-D rev 3 (ATA8-ACS2) working draft spec: > > 0xef =3D command =3D SET FEATURES > 0x90 =3D features =3D Disable use of SATA feature > 0x00 0x00 0x00 =3D lba_* =3D n/a > 0x40 =3D device =3D n/a > 0x00 0x00 0x00 =3D lba_*_exp =3D n/a > 0x00 =3D features_exp =3D n/a > 0x02 =3D sector_count =3D Enable/Disable DMA Setup FIS > Auto-Activate Optimisation > 0x00 =3D sector_count_exp =3D n/a > > DMA Setup FIS is defined as: > > "7.50.16.3 Enable/Disable DMA Setup FIS Auto-Activate Optimization > > A Count field value of 02h is used to enable or disable DMA Setup FIS > Auto-Activate optimization. See SATA 2.6 for more information. The > enable/disable state for the auto-activate optimization shall be > preserved across software reset. The enable/disable state for the > auto-activate optimization shall be reset to its default state upon > COMRESET." > > This feature has to do with NCQ capability for certain types of DMA > transfers. > > src/sys/cam/ata/ata_xpt.c contains the responsible code. I could be > wrong here (mav@ please correct me), but in probestart(), there is: > > 452 case PROBE_SETDMAAA: > 453 cam_fill_ataio(ataio, > 454 1, > 455 probedone, > 456 CAM_DIR_NONE, > 457 0, > 458 NULL, > 459 0, > 460 30*1000); > 461 ata_28bit_cmd(ataio, ATA_SETFEATURES, > 462 (softc->caps & CTS_SATA_CAPS_H_DMAAA) ? 0x10 : > 0x90, > 463 0, 0x02); > 464 break; > > CTS_SATA_CAPS_H_DMAAA is defined per include/cam/cam_ccb.h as > "Auto-activation", and its name implies DMA, so this would match the > feature in question. > > This would explain why you see it when the machine boots (xpt(4) probe), > as well as when smartctl is run or smartd starts (uses xpt(4)). > > However, I noticed this piece of code in probedone(): > > 739 /* > 740 * Some HP SATA disks report supported DMA > Auto-Activation, > 741 * but return ABORT on attempt to enable it. > 742 */ > 743 } else if (softc->action =3D=3D PROBE_SETDMAAA && > 744 status =3D=3D CAM_ATA_STATUS_ERROR) { > 745 goto noerror; > > Which makes me scratch my head -- the comment and logic seems to imply > there shouldn't be any error condition reported, but you do see one. > > This also implies that the drive advertises per SATA protocol DMA AA yet > when xpt(4) tries to disable it the drive rejects that request with ABRT. > > I don't know why OCZ rejects disabling that feature, but whatever. > > Addendum note for mav@ -- we also need to add an ADA_Q_4K quirk entry to > ata_da.c for Vertex 4 SSDs ("OCZ-VERTEX4"). > > -- > | 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 | > >