Groups > alt.os.linux > #81253 > unrolled thread

Hard disk error (Error probing device: Error sending ATA command IDENTIFY DEVICE)

Started by	"Carlos E.R." <robin_listas@es.invalid>
First post	2025-04-03 22:01 +0200
Last post	2025-04-05 22:03 +0200
Articles	20 on this page of 46 — 7 participants

Back to article view | Back to alt.os.linux

  Hard disk error (Error probing device: Error sending ATA command IDENTIFY DEVICE) "Carlos E.R." <robin_listas@es.invalid> - 2025-04-03 22:01 +0200
    Re: Hard disk error (Error probing device: Error sending ATA command IDENTIFY DEVICE) Paul <nospam@needed.invalid> - 2025-04-03 17:47 -0400
      Re: Hard disk error (Error probing device: Error sending ATA command IDENTIFY DEVICE) "Carlos E.R." <robin_listas@es.invalid> - 2025-04-04 02:39 +0200
        Re: Hard disk error (Error probing device: Error sending ATA command IDENTIFY DEVICE) Paul <nospam@needed.invalid> - 2025-04-03 23:33 -0400
          Re: Hard disk error (Error probing device: Error sending ATA command IDENTIFY DEVICE) "Carlos E.R." <robin_listas@es.invalid> - 2025-04-04 11:36 +0200
            Re: Hard disk error (Error probing device: Error sending ATA command IDENTIFY DEVICE) "Carlos E.R." <robin_listas@es.invalid> - 2025-04-04 12:16 +0200
              Re: Hard disk error (Error probing device: Error sending ATA command IDENTIFY DEVICE) Paul <nospam@needed.invalid> - 2025-04-04 14:51 -0400
                Re: Hard disk error (Error probing device: Error sending ATA command IDENTIFY DEVICE) "Carlos E.R." <robin_listas@es.invalid> - 2025-04-04 21:52 +0200
            Re: Hard disk error (Error probing device: Error sending ATA command IDENTIFY DEVICE) Java Jive <java@evij.com.invalid> - 2025-04-04 11:28 +0100
              Re: Hard disk error (Error probing device: Error sending ATA command IDENTIFY DEVICE) "Carlos E.R." <robin_listas@es.invalid> - 2025-04-04 12:47 +0200
                Re: Hard disk error (Error probing device: Error sending ATA command IDENTIFY DEVICE) Java Jive <java@evij.com.invalid> - 2025-04-04 17:06 +0100
                  Re: Hard disk error (Error probing device: Error sending ATA command IDENTIFY DEVICE) "Carlos E.R." <robin_listas@es.invalid> - 2025-04-04 19:09 +0200
                    Re: Amazon (Was: Hard disk error (Error probing device: Error sending ATA command IDENTIFY DEVICE) "J.O. Aho" <user@example.net> - 2025-04-04 21:26 +0200
                      Re: Amazon (Was: Hard disk error (Error probing device: Error sending ATA command IDENTIFY DEVICE) Mark Lloyd <not.email@all.invalid> - 2025-04-05 16:22 +0000
                        Re: Amazon (Was: Hard disk error (Error probing device: Error sending ATA command IDENTIFY DEVICE) "Carlos E.R." <robin_listas@es.invalid> - 2025-04-05 21:01 +0200
      Re: Hard disk error (Error probing device: Error sending ATA command IDENTIFY DEVICE) "Carlos E.R." <robin_listas@es.invalid> - 2025-04-06 14:44 +0200
    Re: Hard disk error (Error probing device: Error sending ATA command IDENTIFY DEVICE) vallor <vallor@cultnix.org> - 2025-04-04 06:30 +0000
      Re: Hard disk error (Error probing device: Error sending ATA command IDENTIFY DEVICE) Paul <nospam@needed.invalid> - 2025-04-04 03:53 -0400
        Re: Hard disk error (Error probing device: Error sending ATA command IDENTIFY DEVICE) "Carlos E.R." <robin_listas@es.invalid> - 2025-04-04 12:53 +0200
          Re: Hard disk error (Error probing device: Error sending ATA command IDENTIFY DEVICE) "Carlos E.R." <robin_listas@es.invalid> - 2025-04-04 13:44 +0200
          Re: Hard disk error (Error probing device: Error sending ATA command IDENTIFY DEVICE) "Carlos E.R." <robin_listas@es.invalid> - 2025-04-04 23:40 +0200
            Re: Hard disk error (Error probing device: Error sending ATA command IDENTIFY DEVICE) "Carlos E.R." <robin_listas@es.invalid> - 2025-04-05 13:33 +0200
              Re: Hard disk error (Error probing device: Error sending ATA command IDENTIFY DEVICE) "Carlos E.R." <robin_listas@es.invalid> - 2025-04-05 18:23 +0200
                Re: Hard disk error (Error probing device: Error sending ATA command IDENTIFY DEVICE) "Carlos E.R." <robin_listas@es.invalid> - 2025-04-05 21:04 +0200
      Re: Hard disk error (Error probing device: Error sending ATA command IDENTIFY DEVICE) "Carlos E.R." <robin_listas@es.invalid> - 2025-04-04 12:15 +0200
        Re: Hard disk error (Error probing device: Error sending ATA command IDENTIFY DEVICE) Paul <nospam@needed.invalid> - 2025-04-04 16:30 -0400
          Re: Hard disk error (Error probing device: Error sending ATA command IDENTIFY DEVICE) "Carlos E.R." <robin_listas@es.invalid> - 2025-04-04 22:52 +0200
            Re: Hard disk error (Error probing device: Error sending ATA command IDENTIFY DEVICE) Paul <nospam@needed.invalid> - 2025-04-04 18:46 -0400
            Re: Hard disk error (Error probing device: Error sending ATA command IDENTIFY DEVICE) Java Jive <java@evij.com.invalid> - 2025-04-05 00:20 +0100
              Re: Hard disk error (Error probing device: Error sending ATA command IDENTIFY DEVICE) Paul <nospam@needed.invalid> - 2025-04-04 23:05 -0400
              Re: Hard disk error (Error probing device: Error sending ATA command IDENTIFY DEVICE) "Carlos E.R." <robin_listas@es.invalid> - 2025-04-05 12:47 +0200
                Re: Hard disk error (Error probing device: Error sending ATA command IDENTIFY DEVICE) Java Jive <java@evij.com.invalid> - 2025-04-05 14:14 +0100
                  Re: Hard disk error (Error probing device: Error sending ATA command IDENTIFY DEVICE) "Carlos E.R." <robin_listas@es.invalid> - 2025-04-05 18:23 +0200
                    Re: Hard disk error (Error probing device: Error sending ATA command IDENTIFY DEVICE) Paul <nospam@needed.invalid> - 2025-04-06 00:13 -0400
                  Re: Hard disk error (Error probing device: Error sending ATA command IDENTIFY DEVICE) Simon <SimonJ@eu.invalid> - 2025-04-07 09:42 +0000
                    Re: Hard disk error (Error probing device: Error sending ATA command IDENTIFY DEVICE) "Carlos E.R." <robin_listas@es.invalid> - 2025-04-07 14:07 +0200
                      Re: Hard disk error (Error probing device: Error sending ATA command IDENTIFY DEVICE) "J.O. Aho" <user@example.net> - 2025-04-07 16:37 +0200
                        Re: Hard disk error (Error probing device: Error sending ATA command IDENTIFY DEVICE) Paul <nospam@needed.invalid> - 2025-04-07 15:00 -0400
                          Re: Hard disk error (Error probing device: Error sending ATA command IDENTIFY DEVICE) "Carlos E.R." <robin_listas@es.invalid> - 2025-04-08 02:34 +0200
                            Re: Hard disk error (Error probing device: Error sending ATA command IDENTIFY DEVICE) Paul <nospam@needed.invalid> - 2025-04-08 00:05 -0400
                            Re: Hard disk error (Error probing device: Error sending ATA command IDENTIFY DEVICE) "J.O. Aho" <user@example.net> - 2025-04-08 08:09 +0200
                              Re: Hard disk error (Error probing device: Error sending ATA command IDENTIFY DEVICE) Java Jive <java@evij.com.invalid> - 2025-04-08 11:16 +0100
                                Re: Hard disk error (Error probing device: Error sending ATA command IDENTIFY DEVICE) Paul <nospam@needed.invalid> - 2025-04-08 09:39 -0400
                              Re: Hard disk error (testing usb-storage instead of UAS) "Carlos E.R." <robin_listas@es.invalid> - 2025-04-08 20:49 +0200
                                Re: Hard disk error (testing usb-storage instead of UAS) Paul <nospam@needed.invalid> - 2025-04-08 18:38 -0400
    Re: Hard disk error (Error probing device: Error sending ATA command IDENTIFY DEVICE) "Carlos E.R." <robin_listas@es.invalid> - 2025-04-05 22:03 +0200

Page 2 of 3 — ← Prev page 1 [2] 3 Next page →

#81274

From	"Carlos E.R." <robin_listas@es.invalid>
Date	2025-04-04 23:40 +0200
Message-ID	<i606clxumo.ln2@Telcontar.valinor>
In reply to	#81265

On 2025-04-04 12:53, Carlos E.R. wrote:
> On 2025-04-04 09:53, Paul wrote:

>>     https://ralimtek.com/posts/2021/jms578/
>>
>> The claim there, is the ROM inside the device has a boot loader,
>> so erasing the flash cannot brick it. You can keep trying to flash it.
> 
> «Additionally, you may have run into the stupid way these units power 
> down the drives after 10 minutes of inactivity forcefully. Completely 
> ignoring OS or HDD settings. This is infuriating if you want the drives 
> to do what you tell them.»
> 
> Argh. So I need a cronjob every five minutes? Or do they restart 
> automatically?
> 
> [...]
> 
> Seems to not be happening. I listed files in the terminal more than 10 
> minutes later, and it responded instantly.

Yes, it is happening.

Maybe having a terminal open at the mount point avoided the power off to happen.

I hibernated the machine, later woke it up, and access to the files was fast. But now I launched a smartctl long test, and it aborted (doesn't say the percent):

Telcontar:~ # smartctl -l selftest /dev/sde
smartctl 7.4 2023-08-01 r5530 [x86_64-linux-6.4.0-150600.23.42-default] (SUSE RPM)
Copyright (C) 2002-23, Bruce Allen, Christian Franke, www.smartmontools.org

=== START OF READ SMART DATA SECTION ===
SMART Self-test log structure revision number 1
Num  Test_Description    Status                  Remaining  LifeTime(hours)  LBA_of_first_error
# 1  Extended offline    Interrupted (host reset)      00%       614         -
# 2  Short offline       Completed without error       00%       613         -
# 3  Short offline       Completed without error       00%       606         -

So I'm trying again leaving a terminal open at the mount point. If that fails, I need a while loop to do some activity periodically while running the smart test.

I don't know how sensitive is software raid to the disk dying on it.

[...]

Well, no, leaving the terminal open is not enough, the long test is aborted. Brilliant firmware, that. I'll have to create a script with the test and a loop.

Initial script:

+++···················
#!/bin/bash

THEDISK=/dev/sde

function busyloop()
{
    while true  ; do
         DATE=`date --rfc-3339=s`
         echo -en "$DATE \t"
         smartctl -l selftest $THEDISK | grep "# 1"
         sleep 1m
    done
}

echo smartctl --test=long $THEDISK
echo
busyloop
···················++-

It has survived for 15 minutes so far. I will let the script run, and change the loop to 5 minutes.

Mmm, dunno how to stop automatically the script... Of course, the text will say so, then ctrl-C. Maybe... knowing how long it should run, kill the script with a timer. Better parse the text somehow.

2025-04-04 23:35:18+02:00 	# 1  Extended offline    Completed without error       00%       618         -
^C
Telcontar:~/tmp/disk1 #

Ok, the procedure works. Now logging off, because I have a bug that crashes the machine a bit after midnight.
Improving the script has to wait.

-- 
Cheers, Carlos.

[toc] | [prev] | [next] | [standalone]

#81282

From	"Carlos E.R." <robin_listas@es.invalid>
Date	2025-04-05 13:33 +0200
Message-ID	<i1h7clxu39.ln2@Telcontar.valinor>
In reply to	#81274

On 2025-04-04 23:40, Carlos E.R. wrote:
> On 2025-04-04 12:53, Carlos E.R. wrote:
>> On 2025-04-04 09:53, Paul wrote:


> Well, no, leaving the terminal open is not enough, the long test is 
> aborted. Brilliant firmware, that. I'll have to create a script with the 
> test and a loop.
> 
> Initial script:
> 
> +++···················
> #!/bin/bash
> 
> THEDISK=/dev/sde
> 
> function busyloop()
> {
>     while true  ; do
>          DATE=`date --rfc-3339=s`
>          echo -en "$DATE \t"
>          smartctl -l selftest $THEDISK | grep "# 1"
>          sleep 1m
>     done
> }
> 
> echo smartctl --test=long $THEDISK
> echo
> busyloop
> ···················++-

...

> Ok, the procedure works. Now logging off, because I have a bug that 
> crashes the machine a bit after midnight.
> Improving the script has to wait.

Improved script:

+++···················
#!/bin/bash


function busyloop()
{
    while true  ; do
         DATE=`date --rfc-3339=s`
         TEXT=`smartctl -l selftest $THEDISK | grep "# 1"`
         echo -en "$DATE \t $TEXT\r"
         
         TEXT2=`echo "$TEXT" | grep "Self-test routine in progress"`
         if [ -n "$TEXT2" ]; then
             sleep 1m
         fi

         TEXT2=`echo "$TEXT" | grep "Interrupted"`
         if [ -n "$TEXT2" ]; then
             echo -e "\nTest Aborted."
             break
         fi

         TEXT2=`echo "$TEXT" | grep "Completed"`
         if [ -n "$TEXT2" ]; then
             echo -e "\nTest ended."
             break
             #echo -en "\r"
         fi

    done
}

if [ $# -eq 0 ]; then
     echo "runs SMART long test on the given device, and waits it out, verbosely"
     exit
fi
THEDISK=$1


smartctl --test=long $THEDISK
echo
busyloop

#parse output.

# 2025-04-04 23:35:18+02:00     # 1  Extended offline    Completed without error       00%       618         -
# 1  Extended offline    Self-test routine in progress 10%       618         -
# 2  Extended offline    Interrupted (host reset)      00%       614         -
···················++-

It runs like this:


Telcontar:~/tmp/disk2 # YottamasterLongtest /dev/sdf
smartctl 7.4 2023-08-01 r5530 [x86_64-linux-6.4.0-150600.23.42-default] (SUSE RPM)
Copyright (C) 2002-23, Bruce Allen, Christian Franke, www.smartmontools.org

=== START OF OFFLINE IMMEDIATE AND SELF-TEST SECTION ===
Sending command: "Execute SMART Extended self-test routine immediately in off-line mode".
Drive command "Execute SMART Extended self-test routine immediately in off-line mode" successful.
Testing has begun.
Please wait 108 minutes for test to complete.
Test will complete after Sat Apr  5 15:15:23 2025 CEST
Use smartctl -X to abort test.

2025-04-05 13:30:24+02:00 	 # 1  Extended offline    Self-test routine in progress 90%      3989         -



The last line is overwritten every minute. Or could be every 5 minutes, but I'm testing. The terminal has to be kept open.


-- 
Cheers, Carlos.

[toc] | [prev] | [next] | [standalone]

#81285

From	"Carlos E.R." <robin_listas@es.invalid>
Date	2025-04-05 18:23 +0200
Message-ID	<3128clxb1o.ln2@Telcontar.valinor>
In reply to	#81282

On 2025-04-05 13:33, Carlos E.R. wrote:
> On 2025-04-04 23:40, Carlos E.R. wrote:
>> On 2025-04-04 12:53, Carlos E.R. wrote:
>>> On 2025-04-04 09:53, Paul wrote:
> 
> 
>> Well, no, leaving the terminal open is not enough, the long test is 
>> aborted. Brilliant firmware, that. I'll have to create a script with 
>> the test and a loop.
>>
>> Initial script:
...
> 
>> Ok, the procedure works. Now logging off, because I have a bug that 
>> crashes the machine a bit after midnight.
>> Improving the script has to wait.
> 
> Improved script:

...

> The last line is overwritten every minute. Or could be every 5 minutes, 
> but I'm testing. The terminal has to be kept open.

There is an impact of the script, that queries the status of the smart test; look at the output:

Telcontar:~/tmp/disk2 # YottamasterLongtest /dev/sdf
smartctl 7.4 2023-08-01 r5530 [x86_64-linux-6.4.0-150600.23.42-default] (SUSE RPM)
Copyright (C) 2002-23, Bruce Allen, Christian Franke, www.smartmontools.org

=== START OF OFFLINE IMMEDIATE AND SELF-TEST SECTION ===
Sending command: "Execute SMART Extended self-test routine immediately in off-line mode".
Drive command "Execute SMART Extended self-test routine immediately in off-line mode" successful.
Testing has begun.
Please wait 108 minutes for test to complete.
Test will complete after Sat Apr  5 15:15:23 2025 CEST
Use smartctl -X to abort test.

2025-04-05 16:49:57+02:00 	 # 1  Extended offline    Completed without error       00%      3992         -
Test ended.
Telcontar:~/tmp/disk2 #

Instead of finishing at 15:15:23. it did at 16:49:57. It took more than one hour longer. So I'll change the delay to 8 minutes.

-- 
Cheers, Carlos.

[toc] | [prev] | [next] | [standalone]

#81288

From	"Carlos E.R." <robin_listas@es.invalid>
Date	2025-04-05 21:04 +0200
Message-ID	<3fb8clxkbr.ln2@Telcontar.valinor>
In reply to	#81285

On 2025-04-05 18:23, Carlos E.R. wrote:
> On 2025-04-05 13:33, Carlos E.R. wrote:
>> On 2025-04-04 23:40, Carlos E.R. wrote:
>>> On 2025-04-04 12:53, Carlos E.R. wrote:
>>>> On 2025-04-04 09:53, Paul wrote:

One more find: when I hibernate the computer, the leds on the box switch 
off, so I assume it powers down the disks. However, the fan keeps 
running. The fan is very silent, I have to put my ear very close to the 
box to distinguish it.

This is possibly not important for my use case, but it is a data point.

-- 
Cheers, Carlos.

[toc] | [prev] | [next] | [standalone]

#81262

From	"Carlos E.R." <robin_listas@es.invalid>
Date	2025-04-04 12:15 +0200
Message-ID	<v3o4clxl55.ln2@Telcontar.valinor>
In reply to	#81258

On 2025-04-04 08:30, vallor wrote:
> On Thu, 3 Apr 2025 22:01:43 +0200, "Carlos E.R." <robin_listas@es.invalid>
> wrote in <7263clxr47.ln2@Telcontar.valinor>:

...

>> What do you think about the error?
>>
>> <1.4> 2025-04-03T20:16:01.859892+02:00 Telcontar udisksd 2769 - -  Error
>> probing device: Error sending ATA command IDENTIFY DEVICE to '/dev/sde':
>> Unexpected sense data returned:#0120000: 00 00 00 00  00 00 00 00  00 00
>> 00 00  00 00 00 00    ................#0120010: 00 00 00 00  00 00 00 00
>>   00 00 00 00  00 00 00 00    ................#012 (g-io-error-quark, 0)
>>
>>
>> Bug report?
>>
>> (openSUSE Leap 15.6)
> 
> Well, Linux seems to see the partitions...
> 
> Maybe the drives will work anyway?  Have you tested them?

I don't have yet the blank hard disks to construct the software raid I 
intended, I expect them early next week.

I have two disks with data that I connected. I launched a file copy from 
both disks simultaneously (a /usr directory) and they are running at 
speeds of 4.5M/S. No errors on log.

I can try big file write, simultaneously, with dd.

Telcontar:~/tmp/disk1 # dd if=/dev/zero of=test bs=5M count=1000 
status=progress oflag=direct
5117050880 bytes (5.1 GB, 4.8 GiB) copied, 29 s, 176 MB/s
1000+0 records in
1000+0 records out
5242880000 bytes (5.2 GB, 4.9 GiB) copied, 29.5996 s, 177 MB/s
Telcontar:~/tmp/disk1 #

Telcontar:~/tmp/disk2 # dd if=/dev/zero of=test bs=5M count=1000 
status=progress oflag=direct
5153751040 bytes (5.2 GB, 4.8 GiB) copied, 30 s, 172 MB/s
1000+0 records in
1000+0 records out
5242880000 bytes (5.2 GB, 4.9 GiB) copied, 30.4898 s, 172 MB/s
Telcontar:~/tmp/disk2 #


So at least plain normal usage works.



-- 
Cheers, Carlos.

[toc] | [prev] | [next] | [standalone]

#81272

From	Paul <nospam@needed.invalid>
Date	2025-04-04 16:30 -0400
Message-ID	<vspfi8$ctlr$1@dont-email.me>
In reply to	#81262

On Fri, 4/4/2025 6:15 AM, Carlos E.R. wrote:
> On 2025-04-04 08:30, vallor wrote:
>> On Thu, 3 Apr 2025 22:01:43 +0200, "Carlos E.R." <robin_listas@es.invalid>
>> wrote in <7263clxr47.ln2@Telcontar.valinor>:
> 
> ...
> 
>>> What do you think about the error?
>>>
>>> <1.4> 2025-04-03T20:16:01.859892+02:00 Telcontar udisksd 2769 - -  Error
>>> probing device: Error sending ATA command IDENTIFY DEVICE to '/dev/sde':
>>> Unexpected sense data returned:#0120000: 00 00 00 00  00 00 00 00  00 00
>>> 00 00  00 00 00 00    ................#0120010: 00 00 00 00  00 00 00 00
>>>   00 00 00 00  00 00 00 00    ................#012 (g-io-error-quark, 0)
>>>
>>>
>>> Bug report?
>>>
>>> (openSUSE Leap 15.6)
>>
>> Well, Linux seems to see the partitions...
>>
>> Maybe the drives will work anyway?  Have you tested them?
> 
> I don't have yet the blank hard disks to construct the software raid I intended, I expect them early next week.
> 
> I have two disks with data that I connected. I launched a file copy from both disks simultaneously (a /usr directory) and they are running at speeds of 4.5M/S. No errors on log.
> 
> I can try big file write, simultaneously, with dd.
> 
> Telcontar:~/tmp/disk1 # dd if=/dev/zero of=test bs=5M count=1000 status=progress oflag=direct
> 5117050880 bytes (5.1 GB, 4.8 GiB) copied, 29 s, 176 MB/s
> 1000+0 records in
> 1000+0 records out
> 5242880000 bytes (5.2 GB, 4.9 GiB) copied, 29.5996 s, 177 MB/s
> Telcontar:~/tmp/disk1 #
> 
> Telcontar:~/tmp/disk2 # dd if=/dev/zero of=test bs=5M count=1000 status=progress oflag=direct
> 5153751040 bytes (5.2 GB, 4.8 GiB) copied, 30 s, 172 MB/s
> 1000+0 records in
> 1000+0 records out
> 5242880000 bytes (5.2 GB, 4.9 GiB) copied, 30.4898 s, 172 MB/s
> Telcontar:~/tmp/disk2 #
> 
> 
> So at least plain normal usage works.

When you get your practice disks *do a capacity test*.

1) Create the array.
2) Fill the array with 1GB test files until it is full.
3) Did the array corrupt at 2.2TB worth of files ?

I could find evidence that the thing was using 28-bit LBA
instead of 48-bit LBA. I don't think the SATA specs even allow
that. All of SATA, should be in 48-bit addressing mode.

You should be *very suspicious* about this product,
and use test procedures appropriate for "mystery meat".

   Paul

[toc] | [prev] | [next] | [standalone]

#81273

From	"Carlos E.R." <robin_listas@es.invalid>
Date	2025-04-04 22:52 +0200
Message-ID	<sdt5clxhsh.ln2@Telcontar.valinor>
In reply to	#81272

On 2025-04-04 22:30, Paul wrote:
> On Fri, 4/4/2025 6:15 AM, Carlos E.R. wrote:
>> On 2025-04-04 08:30, vallor wrote:
>>> On Thu, 3 Apr 2025 22:01:43 +0200, "Carlos E.R." <robin_listas@es.invalid>
>>> wrote in <7263clxr47.ln2@Telcontar.valinor>:

...

>> So at least plain normal usage works.
> 
> When you get your practice disks *do a capacity test*.
> 
> 1) Create the array.
> 2) Fill the array with 1GB test files until it is full.
> 3) Did the array corrupt at 2.2TB worth of files ?
> 
> I could find evidence that the thing was using 28-bit LBA
> instead of 48-bit LBA. I don't think the SATA specs even allow
> that. All of SATA, should be in 48-bit addressing mode.
> 
> You should be *very suspicious* about this product,
> and use test procedures appropriate for "mystery meat".

