[USB] - CrystalDiskMark allows setting APM/AAM and Passmark DiskCheckup allows DST, but your software does not

[LtqxWYEG]

output of openSeaChest_PassthroughTest

Performing Pass-through test.
If at any point during the test, a crash, a hang, or the device
seems to stop responding to any normal request, save all previously
reported hacks, stop the tool, reset the device, then restart
the test, skipping to another part of the test to avoid the same issue.
All discovered hacks will be necessary in order to fully communicate
with the end target device to the highest capabilities of the adapter or
bridge performing the translations.

This device is already in the database with known pass-through hacks.
Use the --forceRetest option to force a retest of pass-through hacks already known.

PS C:\Users\###\openSeaChest-v25.05-win-x64> ./openSeaChest_PassthroughTest -d PD3 --runPTTest --forceRetest
==========================================================================================
 openSeaChest_PassthroughTest - openSeaChest drive utilities - NVMe Enabled
 Copyright (c) 2014-2025 Seagate Technology LLC and/or its Affiliates, All Rights Reserved
 openSeaChest_PassthroughTest Version: 1.5.0 X86_64
 Build Date: May 30 2025
 Today: 20250620T061852 User: admin
==========================================================================================

\\.\PhysicalDrive3 -  -  -  - SCSI
Performing Pass-through test.
If at any point during the test, a crash, a hang, or the device
seems to stop responding to any normal request, save all previously
reported hacks, stop the tool, reset the device, then restart
the test, skipping to another part of the test to avoid the same issue.
All discovered hacks will be necessary in order to fully communicate
with the end target device to the highest capabilities of the adapter or
bridge performing the translations.

Checking standard SCSI inquiry data, VPD pages, and some mode pages
to understand device capabilities. Only commands specified in translator
specifications will be tested.

====================
Reading Inquiry Data
====================
                Peripheral Device Type: Direct Access Block Device (SBC)
                SCSI Version: SCSI 2 (1993) - (2h)
WARNING: Response data format is set to 1!
         This means that all product identification is in a vendor specific
         format and cannot be parsed correctly!
         This is only expected for OLD SCSI devices. Nothing else should
         report in this format. Raw output is provided which may be usable
         if needed for better legacy device support.
HACK FOUND: PRESCSI2

        0  1  2  3  4  5  6  7  8  9  A  B  C  D  E  F
  0x00 00 00 02 01 1F 00 00 00 57 44 43 20 57 44 31 30   ........WDC WD10
  0x10 4A 50 56 58 2D 32 32 4A 43 33 54 30 20 20 20 20   JPVX-22JC3T0
  0x20 00 00 00                                          ...


=========================
Checking VPD page support
=========================
WARNING: Device did not report supported VPD pages.
         VPD pages communicate other device capabilities
         and limits which are useful to the host.
Will dummy up support to see if any pages are supported that are useful.
        Found page 80h
Unit Serial Number VPD Page
        Found page 83h
Device Identification VPD Page
        Found page 86h
Extended Inquiry Data VPD Page
        Found page B0h
Block Limits VPD Page
        Found page B1h
Block Device Characteristics VPD Page
HACK FOUND: NVPD

========================================
Getting Read Capacity data. 10 & 16 byte
========================================
        Read Capacity 10 data:
                MaxLBA: 1953525167
                Block Size : 512
WARNING: Failed read capacity 16. This should only happen on old legacy SPC & earlier devices.
         All new devices SHOULD support this command to report PI type (if any) and logical
         to physical block relationships so that read/write can be properly aligned for the device.
         this command also reports if logical block provisioning management is enabled and whether
         or not zeros are reported when reading an unmapped LBA.

========================================
Checking SCSI Read/Write Command Support
========================================
HACK FOUND: RW10
NOTE: Skipping testing for zero length transfers. This test should be done for highest compatibility testing!

