SMART attributes of sleeping external HDD are returned only after the 3rd try

[droid-xx]

Device Model: ST9500325AS
Model Family: Seagate Momentus 5400.6
vid=0x0BC2, pid=0x2332
Platform: Windows 10

Commands used via an elevated prompt:

smartctl -A G:

OR

smartctl -d sat -A G:

If the drive is in spindown mode, the command prompt hangs for 1-2 minutes and then I get the following error:

Read SMART Data failed: IOCTL_SCSI_PASS_THROUGH_DIRECT failed, Error=121

If I run again the above command, it hangs again for 1-2 minutes and I get the following error:

Read Device Identity failed: IOCTL_SCSI_PASS_THROUGH_DIRECT failed, Error=121
SMART support is: Ambiguous - ATA IDENTITY DEVICE words 82-83 don't show if SMART supported.
SMART support is: Ambiguous - ATA IDENTITY DEVICE words 85-87 don't show if SMART is enabled.
                  Checking to be sure by trying SMART RETURN STATUS command.
SMART support is: Unknown - Try option -s with argument 'on' to enable it. Read SMART Data failed: IOCTL_SCSI_PASS_THROUGH_DIRECT failed, Error=433

When the command completes the second time however, File Explorer opens up at the root of the drive, and I am then able to run the above command (for the third time) successfully.

This only happens when this particular external HDD is sleeping. Other external drives that I've tried (all WD), if they're sleeping they are spinned up and give their SMART data.

[Christian Franke]

Device Model: ST9500325AS
Model Family: Seagate Momentus 5400.6
vid=0x0BC2, pid=0x2332

Is this an older Seagate USB drive?

smartctl -d sat -A G:

Drive letters address partitions, not physical drives. Using drive letters for pass-through to the underlying physical drives relies on undocumented Windows behavior and may not always work. Please retry with the (pseudo-)device name printed by smartctl --scan.

If the drive is in spindown mode, the command prompt hangs for 1-2 minutes and then I get the following error:

Read SMART Data failed: IOCTL_SCSI_PASS_THROUGH_DIRECT failed, Error=121

Error 121 is ERROR_SEM_TIMEOUT. The duration is likely 60 seconds.

The drive is possibly in SLEEP mode where it does not reply to any command until the USB bridge firmware decides to spin up the drive. This cannot be fixed by smartctl.

[droid-xx]

Replying to Christian Franke:

Hey Christian, thanks for your reply.

Is this an older Seagate USB drive?

It's a Seagate 9SCAN1-500 Expansion 500GB usb drive, I bought it maybe 4 years ago. It's healthy and have no problems with it

Please retry with the (pseudo-)device name printed by smartctl --scan.

I just tried with /dev/sdd but no luck, same results...

The duration is likely 60 seconds.

You are right, it's precisely 1 min

The drive is possibly in SLEEP mode where it does not reply to any command until the USB bridge firmware decides to spin up the drive. This cannot be fixed by smartctl.

Well *something* happens during smartctl execution which causes the drive to spin up after the 2nd time (by the way I just noticed that all my sleeping external drives also spin up at that moment...). It always follows the same pattern as described above in the ticket: same number of tries, same error message after try 1, same message after try 2, then it wakes up and I can retrieve the SMART data during the 3rd try.

Why does the bridge firmware decide to spin it up after executing the same command two consecutive times?

[Christian Franke]

This might be an error handling strategy of either the USB bridge or Windows: If commands fail twice in a row, reset the device.

Please run the following command when the drive is spun down and provide its output as a plaintext attachment:

smartctl -r ioctl,2 -n standby -i -A /dev/sdd

[droid-xx]

I attached the file. Btw the combination of cmd options in this command creates different results for some reason... It wakes up the drive after one try (again the standard 60 second timeout) instead of 2.

[Christian Franke]

The SAT layer of this USB bridge behaves strange, at least when the drive is spun down mode.

Please rerun the same command if the drive is spun up and provide its output.

[droid-xx]

Attached output of same command when the drive is spun up

[Christian Franke]