My routine includes filling the disks to capacity with pseudo random data. I wrote some code that does this at maximum speed ;-)

Oh, this is because I intend to encrypt the disks. I suppose I should encrypt the resulting raid device, say /dev/md0, then mount /dev/dm-0.

Another hurdle, is I need to read the FARM data, because there are fake new Seagate hard disks running around⁽¹⁾. I tested this:

+++··················
Telcontar:~ # smartctl -l farm /dev/sdf
smartctl 7.4 2023-08-01 r5530 [x86_64-linux-6.4.0-150600.23.42-default] (SUSE RPM)
Copyright (C) 2002-23, Bruce Allen, Christian Franke, www.smartmontools.org

FARM log (GP Log 0xa6) not supported

Telcontar:~ #
··················++-

I have to find out if this because the disks I am using are old and do not have the FARM log yet, or the box firmware doesn't allow reading it. This is not crucial if I can read it somewhere else.

Huh, I have an idea. If this box in the end is not valid, I could rip it out and insert usb2sata connectors on the back of each disk. Use only the power supply and the iron. It would be ugly and impose a delay on my project, and waste of money, but would work.

(1) <https://www.tomshardware.com/pc-components/hdds/seagate-hard-drive-controversy-persists-as-scammers-discover-methods-to-alter-reliability-metrics>

