SMART responses hanging *BOOT drives?

[vitorio]

Not sure if this is the right place to put this, but:

There seems to be some evidence that querying the *BOOT drives (and however that's exposed by firmware) for SMART responses hangs them up?

• Multiple devices: https://forums.adafruit.com/viewtopic.php?f=58&t=150232#p741767
• PyPortal: https://forums.adafruit.com/viewtopic.php?f=60&t=149791&p=742995#p742995

I dunno if that's something that gets fixed by Adafruit or upstream, but there's two data points for it.

Thanks!

[vitorio]

Ran some more tests in the PyPortal thread with SMART tools; they definitely lock up PORTALBOOT and not CIRCUITPY.

[dhalbert]

smartmontools source available here: https://github.com/mirror/smartmontools

Trying a few USB sticks. Most respond like this:

$ sudo smartctl --all -d scsi /dev/sdc
smartctl 6.6 2016-05-31 r4324 [x86_64-linux-4.15.0-47-generic] (local build)
Copyright (C) 2002-16, Bruce Allen, Christian Franke, www.smartmontools.org

=== START OF INFORMATION SECTION ===
Vendor:               USB 2.0
Product:              USB Flash Drive
Revision:             1100
User Capacity:        4,057,989,120 bytes [4.05 GB]
Logical block size:   512 bytes
>> Terminate command early due to bad response to IEC mode page
A mandatory SMART command failed: exiting. To continue, add one or more '-T permissive' options.

I'll attempt to emulate the above.

A high-quality Samsung stick I have does this:

$ sudo smartctl --all -d scsi /dev/sdc
smartctl 6.6 2016-05-31 r4324 [x86_64-linux-4.15.0-47-generic] (local build)
Copyright (C) 2002-16, Bruce Allen, Christian Franke, www.smartmontools.org

=== START OF INFORMATION SECTION ===
Vendor:               Samsung
Product:              Flash Drive FIT
Revision:             1100
Compliance:           SPC-4
User Capacity:        32,086,425,600 bytes [32.0 GB]
Logical block size:   512 bytes
LU is fully provisioned
scsiModePageOffset: response length too short, resp_len=4 offset=4 bd_len=0
Logical Unit id:      0x00010200000608040x2020030102060804error: SCSI name string
Serial number:        AA00000000000489
Device type:          disk
scsiModePageOffset: response length too short, resp_len=4 offset=4 bd_len=0
Local Time is:        Tue Apr 16 09:47:19 2019 EDT
SMART support is:     Available - device has SMART capability.
SMART support is:     Disabled
Temperature Warning:  Disabled or Not Supported

=== START OF READ SMART DATA SECTION ===
SMART Health Status: OK
Current Drive Temperature:     0 C
Drive Trip Temperature:        0 C

Error Counter logging not supported

scsiModePageOffset: response length too short, resp_len=4 offset=4 bd_len=0
Device does not support Self Test logging

[dhalbert]

By the way, CIRCUITPY does this (which may not be the best):

$ sudo smartctl --all -d scsi /dev/sdc
smartctl 6.6 2016-05-31 r4324 [x86_64-linux-4.15.0-47-generic] (local build)
Copyright (C) 2002-16, Bruce Allen, Christian Franke, www.smartmontools.org

Short INQUIRY response, skip product id
A mandatory SMART command failed: exiting. To continue, add one or more '-T permissive' options.

[dhalbert]

@vitorio Here's a test bootloader that makes PORTALBOOT act more like a regular USB stick. It deliberately has a malformed response to a MODE SENSE query for page 0x1c, which is like nearly all the USB sticks and SD card readers I tried.

Could you try this and see if it works for you even with SMART sensing on?

update-bootloader-pyportal_m4-v3.3.0-adafruit.10-1-g93c961b.uf2.zip

[Ve2mrx]

For Windows users, test with Hard Disk Sentinel. It causes big issues when detecting the USB key emulation.

Telling HDS to ignore USB devices fixed my issues.

Related?

[vitorio]

Hi, @dhalbert, updated with your test bootloader, but under Linux, running skdump on the PORTALBOOT device still locks up the PyPortal and makes the device unable to be mounted, or unable to be read if it's already mounted.

On whatever is peculiar about my Windows 10 installation, the device now shows up under Disk drives in Device Manager (it didn't before), but Windows still won't mount the PORTALBOOT drive.

After reinstalling the SMART driver for OSX, the PORTALBOOT drive does not appear.

[dhalbert]

@vitorio Here's another version to try:
update-bootloader-pyportal_m4-v3.3.0-adafruit.10-dirty.uf2.zip

This times out on skdump, and fails quickly on smartctl. If you could try it with the with the MacOS SMART driver, that would be great. What's the name of the thing you're trying? I now have a Mac I can test this on, so I could try to duplicate your MacOS issue.

@Ve2mrx Is the trial version of Hard Disk Sentinel good enough to provoke this problem? I can try that.

[Ve2mrx]

@dhalbert Yes, but you might have to allow USB scanning in HDS. HDS will attempt to get SMART info if you plug and invoke the bootloader. I use both Metro M0 and the Feather M0 RFM69 with the same results.

IIRC, the computer almost freezes. I'll try to reproduce later today.

Note: The software AnyDesk (a remote control software like TeamViewer) might have an influence, too. At least, it messes with Virtual Box's USB capture.

[Ve2mrx]

@dhalbert I reproduced the issue with HDS 5.40 Pro, HDS freezes until I get out of bootloader mode.

UF2 bootloaders where v2.0.0 for both the Metro M0 and the Feather M0. (v3.3.0-adafruit.10 now tested, same HDS freeze)

[dhalbert]

@Ve2mrx Would you be able to try the new trial version? Here is a Metro M0 Express version of the new trial bootloader I posted above:
update-bootloader-metro_m0-v3.3.0-adafruit.10-dirty.uf2.zip

[Ve2mrx]

Free today: HDS Standard : https://sharewareonsale.com/s/hard-disk-sentinel-standard-sale

[Ve2mrx]

@dhalbert I'll try it probably tomorrow.

[dhalbert]

@vitorio I tried the trial version of DriveDX (v1.8.2) on both High Sierra (2010 MacBook Air) and Mojave 10.14.4 (2018 MacBook). In both cases, the program did not interfere with showing a BOOT drive on a number of versions of the UF2 bootloader, including v1.22 and v3.3.0-adafruit.10. I did a rescan from the DriveDX window after plugging the boards in. They did not show up for SMART diagnosis, but neither were they blocked. Hmm.

[dhalbert]

@Ve2mrx I tried HDS 5.30 and 5.40 with the test bootloader above: it still hangs. I'll need to take a USB trace to see what's going on.

All these tools seem to get drive info and test for SMART capability in different ways. Various drives give bad responses to these requests in different ways: USB sticks fail in a certain way that seems tolerated by the utilities. I did something else that makes skdump and smartctl not get stuck, but that didn't help with HDS.

[Ve2mrx]

@dhalbert At this point, it might be useful to ping the HDS Author to this thread. In my memory, he's pretty responsive.

[vitorio]

@dhalbert tried your updated 10-dirty firmware.

Sorry for being unclear. The test with skdump isn't just if it times out or not. It's, does it time out, and then can you subsequently still mount the drive (or subsequently read from the drive if it was previously mounted). With this firmware, I still cannot, e.g.:

$ sudo mount /dev/sdd p
$ ls p
CURRENT.UF2  INDEX.HTM  INFO_UF2.TXT
$ sudo skdump /dev/sdd
Device: sat12:/dev/sdd
Type: 12 Byte SCSI ATA SAT Passthru
Size: 7 MiB
Awake: Operation not supported
ATA SMART not supported.
$ md5sum p/INFO_UF2.TXT 
(no response until I unplug and replug the device)

I can do this from the CIRCUITPY drive.

On my Mac, I don't get the PORTALBOOT drive still. If you installed DriveDx, you also have to install the third-party USB driver to get it to query for SMART on external disks. It should prompt you for it within the app once you plug in an external USB disk. If it doesn't, it's also available on their site here: https://binaryfruit.com/drivedx/usb-drive-support

Just FYI, there's also another fork of the same driver available here, although it's not the one I'm using: https://github.com/RJVB/OS-X-SAT-SMART-Driver

[dhalbert]

@vitorio I was able to read from the drive after skdump ran, but I was using it slightly differently. I'll take your word for it. I'm trying to make it act the same as CIRCUITPY for SMART checks. CIRCUITPY actually has its own issues: it returns a prematurely short response to a query, and that seems to cause skdump, or the driver it's using, to fail earlier and not hang up the drive. In any case, I appreciate all the testing.