Hard Drive error: bad/missing sense data

Question

I recently tried to check the spin down time of my hard drive with the following command:

sudo hdparm -I /dev/sdb | grep level

and got the error:

SG_IO: bad/missing sense data, sb[]:  70 00 05 00 00 00 00 0a 00 00 00 00 24 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

The drive reads & writes data just fine and mounts on startup as well. I just simply cannot run this command on this drive without errors

What does this mean, and how can I resolve the issue?

Answer 1

I had a similar problem with my Seagate backup slim and WD black SCSI drives. And I was using hdparm as well. What worked for me is thesdparm utility.

Install with

sudo apt install sdparm

Get all parameters/settings with

sudo sdparm -l -a /dev/sdX

Here -a gets all output fields and -l gets the long output i.e. explanation of the output fields. /dev/sdX is the drive in question (similar to /dev/sda).

Get the spindown timer and the STANDBY flag with:

sudo sdparm -l --get SCT /dev/sdX
sudo sdparm -l --get STANDBY /dev/sdX

The spindown time SCT here is in milliseconds and STANDBY flag is the spindown timer on/off (1/0) switch

If your output is similar to:

# STANDBY     0  [cha: y, def:  1, sav:  1]
# SCT       4294967286  [cha: y, def:18000, sav:18000]

This means that your device is not set to spin down.

If you want you can change these settings for the current session with:

sudo sdparm -l --set SCT=6000 /dev/sdX
sudo sdparm -l --set STANDBY=1 /dev/sdX

These settings will be lost on reboot.

Change permanently with:

sudo sdparm -l --save --set SCT=6000 /dev/sdX
sudo sdparm -l --save --set STANDBY=1 /dev/sdX

Here I chose 6 seconds (6000 milliseconds) but you can choose according to your requirements.

If for some reason, you cannot save your settings, you can put this in your /etc/rc.local to set these on boot:

sdparm -l --set SCT=6000 --set STANDBY=1 /dev/sdX

I hope this helps.

Answer 2

This problem is usually caused by broken/incorrect USB-SATA bridge implementation and should be visible only with USB connected disk enclosures.

In case of external USB disk, the system needs to talk to the SATA drive inside the enclosure using UAS (USB Attached SCSI) protocol over SAT (SCSI / ATA Translation) to send raw ATA commands (sent by hdparm or smartctl) over SCSI over USB. The reason this protocol chain so complex is due historical reasons.

Somewhere in the chain USB → UAS → SCSI → SAT → SATA some piece of hardware has incorrect implementation. Usually all of this is done by a single microchip inside the enclosure called USB-SATA bridge and some well known variants are ASM1051, ASM1053 and ASM1153. Of these, the ASM1051 is known to be buggy and UAS should be avoided with any hardware containing this chip. ASM1053 and ASM1153 may or may not work depending on actual firmware inside the chip (the manufacturer is allowed to customize the firmware, the reference implementation does work correctly). For example, many enclosures made by Seagate use ASM1153 with custom firmware and have problems with some ATA commands even if the same chip does work correctly with reference firmware. (For example, some enclosures by Seagate work as long as OS never sends any 12 or 16 bit commands. Linux usb_storage supports quirk t for this purpose.) The end user usually cannot replace the firmware so if you have a bad chip/firmware your only option is to complain to the manufacturer. In case of Seagate, they "fix" the problem by stating that they officially support Windows and OS X only (and those operating systems do not support configuring SATA devices nor fetching S.M.A.R.T. data over USB so everything is "working"). Seagate is nowdays officially working with Linux community so perhaps their products will actually work in the future.

The only real way to figure out the bridge chip is to dismantle the enclosure and inspect the markings in the actual microchips.

Update: "Seagate Backup Plus Hub" enclosures have correctly working USB-SATA bridge and UAS works correctly (Note that this is different product from "Seagate Backup Plus"!) However, due to poor history by Seagate's enclosures, the Linux kernel applies the quirk t by default which prevents this enclosure from using all SATA features. You can enable full SATA support including S.M.A.R.T. features with following command:

echo "0bc2:ab38:" > /sys/module/usb_storage/parameters/quirks

Note the trailing colon and nothing after that - it disables all built-in quirks for the selected vendor:product. Check your vendor and product ids with lsusb if needed.

If your device is buggy enough, you may need to totally disable UAS support. This can be done with the u quirk. For example, if I would like to disable UAS support on Seagate Backup Plus Hub, I'd run following as root:

echo "0bc2:ab38:u" > /sys/module/usb_storage/parameters/quirks

After that, the external disk will use only slower but usually working USB storage device features and things end up working... slowly. If you only need to transfer some big files the difference is not that bad. If you have lots of small files, the difference between having working UAS support may be more than 10x speed difference.

Answer 3

looks like your drive controller doesn't support that method of enquiry, not all usb sata chipsets are created equal. You don't say what model of drive or controller you are using so its hard to offer more advice here.

You could test this by plugging into another usb controller or using a different drive with the same controller or better still direct via SATA.

3TB drives can be too big for some usb2 era controllers so i would recommend getting a reputable usb3 sata bridge instead, it will be much faster as well.

Answer 4

Additional info for systems/devices for which the above and/or modprobe tweaks have no effect (eg Raspberry Pi 3):

The quirks must be added to the boot parameters. For RPi 3/Raspbian, the boot parameters are in the file /boot/cmdline.txt.

[other command line parameters...] usb_storage.quirks=YOUR_VENDOR_ID:YOUR_DEVICE_ID:QUIRK_FLAGS

In my case, I needed to clear the quirks flag for my device, so I added this to /boot/cmdline.txt:

usb_storage.quirks=0bc2:a0a4:

This solved my issue, hopefully it helps someone else