-- 
Cheers, Carlos.

[toc] | [prev] | [next] | [standalone]

#81277

From	Paul <nospam@needed.invalid>
Date	2025-04-04 18:46 -0400
Message-ID	<vspnfl$kge7$2@dont-email.me>
In reply to	#81273

On Fri, 4/4/2025 4:52 PM, Carlos E.R. wrote:

> Huh, I have an idea. If this box in the end is not valid, I could rip it out and insert usb2sata connectors on the back of each disk. Use only the power supply and the iron. It would be ugly and impose a delay on my project, and waste of money, but would work.

Now, you are talking like a real scientist [Like] :-)

   Paul

[toc] | [prev] | [next] | [standalone]

#81278

From	Java Jive <java@evij.com.invalid>
Date	2025-04-05 00:20 +0100
Message-ID	<vsppfn$n253$1@dont-email.me>
In reply to	#81273

On 2025-04-04 21:52, Carlos E.R. wrote:
> 
> Huh, I have an idea. If this box in the end is not valid, I could rip it 
> out and insert usb2sata connectors on the back of each disk. Use only 
> the power supply and the iron. It would be ugly and impose a delay on my 
> project, and waste of money, but would work.

Wouldn't it be easier to try to solve the firmware problem?  If you're 
going to destroy the innards, invalidate the warranty, and so not be 
able to return it anyway, why not try installing a fixed firmware first?