==========================
Checking Mode Page Support
==========================
Read Write Error Recovery Mode Page
        Automatic Write Reallocation: Disabled
        Automatic Read Reallocation: Disabled
        Recovery Time Limit: 0
Caching Mode Page
        Write Cache: Disabled

==========================
Testing for SCSI Log Pages
==========================
NOTE: Skipping SCSI Log test since device reported invalid operation code.
HACK FOUND: NLP

===========================
Testing Other SCSI Commands
===========================
ERROR: Report LUNS failed. This is a critical command!
WARNING: Security protocol in failed. Access to device security subsystems may be inaccessible or limited!
WARNING: Reporting supported operation codes failed! This command does not appear to be known by the device.
HACK FOUND: NRSUPOP
Testing SCSI default self-test.
WARNING: Default self-test is not available.

==============================================
Testing Error Handling Of Unsupported Commands
==============================================
Average response time from 3 commands: 447933 nanoseconds
Testing complete.
        Total Commands Tried: 12
        Average return time from bad commands: 5969600 nanoseconds
        Command time ratio (bad compared to good): 13.33
HACK FOUND: TURF13

==================================
Testing SCSI Maximum Transfer Size
==================================
NOTE: This is currently limited to 4096 sectors for now
SCSI Max Transfer Size: 65536B


==================
Final Test Results
==================
SEND THIS INFO BELOW TO seaboard@seagate.com:
Adapter Information:
        Information Type: USB
        Vendor ID: 152Dh
        Product ID: 2339h
        Revision: 0100h
        Device information could not be detected by this tool since it was reported in a legacy
        vendor specific format from old SCSI or CCS (pre-SCSI2) standards. Detecting this must
        be done manually by specifying specific offsets at this time for optimal support.
        Please include the full output from the tool when sending to seaboard@seagate.com
        Command Processing (bad relative to good): 13.33
        SCSI Max Transfer Size: 65536

Hacks For This Device:
                TURF:13
        SCSI Hacks: PRESCSI2, RW10, NVPD, NLP, NRSUPOP, MXFER:65536
        ATA Hacks:  SAT, A1, CHKND, NDMA,
Recommendations For Device Makers:
1       Test this device with this tool in multiple OS's. Linux and Windows testing should be done to find highest compatibility.
2       Improve error handling for unknown commands. This device takes longer
            and longer to respond with each unknown command.
3       Rerun this test to test for commands that are known to hang some devices to ensure
        all hacks are known for this device to perform properly...if the firmware can be
        fixed to prevent these hangs, that is the best solution!

Desktop (please complete the following information):

• OS: Windows 10 22H2
• Version: v25.05-win-x64

Hint: All openSeaChest tools support the --version option which can report this for you.

Additional context
Tools like CrystalDiskMark allows setting APM/AAM and Passmark DiskCheckup allows DST with this external USB enclosure.

I get the error: \\.\PhysicalDrive3 - SPZX-21Z10T0 - - - SCSI Setting APM Level is not supported on this device.

That's not a critical issue, but I'm wondering why this is. You even have extra hacks and it still doesn't work?

EDIT: Oh, those hacks are not for the USB-"anything", right? But for some SCSI device on my mainboard??
I would love to make me a batch that uses your tools for extra nice work-flow flow, so that I don't need those tools anymore. They alway slow down to nothing when detecting HDDs. A minute sometimes. Or maybe, since that's also the case with Disk Management MMC, it's an issue with Windows disk/volume service? *ramble

• Unrelated question: Anyway, I was hoping I could fix my Seagate drive which is detected as 1.8TB but has 4TB actually. Does not long-format with HDD Low Level Format Tool 4.50. This HDDLLF Tool does always detect/say the HDDs have 512Byte sectors; Even with a HGST HDD that clearly states Advanced Format on it's label. (Which is 4KB/sector, right?) Is this OK or do I have to use a different LLF tool or maybe make extra sure it's NTFS formatted with 4KB and aligned? Sorry :D

Thanks! :)

