4

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?

  • 2
    Hi, was your hdd connected through a USB port? In this case, you can take a look here and verify if a new scan (with the hdd attached to a sata port) gives the same error. – PieCot May 11 '16 at 8:28
  • 1
    yes through USB. 3 TB drive but it is not a sata drive. external usb – Kalamalka Kid May 11 '16 at 10:48
  • Has it others interface than USB? If so, you can try to use another interface to repeat the scan. However, probably the error is due to the USB connection and your drive could actually be ok. – PieCot May 11 '16 at 10:58
  • no it is USB only - external drive – Kalamalka Kid May 11 '16 at 11:02
  • The drive reads & writes data just fine and mounts on startup as well. I just simply cannot run this commandm on this drive without errors – Kalamalka Kid May 11 '16 at 11:04
7

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.

  • hi, thanks for taking the tiem to reply, my machine has no available sata ports (theres only 1 on intel nuc).; – Kalamalka Kid May 15 '16 at 21:19
1

This problem is usually caused by 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 ATA commands over SCSI over USB. The reason this is 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. 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.

0

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

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.