-- 

Fake news kills!

I may be contacted via the contact address given on my website: 
www.macfh.co.uk

[toc] | [prev] | [next] | [standalone]

#81280

From	Paul <nospam@needed.invalid>
Date	2025-04-04 23:05 -0400
Message-ID	<vsq6m0$17cbt$1@dont-email.me>
In reply to	#81278

On Fri, 4/4/2025 7:20 PM, Java Jive wrote:
> On 2025-04-04 21:52, Carlos E.R. wrote:
>>
>> Huh, I have an idea. If this box in the end is not valid, I could rip it out and insert usb2sata connectors on the back of each disk. Use only the power supply and the iron. It would be ugly and impose a delay on my project, and waste of money, but would work.
> 
> Wouldn't it be easier to try to solve the firmware problem?  If you're going to destroy the innards, invalidate the warranty, and so not be able to return it anyway, why not try installing a fixed firmware first?
> 

You can't really destroy it (apparently), as the ROM
inside the 578 is not volatile, and it allows attempts
to reflash the external SPI flash chip, as you wish.

Keep a backup copy of the existing SPI image (using the flasher
tool) and then that can be put back later if desired.

I get the impression that executing the "erase flash",
followed by a "power cycle" for the 578, puts it in
"ready-to-flash" mode.

   Paul