[vonericsen]

Hi @LtqxWYEG,

Thanks for uploading these results.
The hacks are to work around problems with different USB devices. We have them specific for a variety of different issues.
It may be working around passing through ATA commands or the way the USB adapter handles certain SCSI commands.

That's not a critical issue, but I'm wondering why this is. You even have extra hacks and it still doesn't work?

Let's start by going through this first.

This chip we have hacks for based on a version we tested internally that had SAT ATA passthrough command support, but this version you have does not appear to have that support.
Before the SAT standard, every vendor did their own unique translation and passthrough support and it is possible this has a legacy JMicron support that crystal disk info supports, but we do not right now.

The test you ran gives a lot of info about what the device does so I can understand what is supports or does not support and that can help me understand what the error is.

\\.\PhysicalDrive3 - SPZX-21Z10T0 - - - SCSI Setting APM Level is not supported on this device <- this error tells me that our software detected the drive as a SCSI device so no passthrough was found that could tell it that this is actually an ATA device which supports APM.

I have run into a few other JMicron adapters similar to this that report identical Vendor ID, Product ID, and Revision ID, but one supported SAT and one did not....that is likely what is happening here as well. All the hacks we have so far are based on what we've been able to test or had someone submit. This tells me that there are different firmwares, but no way to identify them that I have found so far.

smartctl also has jmicron's legacy passthrough supported so that may work for you, but I do not recall the exact options you will need to run it.

Oh, those hacks are not for the USB-"anything", right? But for some SCSI device on my mainboard??
I would love to make me a batch that uses your tools for extra nice work-flow flow, so that I don't need those tools anymore. They alway slow down to nothing when detecting HDDs. A minute sometimes. Or maybe, since that's also the case with Disk Management MMC, it's an issue with Windows disk/volume service?

Most of it is specific to USB due to the way they can stop responding when issued commands they do not like. Some have a watchdog timer and reboot themselves, but I have run into a lot that just stop responding until you unplug it and plug it back in. These hacks help us not trigger those issues and get as much support as we can into our tools for the adapter.

Additionally the hacks help change the way in which the ATA passthrough commands are built so that they are correctly interpretted by the USB adapter's firmware. The standard has a few different ways to handle things and we have found some devices implement one or the other, some support both. Some only properly handle commands when submitted with certain options set. Sometimes they respond with an error when not setup the way the adapter likes, or they fail to return the raw drive response so we have to try alternative methods to get it. These hacks get setup automatically to remove retries and make things "just work" for the user as best we can. They cannot resolve every issue, so the goal is generally to get as many things working as possible.

We have ways to create similar hacks for working around other adapters like SAS HBAs and AHCI cards or drivers but generally don't need to implement them the same as they don't have the same level of issue and we can do a retry instead as necessary.
I also have code that detects certain known adapters automatically off of other info to work around issues we've run into.... it's far from perfect as we always run into something new causing a problem, but it helps keep everything functioning as best we can make it given the issues we find.

Unrelated question: Anyway, I was hoping I could fix my Seagate drive which is detected as 1.8TB but has 4TB actually. Does not long-format with HDD Low Level Format Tool 4.50. This HDDLLF Tool does always detect/say the HDDs have 512Byte sectors; Even with a HGST HDD that clearly states Advanced Format on it's label. (Which is 4KB/sector, right?) Is this OK or do I have to use a different LLF tool or maybe make extra sure it's NTFS formatted with 4KB and aligned? Sorry :D

If this drive is 4TB but showing as 1.8TB with this adapter, that is likely because the adapter does not translate the capacity correctly. This is not uncommon on older USB adapters. I have run into numerous ones, even with SAT, that have some random capacity limit in them.

For example, I had an older model Thermaltake black-x USB2.0/eSATA adapter. It worked great for years, but I remember putting in a 10TB drive and the capacity shows up as some random value well below 10TB....something in the adapter firmware does not get translated for the full 10TB. This device does support pass-through though, so in passthrough mode commands, I can access the full 10TB.

