Is this an SSD problem or a controller problem?

Jeremy Chadwick jdc at koitsu.org
Fri Feb 15 01:13:43 UTC 2013


(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           = command          = SET FEATURES
0x90           = features         = Disable use of SATA feature
0x00 0x00 0x00 = lba_*            = n/a
0x40           = device           = n/a
0x00 0x00 0x00 = lba_*_exp        = n/a
0x00           = features_exp     = n/a
0x02           = sector_count     = Enable/Disable DMA Setup FIS Auto-Activate Optimisation
0x00           = sector_count_exp = 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 == PROBE_SETDMAAA &&
 744                     status == 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 at koitsu.org |
| UNIX Systems Administrator                http://jdc.koitsu.org/ |
| Mountain View, CA, US                                            |
| Making life hard for others since 1977.             PGP 4BD6C0CB |



More information about the freebsd-fs mailing list