[toc] | [prev] | [next] | [standalone]

#81281

From	"Carlos E.R." <robin_listas@es.invalid>
Date	2025-04-05 12:47 +0200
Message-ID	<ebe7clx3p.ln2@Telcontar.valinor>
In reply to	#81278

On 2025-04-05 01:20, Java Jive wrote:
> On 2025-04-04 21:52, Carlos E.R. wrote:
>>
>> Huh, I have an idea. If this box in the end is not valid, I could rip 
>> it out and insert usb2sata connectors on the back of each disk. Use 
>> only the power supply and the iron. It would be ugly and impose a 
>> delay on my project, and waste of money, but would work.
> 
> Wouldn't it be easier to try to solve the firmware problem?  If you're 
> going to destroy the innards, invalidate the warranty, and so not be 
> able to return it anyway, why not try installing a fixed firmware first?

But someone has to provide the fixed software file.

-- 
Cheers, Carlos.

[toc] | [prev] | [next] | [standalone]

#81283

From	Java Jive <java@evij.com.invalid>
Date	2025-04-05 14:14 +0100
Message-ID	<vsrac2$2b6bi$1@dont-email.me>
In reply to	#81281

On 2025-04-05 11:47, Carlos E.R. wrote:
>
> On 2025-04-05 01:20, Java Jive wrote:
>>
>> On 2025-04-04 21:52, Carlos E.R. wrote:
>>>
>>> Huh, I have an idea. If this box in the end is not valid, I could rip 
>>> it out and insert usb2sata connectors on the back of each disk. Use 
>>> only the power supply and the iron. It would be ugly and impose a 
>>> delay on my project, and waste of money, but would work.
>>
>> Wouldn't it be easier to try to solve the firmware problem?  If you're 
>> going to destroy the innards, invalidate the warranty, and so not be 
>> able to return it anyway, why not try installing a fixed firmware first?
> 
> But someone has to provide the fixed software file.

