KINGSTON SUV400S37120G: badly formed scsi parameters

[mara43]

We have installed a freshly purchased KINGSTON SUV400S37120G SSD drive. Unfortunately there seems to be some incompatibility with smartctl:

• a wrong form factor is reported (M.2 instead of 2,5")
• the ATA Version is reported as Unknown(0x0ffe), ATA8-ACS T13/1699-D revision 6
• SMART status, attributes and thresholds cannot be read due to scsi error badly formed scsi parameters

Apart from that the drive seems to be fully operational.
This has been tested with smartctl 6.5 (SVN rev. 4383) and 6.6 (SVN rev. 4410).
I have attached to smartctl -x outputs from both versions.

[Christian Franke]

We have installed a freshly purchased KINGSTON SUV400S37120G SSD drive.

Did smartctl -x work with other drives behind same (which?) controller+driver?
Are any -d TYPE options used?

• a wrong form factor is reported (M.2 instead of 2,5")

Smartctl interprets NOMINAL FORM FACTOR field (word 168) of ATA IDENTIFY data as specified by ACS-4 and earlier: 0x3 = 2.5", 0x7 = M.2

• the ATA Version is reported as Unknown(0x0ffe), ATA8-ACS T13/1699-D revision 6

Actually bit 11 set is not yet reported as ACS-4 because this is a very recent addition to the standard. But this major version is not consistent with the reported minor version ATA8-ACS ....

Possibly the drive either returns some bogus info or some driver or firmware modifies IDENTIFY data.

• SMART status, attributes and thresholds cannot be read due to scsi error badly formed scsi parameters

If -d sat was used or was auto-detected (see -d test), please try also -d sat,12.

For further diagnostics, please provide output of:
smartctl -r ioctl,2 -i -H -A ...

Outputs from one smartctl version are sufficient.

[mara43]

• The Kingston SSD is connected directly to the mainboard (ASUS P5P43TD). So the mass storage controller should be Intel ICH10R.
• The SMART outputs for other drives (2x Seagate ST1000DM003, 1x Hitachi HDS721010KLA330, 1x SAMSUNG HD103UJ) look perfectly okay.
• No explicit -d option was set, I guess it is automatic then. smartctl --scan suggests -d scsi.
• For -d test it shows
  /dev/sda: Device of type 'scsi' [SCSI] detected
/dev/sda [SAT]: Device open changed type from 'scsi' to 'sat'
/dev/sda [SAT]: Device of type 'sat' [ATA] opened
• The output for -x -d sat,12 is attached.
• Same for -r ioctl,2 -i -H -A.

[Christian Franke]

IDENTIFY DEVICE actually returns some values which do not make sense:

===== [IDENTIFY DEVICE] DATA START (BASE-16) =====
...
160-175: fe 0f 28 00 6b 74 09 74 63 41 69 70 01 b4 67 41 ...
               ^^^^^ word 81 = 0x0028: Minor version = ATA8-ACS revision 6
         ^^^^^       word 80 = 0x0ffe: Major version = ACS-4
...
336-351: 07 00 01 00 20 20 20 20 20 20 20 20 00 00 00 00 ...
          ^          word 168, bit 0-3 = 0x7: Nominal form factor = M.2

Correct output of ACS-4 major version was added in r4417. Minor version and form factor are printed correctly by smartctl.

Leaving ticket open to investigate the SCSI errors from Linux kernel. Possibly related or duplicate: ticket #826.

[Christian Franke]

The Linux kernel returns sense data which does not make much sense in this context:

REPORT-IOCTL: Device=/dev/sda Command=SMART STATUS CHECK
 Input:   FR=0xda, SC=...., LL=...., LM=0x4f, LH=0xc2, DEV=...., CMD=0xb0
 [ata pass-through(16): 85 06 2c 00 da 00 00 00 00 00 4f 00 c2 00 b0 00 ]
  scsi_status=0x2, host_status=0x0, driver_status=0x8
  info=0x1  duration=10 milliseconds  resid=0
  >>> Sense buffer, len=18:
 00     70 00 05 00 00 00 00 0a  00 51 00 00 21 04 00 00
 10     00 00
  status=2: sense_key=5 asc=21 ascq=4
sat_device::ata_pass_through: scsi error: badly formed scsi parameters

The ​SENSE_KEY and ​ASC/ASCQ decode to ILLEGAL REQUEST: UNALIGNED WRITE COMMAND.

Interestingly this only affects some of the 28-bit SMART commands. ATA IDENTIFY and all the 48-bit ATA used with -x work.

Possibly a subtle bug in Linux SAT layer.

Same problem was reported in #826 for an older SSD using Sandforce controller.

[Christian Franke]

Please provide the kernel log messages which occur when smartctl fails. See ticket #826 for more details.

[mara43]

I just checked multiple times, there are unfortunately no kernel log messages when smartctl fails.

[Christian Franke]

After a failing smartctl command, dmesg should show at least the original ATA error and status codes. I have no idea why this is not the case.

[Taejun Heo]

The ASC/ASCQ translation is a bit obscure but this is the controller/drive failing the command and DRDY remaining in the status part. The thing is that the DRDY might be from before the command is issued. Can someone please post the dmesg output after such a failure? The kernel should have reported what happened to the command.

[Dmitry Nosachev]

I can confirm only the wrong form factor reporting (M.2 instead of 2.5") with Kingston UV400 240GB SUV400S37240G, Adaptec 7805H SAS HBA, smartctl 6.6 on CentOS Linux release 7.4.1708.

[Christian Franke]

Possibly related: tickets #826 and #1070.