Thanks.
Conclusion: SAT layer works sane if disk is in ACTIVE/IDLE mode. It times out or returns invalid data if the disk is in SLEEP or (unlikely) in STANDBY mode. A device in SLEEP mode is activated, but too late.

Two more checks:

smartctl -r ioctl,2 -n standby -d ata /dev/sdd
smartctl -r ioctl,2 -n standby -d scsi /dev/sdd

These commands check whether the SLEEP mode of the device could be detected via Windows API or SCSI pass-through command.

[droid-xx]

Attached the following:

A.txt = smartctl -r ioctl,2 -n standby -d ata /dev/sdd (when device is active)
B.txt = smartctl -r ioctl,2 -n standby -d scsi /dev/sdd (when device is active)
C.txt = smartctl -r ioctl,2 -n standby -d ata /dev/sdd (when device is spun down)
D.txt = smartctl -r ioctl,2 -n standby -d scsi /dev/sdd (when device is spun down) - this command also spins it up

When you say that the power mode can be detected "via Windows API" do you mean the -d ata part specifically?

I'm already using the -n standby -d ata options to detect the power mode of this and other external USB drives. Without -d ata it doesn't work for none of my drives (I have checked this Seagate drive and three WD ones, all external). See ​here for the outputs I get. Can I trust the response of -n standby -d ata regarding current power mode of these drives? As far as I can observe it's reliable.

I've never seen a device in SLEEP mode when running that command though. I only get either ACTIVE/IDLE or STANDBY.

[Christian Franke]

When you say that the power mode can be detected "via Windows API" do you mean the -d ata part specifically?

Yes. This uses ​GetDevicePowerState() and skips the actual CHECK POWER MODE command if FALSE is returned. This is indicated by STANDBY (OS) in the output.

This functionality is currently only implemented for -d ata. I will add this for -d scsi and -d sat in the next weeks. It should then work for USB drives without the need of a -d option.

... Can I trust the response of -n standby -d ata regarding current power mode of these drives? As far as I can observe it's reliable.

Should be reliable if Windows has sent the standby request. Unknown if the USB bridge decided this itself.

I've never seen a device in SLEEP mode when running that command though. I only get either ACTIVE/IDLE or STANDBY.

SLEEP mode cannot be reliably detected because in this mode the drive does not accept any ATA command except the device reset signal.

---

The above results suggest that the following happens: If Windows sends a standby request (via some SCSI command), the USB bridge sends the ATA command SLEEP (instead of STANDBY IMMEDIATE) to the SATA drive. If the drive in in SLEEP mode, the USB bridge must send a reset before sending any ATA command. But it apparently does not do this reliably if the ATA command is issued via the SCSI command ATA PASS-THROUGH. This is a bug in the USB bridge firmware which cannot be fixed by smartctl.

The problem would not occur with STANDBY IMMEDIATE command. In STANDBY mode, the drive accepts ATA commands and spins up if required. Some drives spin up if SMART info is read, others don't.

[droid-xx]

Thank you for the detailed explanation. So this particular Seagate drive enters SLEEP mode instead of STANDBY, and when I try to retrieve its SMART data via smartctl while it's sleeping, it doesn't reset like it should, hence it doesn't spin up, hence all this hassle.

This was driving me crazy because I'm querying for SMART data all my drives (both in spin-up and spin-down) via a script which would get stuck for 1 minute on this drive without returning any data. It could however run smartctl three times against the disk and then I could get the data (but would get stuck for two minutes on that drive). Now the script is just writing a dummy file to the root of the drive and then deletes it, so the drive wakes up and I can get the SMART data almost instantly. It's the only solution I found.

Also from the above results and your explanation I understand that with -d ata option, Device is in STANDBY (OS) mode is reported when Windows API returns false (state 0=standby). Device is in STANDBY mode (without the "OS" part) is reported when Windows API returns true (state 1=active) but CHECK POWER MODE command reports STANDBY. The only one of my drives which returns STANDBY mode (without "OS") is an internal WD one for some reason. All the external ones return Device is in STANDBY (OS) mode.

I hope I got it right. Thanks again