Paul gave you a big clue in his post of 2025-04-04, 04:33.  He didn't 
want to give actual links because he couldn't verify their sources, but 
you can search on the file names he gave, for example:

https://duckduckgo.com/?q=jms578fwupdater.tgz

-- 

Fake news kills!

I may be contacted via the contact address given on my website: 
www.macfh.co.uk

[toc] | [prev] | [next] | [standalone]

#81286

From	"Carlos E.R." <robin_listas@es.invalid>
Date	2025-04-05 18:23 +0200
Message-ID	<l028clxb1o.ln2@Telcontar.valinor>
In reply to	#81283

On 2025-04-05 15:14, Java Jive wrote:
> On 2025-04-05 11:47, Carlos E.R. wrote:
>>
>> On 2025-04-05 01:20, Java Jive wrote:
>>>
>>> On 2025-04-04 21:52, Carlos E.R. wrote:
>>>>
>>>> Huh, I have an idea. If this box in the end is not valid, I could 
>>>> rip it out and insert usb2sata connectors on the back of each disk. 
>>>> Use only the power supply and the iron. It would be ugly and impose 
>>>> a delay on my project, and waste of money, but would work.
>>>
>>> Wouldn't it be easier to try to solve the firmware problem?  If 
>>> you're going to destroy the innards, invalidate the warranty, and so 
>>> not be able to return it anyway, why not try installing a fixed 
>>> firmware first?
>>
>> But someone has to provide the fixed software file.
> 
> Paul gave you a big clue in his post of 2025-04-04, 04:33.  He didn't 
> want to give actual links because he couldn't verify their sources, but 
> you can search on the file names he gave, for example:
> 
> https://duckduckgo.com/?q=jms578fwupdater.tgz
> 

It has to be an update of the Yottamaster model F55 specifically, and I 
didn't see any.

-- 
Cheers, Carlos.

[toc] | [prev] | [next] | [standalone]

#81291

From	Paul <nospam@needed.invalid>
Date	2025-04-06 00:13 -0400
Message-ID	<vssv1e$3d34$1@dont-email.me>
In reply to	#81286

On Sat, 4/5/2025 12:23 PM, Carlos E.R. wrote:
> On 2025-04-05 15:14, Java Jive wrote:
>> On 2025-04-05 11:47, Carlos E.R. wrote:
>>>
>>> On 2025-04-05 01:20, Java Jive wrote:
>>>>
>>>> On 2025-04-04 21:52, Carlos E.R. wrote:
>>>>>
>>>>> Huh, I have an idea. If this box in the end is not valid, I could rip it out and insert usb2sata connectors on the back of each disk. Use only the power supply and the iron. It would be ugly and impose a delay on my project, and waste of money, but would work.
>>>>
>>>> Wouldn't it be easier to try to solve the firmware problem?  If you're going to destroy the innards, invalidate the warranty, and so not be able to return it anyway, why not try installing a fixed firmware first?
>>>
>>> But someone has to provide the fixed software file.
>>
>> Paul gave you a big clue in his post of 2025-04-04, 04:33.  He didn't want to give actual links because he couldn't verify their sources, but you can search on the file names he gave, for example:
>>
>> https://duckduckgo.com/?q=jms578fwupdater.tgz
>>
> 
> It has to be an update of the Yottamaster model F55 specifically, and I didn't see any.
> 

I don't think there are that many firmwares out there.

The "NVRAM" whether emulated or not, there are bytes
in there that control the controller operating mode,
and the NVRAM is not protected by a checksum.

  https://helmet.kafuka.org/bboard/thread.php?id=259

And some of these discussion threads, seem to indicate
the firmware size is a lot smaller than the flasher flash file
size. the uncompressed firmware might be 4MB, but if you
do a backup of an existing firmware, it's on the order of 50668 bytes.
Which is a more reasonable or believable value. When you get your
flasher package, you may want to pop the "firmware file" into
a hex editor, and see if large portions of it are zero. The SPI
chip inside your box, may not be a matching 4MB, but could be
a lot smaller, like maybe 128KB (to hold a 50668 byte file).

When we did two controllers (having entirely different functions),
the firmware for those fit in 3KB of code. That's why I had trouble
believing a firmware needed 3MB to work. And the 50668 bytes or whatever,
is still large, but isn't too much of a multiplier over 3KB.

   Paul

[toc] | [prev] | [next] | [standalone]

#81295

From	Simon <SimonJ@eu.invalid>
Date	2025-04-07 09:42 +0000
Message-ID	<slrnvv77fp.3fm5h.SimonJ@silex.localdomain>
In reply to	#81283

