On systems with SAS SED drives, hdparm does not appear to work - drive sensing fails. We used SAS drives from two different manufacturers - Toshiba and Micron, and 4 different kernels - RHEL 3.10 from RHEL 7.2, Mainline 4.4.21, 4.4.36 and 4.9.3. The exact same error is reported on all kernels.
Please let us know anything else we can collect to diagnose the cause and we would be happy to do so.
System
Dell FC630 connected to two drives. First is a dual ported Micron SAS drive and the second is a dual ported Toshiba SAS drive. Drives are behind PERC 12 Gbps SAS controllers (LSI 3108, megaraid_sas module). However, the controllers are in HBA mode (JBOD), not RAID mode, so the drives are being directly passed through to the OS with no controller translation. This can be confirmed by the sg3_utils package, wherein sginfo correctly reports the drive. We also tried the same experiment with a Supermicro system with a similar (to PERC) LSI 3108 controller in HBA mode with the same results. Both the Micron and the Toshiba SAS drives are failing detection, but a third SATA drive (on the same controller) is correctly being detected. This appears to be a SAS issue. Removing the SATA drive and leaving only the SAS drives on the controller (either one or both drives) doesn't change the results.
OS
CentOS 7.2 with all patches - Redhat 3.10 kernel. We also tried this with mainline 4.4.21, 4.4.36 and 4.9.3 kernels (same CentOS 7.2 distro) with the same results.
Here's the output from hdparm (hdparm version 9.50)
root@primary hdparm-9.50]# ./hdparm -I /dev/sda
/dev/sda:
SG_IO: bad/missing sense data, sb[]: 70 00 05 00 00 00 00 0d 00 00 00 00 20 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
ATA device, with non-removable media
Standards:
Likely used: 1
Configuration:
Logical max current
cylinders 0 0
heads 0 0
sectors/track 0 0
--
Logical/Physical Sector size: 512 bytes
device size with M = 10241024: 0 MBytes
device size with M = 10001000: 0 MBytes
cache/buffer size = unknown
Capabilities:
IORDY not likely
Cannot perform double-word IO
R/W multiple sector transfer: not supported
DMA: not supported
PIO: pio0
[root@primary hdparm-9.50]# ./hdparm -I /dev/sdb
/dev/sdb:
SG_IO: bad/missing sense data, sb[]: 70 00 05 00 00 00 00 0d 00 00 00 00 20 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
ATA device, with non-removable media
Standards:
Likely used: 1
Configuration:
Logical max current
cylinders 0 0
heads 0 0
sectors/track 0 0
--
Logical/Physical Sector size: 512 bytes
device size with M = 10241024: 0 MBytes
device size with M = 10001000: 0 MBytes
cache/buffer size = unknown
Capabilities:
IORDY not likely
Cannot perform double-word IO
R/W multiple sector transfer: not supported
DMA: not supported
PIO: pio0
[root@primary hdparm-9.50]# ./hdparm -I /dev/sdc
/dev/sdc:
ATA device, with non-removable media
Model Number: INTEL SSDSC2BB120G6R
Serial Number: PHWA626102PJ120CGN
Firmware Revision: G201DL2B
Media Serial Num:
Media Manufacturer:
Transport: Serial, ATA8-AST, SATA 1.0a, SATA II Extensions, SATA Rev 2.5, SATA Rev 2.6, SATA Rev 3.0
Standards:
Used: unknown (minor revision code 0x006d)
Supported: 10 9 8 7 6 5
Likely used: 10
Configuration:
Logical max current
cylinders 16383 0
heads 16 0
sectors/track 63 0
--
LBA user addressable sectors: 234441648
LBA48 user addressable sectors: 234441648
Logical Sector size: 512 bytes
Physical Sector size: 4096 bytes
Logical Sector-0 offset: 0 bytes
device size with M = 10241024: 114473 MBytes
device size with M = 10001000: 120034 MBytes (120 GB)
cache/buffer size = unknown
Form Factor: 2.5 inch
Nominal Media Rotation Rate: Solid State Device
Capabilities:
LBA, IORDY(can be disabled)
Queue depth: 32
Standby timer values: spec'd by Standard, no device specific minimum
R/W multiple sector transfer: Max = 1 Current = 1
DMA: mdma0 mdma1 mdma2 udma0 udma1 udma2 udma3 udma4 udma5 *udma6
Cycle time: min=120ns recommended=120ns
PIO: pio0 pio1 pio2 pio3 pio4
Cycle time: no flow control=120ns IORDY flow control=120ns
Commands/features:
Enabled Supported:
* SMART feature set
Security Mode feature set
* Power Management feature set
Write cache
* Look-ahead
* WRITE_BUFFER command
* READ_BUFFER command
* NOP cmd
* DOWNLOAD_MICROCODE
* 48-bit Address feature set
* Mandatory FLUSH_CACHE
* FLUSH_CACHE_EXT
* SMART error logging
* SMART self-test
* General Purpose Logging feature set
* WRITE_{DMA|MULTIPLE}_FUA_EXT
* 64-bit World wide name
* IDLE_IMMEDIATE with UNLOAD
* WRITE_UNCORRECTABLE_EXT command
* {READ,WRITE}_DMA_EXT_GPL commands
* Segmented DOWNLOAD_MICROCODE
* unknown 119[6]
* unknown 119[8]
* Gen1 signaling speed (1.5Gb/s)
* Gen2 signaling speed (3.0Gb/s)
* Gen3 signaling speed (6.0Gb/s)
* Native Command Queueing (NCQ)
* Phy event counters
* NCQ priority information
* READ_LOG_DMA_EXT equivalent to READ_LOG_EXT
* Software settings preservation
* SMART Command Transport (SCT) feature set
* SCT Write Same (AC2)
* SCT Error Recovery Control (AC3)
* SCT Features Control (AC4)
* SCT Data Tables (AC5)
* SANITIZE_ANTIFREEZE_LOCK_EXT command
* SANITIZE feature set
* BLOCK_ERASE_EXT command
* reserved 69[3]
* reserved 69[4]
* Data Set Management TRIM supported (limit 4 blocks)
* Deterministic read ZEROs after TRIM
Security:
Master password revision code = 65534
supported
not enabled
not locked
frozen
not expired: security count
supported: enhanced erase
4min for SECURITY ERASE UNIT. 4min for ENHANCED SECURITY ERASE UNIT.
Logical Unit WWN Device Identifier: 55cd2e404c7d0ca0
NAA : 5
IEEE OUI : 5cd2e4
Unique ID : 04c7d0ca0
Checksum: correct
Here's the output from the sg3_utils toolchain
[root@primary GNU-Linux]# sginfo -T /dev/sda
nothing selected so do a short INQUIRY
cdb: 12 00 00 00 24 00
INQUIRY response (cmd: 0x12)
Device Type 0
Vendor: MICRON
Product: S610DC-1920SED
Revision level: MA13
[root@primary GNU-Linux]# sginfo -T /dev/sdb
nothing selected so do a short INQUIRY
cdb: 12 00 00 00 24 00
INQUIRY response (cmd: 0x12)
Device Type 0
Vendor: TOSHIBA
Product: PX04SRB192
Revision level: AM04
[root@primary hdparm-9.50]# sginfo -T /dev/sdc
nothing selected so do a short INQUIRY
cdb: 12 00 00 00 24 00
INQUIRY response (cmd: 0x12)
Device Type 0
Vendor: ATA
Product: INTEL SSDSC2BB12
Revision level: DL2B
Perhaps the two SAS drives do not implement the SATA IDENTIFY command, which is what hdparm is sending them. If they don't have that command, they will fail the request.
sginfo probably sends pure SCSI commands to the drives, which is why it works (SAS drives normally speak SCSI).
hdparm is for ATA/SATA drives, and for any drives/chips that understand ATA/SATA commands (including some USB enclosures).
Cheers