Now here is where the issue is, the OS does not ever issue these passthrough commands. It only talks to the USB adapter with the SCSI command set and lets it translate them to the appropriate SATA commands.
If you used a different USB adapter, it could work fine and show the full capacity without an issue, or it might have its own separate issues.

Advanced Format on it's label. (Which is 4KB/sector, right?)

This simply means that the physical sector size inside the drive is 4KB. The drive can present a logical 512B sector which is often referred to as 512e (emulated). This is the most common configuration for any drive and is fully backwards compatible with older hardware at this sector size. The downside to 512e is that if the writes are not aligned, it may encounter a read-modify-write penalty. Unless you are running Windows XP or really ancient Linux, that is not really an issue anymore as newer OS's can detect this emulation and align the writes to disk to remove the performance loss.
Having both logical and physical sectors set to 4K is typically referred to as 4KN (native), but whether you can convert the drive depends on a lot of other factors. The newer standards allow a manufacturer to implement commands to switch between 512e and 4KN modes, but older products generally do not support this unless the vendor provided some tool to do it themselves. Seagate drives can only be converted when they support the new standardized method (commonly called fast format). openSeaChest_Format has the option --setSectorSize which runs this method if the drive supports it, but it requires passthrough to get to the raw drive, not the USB emulated drive the OS sees.

Let me know if you have any questions. I also have this Wiki page here that may help as well: Format, Fast-format, and Sector Sizes

[LtqxWYEG]

Hey, thank you very much for your extensive reply! Really, highly appreciated. :)