On 2025-04-05, Java Jive wrote:
> On 2025-04-05 11:47, Carlos E.R. wrote:
>>
>> On 2025-04-05 01:20, Java Jive wrote:
>>>
>>> On 2025-04-04 21:52, Carlos E.R. wrote:
>>>>
>>>> Huh, I have an idea. If this box in the end is not valid, I could rip 
>>>> it out and insert usb2sata connectors on the back of each disk. Use 
>>>> only the power supply and the iron. It would be ugly and impose a 
>>>> delay on my project, and waste of money, but would work.
>>>
>>> Wouldn't it be easier to try to solve the firmware problem?  If you're 
>>> going to destroy the innards, invalidate the warranty, and so not be 
>>> able to return it anyway, why not try installing a fixed firmware first?
>> 
>> But someone has to provide the fixed software file.
>
> Paul gave you a big clue in his post of 2025-04-04, 04:33.  He didn't 
> want to give actual links because he couldn't verify their sources, but 
> you can search on the file names he gave, for example:
>
> https://duckduckgo.com/?q=jms578fwupdater.tgz
>

I found a fix to this some time ago, maybe it will help still now? https://blog.simonj.eu/blog/jms578-based-adaptor-on-linux
-- 
Simon

RLU: 222126

[toc] | [prev] | [next] | [standalone]

#81296

From	"Carlos E.R." <robin_listas@es.invalid>
Date	2025-04-07 14:07 +0200
Message-ID	<6orcclxu42.ln2@Telcontar.valinor>
In reply to	#81295

On 2025-04-07 11:42, Simon wrote:
> On 2025-04-05, Java Jive wrote:
>> On 2025-04-05 11:47, Carlos E.R. wrote:
>>>
>>> On 2025-04-05 01:20, Java Jive wrote:
>>>>
>>>> On 2025-04-04 21:52, Carlos E.R. wrote:
>>>>>
>>>>> Huh, I have an idea. If this box in the end is not valid, I could rip
>>>>> it out and insert usb2sata connectors on the back of each disk. Use
>>>>> only the power supply and the iron. It would be ugly and impose a
>>>>> delay on my project, and waste of money, but would work.
>>>>
>>>> Wouldn't it be easier to try to solve the firmware problem?  If you're
>>>> going to destroy the innards, invalidate the warranty, and so not be
>>>> able to return it anyway, why not try installing a fixed firmware first?
>>>
>>> But someone has to provide the fixed software file.
>>
>> Paul gave you a big clue in his post of 2025-04-04, 04:33.  He didn't
>> want to give actual links because he couldn't verify their sources, but
>> you can search on the file names he gave, for example:
>>
>> https://duckduckgo.com/?q=jms578fwupdater.tgz
>>
> 
> I found a fix to this some time ago, maybe it will help still now? https://blog.simonj.eu/blog/jms578-based-adaptor-on-linux

What does this do? The link doesn't explain.

Google says that this changes usb-disk driver "UAS" to "usb-storage". 
Why would I need that, what is the advantage?

-- 
Cheers, Carlos.

[toc] | [prev] | [next] | [standalone]

#81297

From	"J.O. Aho" <user@example.net>
Date	2025-04-07 16:37 +0200
Message-ID	<m5i68nF22mbU1@mid.individual.net>
In reply to	#81296

On 07/04/2025 14.07, Carlos E.R. wrote:
> On 2025-04-07 11:42, Simon wrote:

>> I found a fix to this some time ago, maybe it will help still now? 
>> https://blog.simonj.eu/blog/jms578-based-adaptor-on-linux
> 
> What does this do? The link doesn't explain.
> 
> Google says that this changes usb-disk driver "UAS" to "usb-storage". 
> Why would I need that, what is the advantage?

The UAS is a newer implementation for mass storage devices, this uses a 
SCSI based protocol instead of the Bulk-Only Transport of the USB. Main 
benefit with UAS is higher transfer speeds from/to usb connected mass 
storage units.

As the device you use seems to have issues with UAS (at least the Linux 
implementation), so the option seems to be to relay on the old USB 
functionality and the benefit for you would be something that works.

The following numbers based on tests on a Banana Pi:
Seq Write: ~10% slower on USB vs UAS
Seq Read: ~14% slower on USB vs UAS

// Aho

[toc] | [prev] | [next] | [standalone]

#81299

From	Paul <nospam@needed.invalid>
Date	2025-04-07 15:00 -0400
Message-ID	<vt17ch$fjv3$1@dont-email.me>
In reply to	#81297

On Mon, 4/7/2025 10:37 AM, J.O. Aho wrote:
> On 07/04/2025 14.07, Carlos E.R. wrote:
>> On 2025-04-07 11:42, Simon wrote:
> 
>>> I found a fix to this some time ago, maybe it will help still now? https://blog.simonj.eu/blog/jms578-based-adaptor-on-linux
>>
>> What does this do? The link doesn't explain.
>>
>> Google says that this changes usb-disk driver "UAS" to "usb-storage". Why would I need that, what is the advantage?
> 
> The UAS is a newer implementation for mass storage devices, this uses a SCSI based protocol instead of the Bulk-Only Transport of the USB. Main benefit with UAS is higher transfer speeds from/to usb connected mass storage units.
> 
> As the device you use seems to have issues with UAS (at least the Linux implementation), so the option seems to be to relay on the old USB functionality and the benefit for you would be something that works.
> 
> The following numbers based on tests on a Banana Pi:
> Seq Write: ~10% slower on USB vs UAS
> Seq Read: ~14% slower on USB vs UAS
> 
> 
> // Aho

For this particular device, the anecdotal evidence is the
regular USB storage seems to work, whereas the UAS implementation
had rough edges. The UAS supports TRIM, which would be a better
fit for SSDs, but I would not put SSDs in that enclosure.
A hard drive may survive any brutal treatment that firmware
hands out. We don't really know what that firmware
does to drives. If a firmware isn't remotely "compliant",
it remains a science experiment.

The next issue, is benching it for performance, and seeing
what kind of write rate it can manage. None of the chit-chat
about it I've seen so far, mentions a bench and whether the
internal processor limits it. It may be examining each ATA
command set command, as it goes by.

   Paul

[toc] | [prev] | [next] | [standalone]

#81304

From	"Carlos E.R." <robin_listas@es.invalid>
Date	2025-04-08 02:34 +0200
Message-ID	<nh7eclxga6.ln2@Telcontar.valinor>
In reply to	#81299

