Project

General

Profile

Bug #1787

SATL fails to handle returned SMART sense data

Added by Jason Williams about 8 years ago. Updated almost 6 years ago.

Status:
Resolved
Priority:
Normal
Assignee:
Category:
kernel
Start date:
2011-11-17
Due date:
% Done:

100%

Estimated time:
Difficulty:
Medium
Tags:

Description

It appears that a SCSI error we are seeing is not an error but the Solaris/Illumos SCSI subsystem not handling the SCSI/ATA Translation (SAT) standard properly. It occurs when you run smartctl from smartmontools to query SMART data from a SATA drive attached to a SAS controller via SCSI/ATA Translation:

smartctl -a -d sat /dev/rdsk/<device>

The error thrown by the SCSI subsystem is:

WARNING: /pci@0,0/pci8086,3a40@1c/pci1000,3020@0/iport@8/disk@w5e83a97010004561,0 (sd42):
Error for Command: <undecoded cmd 0x85> Error Level: Recovered
Requested Block: 0 Error Block: 0
Vendor: ATA Serial Number: A117D0111450
Sense Key: Soft_Error
ASC: 0x0 (<vendor unique code 0x0>), ASCQ: 0x1d, FRU: 0x0

In this case the 0x85 op code is the command for ATA PASSTHROUGH in the SAT standard. When the controller returns the SCSI response, the ATA RETURN DESCRIPTOR is stored in the response as sense data (as per the standard). However, Illumos doesn't discern that sense data is normal and expected for ATA PASSTHROUGH commands and treats the sense data as indicative of an error...triggering the error above.

The SCSI subsystem needs to be updated to discern that sense data in response to an ATA PASSTHROUGH SAT command is not necessarily an error.

Repro info:

OS: OpenIndiana 151a
Drive: OCZ Deneva R SLC 50GB SATA SSD (but reproducible on any SATA drive) 1.35 firmware
Controller: LSI 9211-8i SAS-2 controller w/ 11.0 Initiator Target firmware
Smartmontools 5.42

Commands that reproduce error:

smartctl -a -d sat /dev/rdsk/<sata_disk_id>
smartctl -H -d sat /dev/rdsk/<sata_disk_id>

History

#1

Updated by Robert Mustacchi almost 6 years ago

  • Tags deleted (needs-triage)
  • % Done changed from 0 to 100
  • Assignee set to Yuri Pankov
  • Status changed from New to Resolved

Resolved in 2acf01fd73874e9b92c066e8deb5270d92b083ba.

Also available in: Atom PDF