Do you think CrystalDiskInfo - which doesn't seem very professional to me judging by the amount of anime girls in it - has any hacks for different USB devices? Why does it work? It's just weird to me. (And the title is wrong, it's not the *Mark program.)
Do you need anything more from me in order to improve USB compatibility or is this just not a pressing issue? It's fine. It's a very old enclosure anyway. (Just the only one detecting broken drives)

I tested it with a different adapter; this one is just a SATA data and power plug stuck to a USB cable, and it does work with your software. However it has the issue that it does seem to have more problems detecting HDDs correctly if they are in some way currently ... weird. I mean, I got about 15 HDDs that were not readable/detectable in order to try to "repair" and keep if they work again. All of them were not detected and a big 3.5" HDD didn't even start spinning. (Probably because there's just no 12V rail available, though. So no issues with 5V power).
With the (externally powered) very old adapter I could detect almost all of them, and got three back to perfect working order. Not even any SMART issues with them. (One has actually reduced it's defective sector count by hundreds after a LLF. Is that normal?)
Now that they are working again, have proper filesystems, they are detectable with the newer USB-to-SATA cable adapter.

Why are the totally fine now? Maybe they were in a weird firmware mode. I've read online that some drives can get stuck somehow, in some mode. I have no idea why thay weren't readable/writable before I messed with them. It's not like manufacturer let me see any error logs. You guys's HDDs at least have open UART consoles, sometimes. I love that.

I'll get much more drives in the future so I hoped to improve my workflow/create one/stop being an idiot/learn/etc..

Anyway the USB-to-SATA cable adapter did work:

\\.\PhysicalDrive3 -  - 0000000000011 - 1214 - ATA
Successfully set APM Level!

Here's more info of the USB-to-SATA cable adapter, for seemingly no reason:
(Interestingly, it's also detected as SCSI)

\\.\PhysicalDrive3 -  -  -  - SCSI
Performing Pass-through test.
If at any point during the test, a crash, a hang, or the device
seems to stop responding to any normal request, save all previously
reported hacks, stop the tool, reset the device, then restart
the test, skipping to another part of the test to avoid the same issue.
All discovered hacks will be necessary in order to fully communicate
with the end target device to the highest capabilities of the adapter or
bridge performing the translations.

Checking standard SCSI inquiry data, VPD pages, and some mode pages
to understand device capabilities. Only commands specified in translator
specifications will be tested.

====================
Reading Inquiry Data
====================
                Peripheral Device Type: Direct Access Block Device (SBC)
                SCSI Version: SPC4 (2015) - (6h)
Got Vendor ID as SABRENT
WARNING: Product ID contains non-ASCII or non-Printable Characters!
WARNING: Product ID contains non-ASCII or non-Printable Characters!
WARNING: Product ID contains non-ASCII or non-Printable Characters!
WARNING: Product ID contains non-ASCII or non-Printable Characters!
WARNING: Product ID contains non-ASCII or non-Printable Characters!
WARNING: Product ID contains non-ASCII or non-Printable Characters!
WARNING: Product ID contains non-ASCII or non-Printable Characters!
WARNING: Product ID contains non-ASCII or non-Printable Characters!
WARNING: Product ID contains non-ASCII or non-Printable Characters!
WARNING: Product ID contains non-ASCII or non-Printable Characters!
WARNING: Product ID contains non-ASCII or non-Printable Characters!
WARNING: Product ID contains non-ASCII or non-Printable Characters!
WARNING: Product ID contains non-ASCII or non-Printable Characters!
WARNING: Product ID contains non-ASCII or non-Printable Characters!
WARNING: Product ID contains non-ASCII or non-Printable Characters!
WARNING: Product ID contains non-ASCII or non-Printable Characters!
Got Product ID as
Got Product Revision as 1214
Checking Version Descriptors:
        1747 - UAS T10/2095-D revision 04
        0460 - SPC-4 (no version claimed)
        04C0 - SBC-3 (no version claimed)
        5341 - ----
        4252 - ----
        454E - ----
        5400 - ----

=========================
Checking VPD page support
=========================
        Found page 0h
Supported VPD Pages
        Found page 80h
Unit Serial Number VPD Page
WARNING: Unit Serial Number contains non-ASCII or non-Printable Characters!
WARNING: Unit Serial Number contains non-ASCII or non-Printable Characters!
WARNING: Unit Serial Number contains non-ASCII or non-Printable Characters!
        Got Unit Serial Number as 0000000000011
        Found page 83h
Device Identification VPD Page
        Reported Designators:
                Designator 0
                        Associated with the addressed logical unit
                        Network Address Authority Designator:
                            NAA Type 3 - Locally Assigned
                                Locally Administered Value: 0000000
                Designator 1
                        Associated with the addressed logical unit
                        T10 Vendor ID Based Designator:
                            T10 Vendor ID: SABRENT
                            Vendor Specific ID:
        Found page B0h
Block Limits VPD Page
        Optimal Transfer Length Granularity: 8 Logical Blocks
        Maximum Transfer Length: 65535 Logical Blocks
        Optimal Transfer Length: 65535 Logical Blocks
        Maximum Prefetch Length: 65535 Logical Blocks
        Maximum Unmap LBA Count: Not Reported
        Maximum Unmap Block Descriptor Count: Not Reported
        Optimal Unmap Granularity: Not Reported
        Maximum Write Same Length: Not Reported or write same not supported
        Maximum Atomic Transfer Length: Not Reported or write atomic not supported
        Atomic Alignment: Not Reported or write atomic not supported
        Atomic Transfer Length Granularity: Not Reported or write atomic not supported
        Maximum Atomic Transfer Length With Atomic Boundary: Not Reported or write atomic not supported
        Maximum Atomic Boundary Size: Not Reported or write atomic not supported
        Found page B2h
Logical Block Provisioning VPD Page
        Unmap Command: Not Supported
        Unmap Support in Write Same 16: Not Supported
        Unmap Support in Write Same 10: Not Supported
        Unmapped LBA Data: Vendor Specific
        Anchor Support: Not Supported
        Provisioning Type: Not reported or fully provisioned
        Found page DEh
Vendor Specific VPD Page DEh
        Found page DFh
Vendor Specific VPD Page DFh

========================================
Getting Read Capacity data. 10 & 16 byte
========================================
        Read Capacity 10 data:
                MaxLBA: 1953525167
                Block Size : 512
        Read Capacity 16 data:
                MaxLBA: 1953525167
                Logical Block Size: 512
                Physical Block Size: 4096

========================================
Checking SCSI Read/Write Command Support
========================================
HACK FOUND: RW6
HACK FOUND: RW10
HACK FOUND: RW12
HACK FOUND: RW16
NOTE: Skipping testing for zero length transfers. This test should be done for highest compatibility testing!

==========================
Checking Mode Page Support
==========================
Control Mode Page
        D_Sense = 0
        Ext DST Completion Time (Seconds): 0
Caching Mode Page
        Write Cache: Enabled
Power Condition Control Mode Page
        StandbyZ Timer: 6000
Vendor Specific Mode Page 0

==========================
Testing for SCSI Log Pages
==========================
HACK FOUND: NLPS
This device does NOT report log page subpages properly! Do not attempt to read ANY subpages as it only checks the page code!
        Found page 00h
Supported Log Pages
        Found page 10h
Self-Test Results

===========================
Testing Other SCSI Commands
===========================
WARNING: Security protocol in failed. Access to device security subsystems may be inaccessible or limited!
WARNING: Reporting supported operation codes failed! This command does not appear to be known by the device.
HACK FOUND: NRSUPOP
Testing SCSI default self-test.
Device is capable of performing default self-test

==============================================
Testing Error Handling Of Unsupported Commands
==============================================
Average response time from 3 commands: 275133 nanoseconds
Testing complete.
        Total Commands Tried: 12
        Average return time from bad commands: 2989400 nanoseconds
        Command time ratio (bad compared to good): 10.87
HACK FOUND: TURF11

==================================
Testing SCSI Maximum Transfer Size
==================================
NOTE: This is currently limited to 4096 sectors for now
SCSI Max Transfer Size: 524288B
SCSI reported max size: 33553920B
SCSI reported optimal size: 33553920B


==================
Final Test Results
==================
SEND THIS INFO BELOW TO seaboard@seagate.com:
Adapter Information:
        Information Type: USB
        Vendor ID: 152Dh
        Product ID: 0576h
        Revision: 1214h
        Vendor ID: SABRENT
        Product ID:
        Product Rev: 1214
        Unit Serial Number: 0000000000011
        Device IDs:
                3000000000000150
                53414252454E54200000000000000000
        Command Processing (bad relative to good): 10.87
        SCSI Max Transfer Size: 524288

Hacks For This Device:
                TURF:11
        SCSI Hacks: RW6, RW10, RW12, RW16, NLPS, NRSUPOP, MXFER:524288
        ATA Hacks:  SAT, A1, CHKND, NDMA,
Recommendations For Device Makers:
1       Test this device with this tool in multiple OS's. Linux and Windows testing should be done to find highest compatibility.
2       Improve error handling for unknown commands. This device takes longer
            and longer to respond with each unknown command.
3       Rerun this test to test for commands that are known to hang some devices to ensure
        all hacks are known for this device to perform properly...if the firmware can be
        fixed to prevent these hangs, that is the best solution!
4       The maximum transfer length is less than was reported by the block limits VPD page!
        This page should report the maximum transfer length supported by the SCSI device or SCSI translator
        This should be a true maximum. If this seems low, retest on another OS to ensure it is not a
        limitation on a specific OS. For example, it is fairly common to be limited to 64k in Windows.

Sorry, I seem to use this Issue almost as if I'm in a forum. xD
Thanks for your help. REALLY appreciate it. :)

[vonericsen]

Do you think CrystalDiskInfo - which doesn't seem very professional to me judging by the amount of anime girls in it - has any hacks for different USB devices? Why does it work? It's just weird to me. (And the title is wrong, it's not the *Mark program.)
Do you need anything more from me in order to improve USB compatibility or is this just not a pressing issue? It's fine. It's a very old enclosure anyway. (Just the only one detecting broken drives)

Crystal disk info has been around for quite a while. They have source code for many of the older adapters that used proprietary pass-through functions as well as newer ones. There is some overlap between openSeaChest and Crystal disk info in supported passthrough modes and some differences.

In your case they have support for the older vendor unique JMicron passthrough that openSeaChest is missing.
I've been looking into what I can do to add support for a while, but have held off until I got an issue reported 😉
I don't need anything else from you on this right now, but if I think of anything, I'll reply to this with a request for more info.

If I recall correctly, between smartmontools and openSeaChest, there are 4 vendor unique passthroughs missing in openSeaChest. With crystal disk info, they have a few more that are not present in smartmontools either which tells me those ones are even more rare to encounter. I don't know how that developer has gotten the info to implement those, but they seem to have a way to get some of that pretty early as I've seen smartmontools get requests to implement support from there before too.

With the (externally powered) very old adapter I could detect almost all of them, and got three back to perfect working order. Not even any SMART issues with them. (One has actually reduced it's defective sector count by hundreds after a LLF. Is that normal?)
Now that they are working again, have proper filesystems, they are detectable with the newer USB-to-SATA cable adapter.

For the low-level format reducing defective sectors, if it's the "Pending Defects" that is normal. If it's the "Grown defects" then I'm not so sure.
The difference is a "Pending defect" is one the drive detected as bad during a read so it's still "accessible" with a read as it hasn't had anything else done to it since that last read. It will continue reporting an uncorrectable data error when you try to read it in this state.
When a write is issued to a pending defect, the drive firmware will try to rewrite it with the new data. If it successfully writes to that sector with the new data, then it has corrected it and will continue using it. If it was not able to write to it, then it will reallocate it to a new location on the disk that was reserved for this purpose. Once a reallocation happens, it logs it to the "Grown Defects" list and increments that counter. From that point on, the old location is no longer accessible, and all reads will go to the alternate location it reallocated to.

Hopefully that makes sense, but let me know if you have other questions. The TLDR: this seems pretty normal overall.

If you get excessive reallocations (like 100's) then that starts becoming abnormal as there may be a bigger issue going on inside the drive. If it's excessive enough, SMART will report a trip due to too many reallocations in too short of a time period.

Why are the totally fine now? Maybe they were in a weird firmware mode. I've read online that some drives can get stuck somehow, in some mode. I have no idea why thay weren't readable/writable before I messed with them. It's not like manufacturer let me see any error logs. You guys's HDDs at least have open UART consoles, sometimes. I love that.

This may depend on different factors. I would have to know more about the original condition otherwise it's a lot of guesses.
The external power is necessary for most 3.5" drives unless you can enable a very low current spinup (we have an option in openSeaChest for this on Seagate drives, but you need them to spin up first, and the reduction may still not be enough in some cases).

When you say they weren't working before the low level format, do you mean connected to Windows/Linux they wouldn't show up or something else?

Here's more info of the USB-to-SATA cable adapter, for seemingly no reason:
(Interestingly, it's also detected as SCSI)

In the openSeaChest_Passthrough test everything shows up as SCSI first unless it's natively connected to an ATA or NVMe bus.
USB adapters are always SCSI because that is the command set between the host computer and the adapter in all modes (UAS and BOT), then the adapter translates to SATA/NVMe commands as necessary.
When the passthrough test runs, it is disabling a lot of the built-in lowlevel tests to rerun them manually in this tool instead that way it has more control over what it finds and tests since it may need to skip some of our built-in retries elsewhere in the code to check things for itself to report at the end. This is meant to allow this tool to test each path manually and collect enough information about the drive so we can put in some known workarounds and save time versus relying on the retries in the low-level code. It can also set up other info about which commands are likely to pass or fail and give us some other potential workarounds to other issues. For example, I recently had a report of an HBA not wanting to allow a firmware update. I asked that user to add --forceSCSI to force the SCSI command set to the HBA and that worked. So this test also tries to identify where we can rely on SCSI translations and where we need an ATA passthrough command to do what we need.

[LtqxWYEG]

Hi, thanks again for the great reply. :)

When you say they weren't working before the low level format, do you mean connected to Windows/Linux they wouldn't show up or something else?

If I remember correctly, they weren't detectable at all with the USB-to-SATA cable, were detected with the older USB enclosure, and I couldn't copy files on them, until I LLF'ed one of them. Two did just start working, I think. Very weird. Sorry, I have no real information there. They work now, with great SMART values. So I'm happy I got three working...
Others that I couldn't get to work are just accumulating "Grown defects" and/or are impossible to format in any way. Like they give up after one minute, beep with one their motors - arm, I think - and try again -> but it's all very slow. A couple are being LLF'ed with a speed of about 300 sectors per second (or about 0.1MB/s) or much less. If I restart the LLF, it seems the previously-worked-on-area is OK again and will be sped over with 40MB/s until more broken area is reached. That's very weird and much too slow for me to just let them run for days. (Given they also beep every one or two minutes, it's also highly annoying) bla bla

Couldn't you ask them for they hacks? I don't think sharing that is such a huge deal. Nobody is making money off of it after all. Maybe they will give you their stuff. :)

[vonericsen]

Hi, thanks again for the great reply. :)

No problem! I would rather take the time to help someone else learn something 😄

Others that I couldn't get to work are just accumulating "Grown defects" and/or are impossible to format in any way. Like they give up after one minute, beep with one their motors - arm, I think - and try again -> but it's all very slow. A couple are being LLF'ed with a speed of about 300 sectors per second (or about 0.1MB/s) or much less. If I restart the LLF, it seems the previously-worked-on-area is OK again and will be sped over with 40MB/s until more broken area is reached. That's very weird and much too slow for me to just let them run for days. (Given they also beep every one or two minutes, it's also highly annoying) bla bla

These drives may not recover...or if they do they may remain slow due to so many reallocations.
It's hard to say until they finish one or more passes. From this description it definitely does not sound like a healthy drive.

Couldn't you ask them for they hacks? I don't think sharing that is such a huge deal. Nobody is making money off of it after all. Maybe they will give you their stuff. :)

Yes. I also consulted with Seagate's legal department to figure out what I can and cannot do with the differences between our MPL 2.0 license and Crystal Disk Info's MIT license and smartmontool's GPL license.

At this point I just need to start on the work around all the other things I have going on as well (we have a lot of internal issues on an internal issue tracker) so I balance between openSeaChest and SeaChest a lot.... often times I do find that they end up having overlap which does make it easy when that happens 😄

I'll review how much work this will be to add since I had a nearly identical request show up in the Toolbin project recently. It was Seagate/ToolBin#38
That was a different manufacturer for the adapter, but overall similar issue of a legacy passthrough protocol.

[LtqxWYEG]

Well, at one point you'll have universal USB compatibility and are done. xD

I hope you have fun doing your work! Good luck!

I'll close this now :)
Thank you very much

[vonericsen]

Well, at one point you'll have universal USB compatibility and are done. xD

I remember thinking that IDK how many years ago....and yet it still isn't universal. haha

No problem on helping, but I am going to leave this open as I did get a start on this code while waiting for something else to get reviewed. That way anyone else with a similar USB adapter knows it's at least started.

[vonericsen]

@LtqxWYEG,

I am adding a couple other legacy USB adapters in while working on this that I know about, but once I get those completed I will share a build you can test to see if it works for you or not.

I don't have a device with this JMicron passthrough available to test at the moment or at least I cannot find the one I did have, but I'll try to test it myself first.
Regardless, any feedback you can provide will be very helpful getting this supported.