On 2025-04-07 21:00, Paul wrote:
> On Mon, 4/7/2025 10:37 AM, J.O. Aho wrote:
>> On 07/04/2025 14.07, Carlos E.R. wrote:
>>> On 2025-04-07 11:42, Simon wrote:
>>
>>>> I found a fix to this some time ago, maybe it will help still now? https://blog.simonj.eu/blog/jms578-based-adaptor-on-linux
>>>
>>> What does this do? The link doesn't explain.
>>>
>>> Google says that this changes usb-disk driver "UAS" to "usb-storage". Why would I need that, what is the advantage?
>>
>> The UAS is a newer implementation for mass storage devices, this uses a SCSI based protocol instead of the Bulk-Only Transport of the USB. Main benefit with UAS is higher transfer speeds from/to usb connected mass storage units.
>>
>> As the device you use seems to have issues with UAS (at least the Linux implementation), so the option seems to be to relay on the old USB functionality and the benefit for you would be something that works.
>>
>> The following numbers based on tests on a Banana Pi:
>> Seq Write: ~10% slower on USB vs UAS
>> Seq Read: ~14% slower on USB vs UAS
>>
>>
>> // Aho
> 
> For this particular device, the anecdotal evidence is the
> regular USB storage seems to work, whereas the UAS implementation
> had rough edges. The UAS supports TRIM, which would be a better
> fit for SSDs, but I would not put SSDs in that enclosure.
> A hard drive may survive any brutal treatment that firmware
> hands out. We don't really know what that firmware
> does to drives. If a firmware isn't remotely "compliant",
> it remains a science experiment.
> 
> The next issue, is benching it for performance, and seeing
> what kind of write rate it can manage. None of the chit-chat
> about it I've seen so far, mentions a bench and whether the
> internal processor limits it. It may be examining each ATA
> command set command, as it goes by.

All the issues I have with this box appear to be caused by the firmware 
of the box. None seem to be caused on the Linux side of things.

Things like the firmware reporting wrong identification, or powering off 
the disks after 10 minutes, or not handling correctly SMART (ATA) commands.



-- 
Cheers, Carlos.

[toc] | [prev] | [next] | [standalone]

#81305

From	Paul <nospam@needed.invalid>
Date	2025-04-08 00:05 -0400
Message-ID	<vt27a0$1edv3$1@dont-email.me>
In reply to	#81304

On Mon, 4/7/2025 8:34 PM, Carlos E.R. wrote:
> On 2025-04-07 21:00, Paul wrote:
>> On Mon, 4/7/2025 10:37 AM, J.O. Aho wrote:
>>> On 07/04/2025 14.07, Carlos E.R. wrote:
>>>> On 2025-04-07 11:42, Simon wrote:
>>>
>>>>> I found a fix to this some time ago, maybe it will help still now? https://blog.simonj.eu/blog/jms578-based-adaptor-on-linux
>>>>
>>>> What does this do? The link doesn't explain.
>>>>
>>>> Google says that this changes usb-disk driver "UAS" to "usb-storage". Why would I need that, what is the advantage?
>>>
>>> The UAS is a newer implementation for mass storage devices, this uses a SCSI based protocol instead of the Bulk-Only Transport of the USB. Main benefit with UAS is higher transfer speeds from/to usb connected mass storage units.
>>>
>>> As the device you use seems to have issues with UAS (at least the Linux implementation), so the option seems to be to relay on the old USB functionality and the benefit for you would be something that works.
>>>
>>> The following numbers based on tests on a Banana Pi:
>>> Seq Write: ~10% slower on USB vs UAS
>>> Seq Read: ~14% slower on USB vs UAS
>>>
>>>
>>> // Aho
>>
>> For this particular device, the anecdotal evidence is the
>> regular USB storage seems to work, whereas the UAS implementation
>> had rough edges. The UAS supports TRIM, which would be a better
>> fit for SSDs, but I would not put SSDs in that enclosure.
>> A hard drive may survive any brutal treatment that firmware
>> hands out. We don't really know what that firmware
>> does to drives. If a firmware isn't remotely "compliant",
>> it remains a science experiment.
>>
>> The next issue, is benching it for performance, and seeing
>> what kind of write rate it can manage. None of the chit-chat
>> about it I've seen so far, mentions a bench and whether the
>> internal processor limits it. It may be examining each ATA
>> command set command, as it goes by.
> 
> All the issues I have with this box appear to be caused by the firmware of the box. None seem to be caused on the Linux side of things.
> 
> Things like the firmware reporting wrong identification, or powering off the disks after 10 minutes, or not handling correctly SMART (ATA) commands.
> 

It needs a firmware change. Maybe the ODroid "hardkernel"
one would be good enough.

But if the firmware change does not have release notes,
then some amount of test will be required of each
end-user, to try to establish the remaining flaws.

https://www.jmicron.com/About_JMicron

   Our milestone  [WW = World Wide]

   2021   Delivered USB 20Gbps with RAID / Clone bridge controller

   2020   Merger with KaiKuTeK Inc.

   2019 · WW 1st single chip solution to diverse storage media
   2018   Delivered USB-UFS bridge controller
   2017   Delivered WW 1st USB-PCle bridge controller for >1000MB/s DAS application
   2015   Delivered up to 100M pcs of USB 3.1 Gen1 enclosure
          products and also got certified by USB-IF
   2013   Delivered WW 1st USB 3.1 Gen1 dual-bay enclosure single chip controller
   2010   Be selected as one of the outstanding companies in
          Asia by Asian Science Park Association

  Paul

[toc] | [prev] | [next] | [standalone]

Page 2 of 3 — ← Prev page 1 [2] 3 Next page →

csiph-web

Hard disk error (Error probing device: Error sending ATA command IDENTIFY DEVICE)

Contents

#81274

#81282

#81285

#81288

#81262

#81272

#81273

#81277

#81278

#81280

#81281

#81283

#81286

#81291

#81295

#81296

#81297

#81299

#81304

#81305