Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.user > #267130 > unrolled thread

testing new sdm drive

Back to article view | Back to linux.debian.user

Contents

  testing new sdm drive gene heskett <gheskett@shentel.net> - 2024-02-08 08:20 +0100
    Re: testing new sdm drive "Alexander V. Makartsev" <avbetev@gmail.com> - 2024-02-08 13:30 +0100
      Re: testing new sdm drive gene heskett <gheskett@shentel.net> - 2024-02-08 20:30 +0100
        Re: testing new sdm drive "Alexander V. Makartsev" <avbetev@gmail.com> - 2024-02-08 21:20 +0100
          Re: testing new sdm drive <tomas@tuxteam.de> - 2024-02-09 06:50 +0100
            Re: testing new sdm drive Stefan Monnier <monnier@iro.umontreal.ca> - 2024-02-09 14:00 +0100
              Re: testing new sdm drive <tomas@tuxteam.de> - 2024-02-09 14:10 +0100
                Re: testing new sdm drive Dan Ritter <dsr@randomstring.org> - 2024-02-09 14:40 +0100
                  Re: testing new sdm drive tomas@tuxteam.de - 2024-02-09 15:00 +0100
                  Re: testing new sdm drive Max Nikulin <manikulin@gmail.com> - 2024-02-09 16:30 +0100
                Re: testing new sdm drive Stefan Monnier <monnier@iro.umontreal.ca> - 2024-02-09 15:30 +0100
                  Re: testing new sdm drive <tomas@tuxteam.de> - 2024-02-09 17:20 +0100
          Re: testing new sdm drive gene heskett <gheskett@shentel.net> - 2024-02-09 10:10 +0100
        Re: testing new sdm drive David Christensen <dpchrist@holgerdanske.com> - 2024-02-09 08:30 +0100
      Re: testing new sdm drive Linux-Fan <Ma_Sys.ma@web.de> - 2024-02-08 21:40 +0100
        Re: testing new sdm drive David Christensen <dpchrist@holgerdanske.com> - 2024-02-09 08:30 +0100
        Re: testing new sdm drive gene heskett <gheskett@shentel.net> - 2024-02-10 17:10 +0100
        Re: testing new sdm drive continued gene heskett <gheskett@shentel.net> - 2024-02-10 17:30 +0100
          Re: testing new sdm drive continued David Christensen <dpchrist@holgerdanske.com> - 2024-02-11 01:00 +0100
      Re: testing new sdm drive gene heskett <gheskett@shentel.net> - 2024-02-09 23:40 +0100
        Re: testing new sdm drive "Alexander V. Makartsev" <avbetev@gmail.com> - 2024-02-10 02:40 +0100
          Re: testing new sdm drive gene heskett <gheskett@shentel.net> - 2024-02-10 18:30 +0100
          Re: testing new sdm drive gene heskett <gheskett@shentel.net> - 2024-03-26 09:40 +0100
            Re: testing new sdm drive David Wright <deblis@lionunicorn.co.uk> - 2024-03-26 17:00 +0100
    Re: testing new sdm drive David Christensen <dpchrist@holgerdanske.com> - 2024-02-08 19:30 +0100
      Re: testing new sdm drive David Christensen <dpchrist@holgerdanske.com> - 2024-02-08 19:40 +0100
      Re: testing new sdm drive Dan Ritter <dsr@randomstring.org> - 2024-02-08 20:10 +0100
      Re: testing new sdm drive gene heskett <gheskett@shentel.net> - 2024-02-09 10:00 +0100
        Re: testing new sdm drive David Christensen <dpchrist@holgerdanske.com> - 2024-02-10 06:50 +0100
          Re: testing new sdm drive gene heskett <gheskett@shentel.net> - 2024-02-10 18:30 +0100

Page 2 of 2 — ← Prev page 1 [2]

#267209

[Multipart message — attachments visible in raw view] — view raw

On 10.02.2024 03:34, gene heskett wrote:
> On 2/8/24 07:22, Alexander V. Makartsev wrote:
>> This is how I would test it.
>> First create a new GPT partition table and a new 2TB partition:
>>      $ sudo gdisk /dev/sdX check
>>
>> /!\  Make double sure you've selected the right device by using 
>> "lsblk" and "blkid" utilities.  /!\
>> /!\                            It could change from 'sdm' to another 
>> name after reboot.                              /!\
>>
>> At gdisk prompt press "o" to create a new GPT table, next press "n" 
>> to create a new partition, accept default values by pressing "enter".
>> To verify setup press "p", to accept configuration and write it to 
>> device press "w". check
>>
>> Next format partition to ext4 filesystem:
>>      $ sudo mkfs.ext4 -m 0 -e remount-ro /dev/sdX1 check
>>
>> Next mount the filesystem:
>>      $ sudo mkdir /mnt/disktest check
>>      $ sudo mount /dev/sdX1 /mnt/disktest check
>>
>> Next create reference 1GB file filled with dummy data:
>>      $ cd /mnt/disktest check
>>      $ sudo fallocate -l 1G ./reftestfile check
>>      $ sudo badblocks -w -s -t random ./reftestfile check
>>
>> Now we can use script to create 1830 1GB files and check their checksum:
>>      $ for i in $(seq 1830); do sudo dd if="./reftestfile" 
>> of="./testfile${i}" status=none; md5sum -b "./testfile${i}" ;done
>>
>> This procedure will take a very long time to complete. "md5sum" will 
>> output the checksum for each file and they should be equal to 
>> checksum of "reftestfile":
>>      $ md5sum -b ./reftestfile
> Got a problem Alexander:
> I had to put the script someplace else. So I put it in my private 
> /home/gene/bin as disktest.txt with nano. couldn't find it.
> But:
> gene@coyote:/mnt/disktest$ sudo /home/gene/bin/disktest.txt
> sudo: /home/gene/bin/disktest.txt: command not found
If you put that 'for' loop one-liner inside, I think you forgot to make 
"/home/gene/bin/disktest.txt" executable:
     $ chmod +x /home/gene/bin/disktest.txt

> And:
> gene@coyote:/mnt/disktest$ ls /home/gene/bin/disktest.txt
> /home/gene/bin/disktest.txt
> So I think I found the problem with my script, ancient eyeballs can't 
> tell the diff between () and{} so I fixed that but it still won't run 
> or be killed. I don't care how big you've made the t-bird font, by the 
> time you've read 2 more msgs, its back to about 6 point text.  Grrrrrrr.
>
> So I fired up a root session of htop, found about 8 copies of dd 
> showing and started killing them but cannot kill the last 2 in the D 
> state.
>
> And cannot find .disktest.txt running in a root htop and the2 copy's 
> of dd can't be killall'd.
>
It's not possible for me to know what went wrong.
Have you created "reftestfile" inside "/mnt/disktest" directory?
How many "testfile*" files, if any, were created on the filesystem 
mounted at "/mnt/disktest"?
Was there anything relevant in the syslog about "sdm" drive after the test?
If you'd followed my instructions step by step, you'd end up inside 
"/mnt/disktest" directory and for the last step all you had to do is 
copy and paste that one-liner 'for' loop into the command line.
It's a long line and it really meant to be copied and pasted not typed 
by hand, and also to give you the idea of the process, so you could 
adjust it if needed.
I've tested it again on my computer and it worked as expected, 
synchronously created "testfiles" inside current directory and 
calculated their hashes one by one.


-- 
With kindest regards, Alexander.

⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Debian - The universal operating system
⢿⡄⠘⠷⠚⠋⠀ https://www.debian.org
⠈⠳⣄⠀⠀⠀⠀

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

#267238

On 2/9/24 20:37, Alexander V. Makartsev wrote:
> On 10.02.2024 03:34, gene heskett wrote:
>> On 2/8/24 07:22, Alexander V. Makartsev wrote:
>>> This is how I would test it.
>>> First create a new GPT partition table and a new 2TB partition:
>>>      $ sudo gdisk /dev/sdX check
>>>
>>> /!\  Make double sure you've selected the right device by using 
>>> "lsblk" and "blkid" utilities.  /!\
>>> /!\                            It could change from 'sdm' to another 
>>> name after reboot.                              /!\
>>>
>>> At gdisk prompt press "o" to create a new GPT table, next press "n" 
>>> to create a new partition, accept default values by pressing "enter".
>>> To verify setup press "p", to accept configuration and write it to 
>>> device press "w". check
>>>
>>> Next format partition to ext4 filesystem:
>>>      $ sudo mkfs.ext4 -m 0 -e remount-ro /dev/sdX1 check
>>>
>>> Next mount the filesystem:
>>>      $ sudo mkdir /mnt/disktest check
>>>      $ sudo mount /dev/sdX1 /mnt/disktest check
>>>
>>> Next create reference 1GB file filled with dummy data:
>>>      $ cd /mnt/disktest check
>>>      $ sudo fallocate -l 1G ./reftestfile check
>>>      $ sudo badblocks -w -s -t random ./reftestfile check
>>>
>>> Now we can use script to create 1830 1GB files and check their checksum:
>>>      $ for i in $(seq 1830); do sudo dd if="./reftestfile" 
>>> of="./testfile${i}" status=none; md5sum -b "./testfile${i}" ;done
>>>
>>> This procedure will take a very long time to complete. "md5sum" will 
>>> output the checksum for each file and they should be equal to 
>>> checksum of "reftestfile":
>>>      $ md5sum -b ./reftestfile
>> Got a problem Alexander:
>> I had to put the script someplace else. So I put it in my private 
>> /home/gene/bin as disktest.txt with nano. couldn't find it.
>> But:
>> gene@coyote:/mnt/disktest$ sudo /home/gene/bin/disktest.txt
>> sudo: /home/gene/bin/disktest.txt: command not found
> If you put that 'for' loop one-liner inside, I think you forgot to make 
> "/home/gene/bin/disktest.txt" executable:
>      $ chmod +x /home/gene/bin/disktest.txt
> 
>> And:
>> gene@coyote:/mnt/disktest$ ls /home/gene/bin/disktest.txt
>> /home/gene/bin/disktest.txt
>> So I think I found the problem with my script, ancient eyeballs can't 
>> tell the diff between () and{} so I fixed that but it still won't run 
>> or be killed. I don't care how big you've made the t-bird font, by the 
>> time you've read 2 more msgs, its back to about 6 point text.  Grrrrrrr.
>>
>> So I fired up a root session of htop, found about 8 copies of dd 
>> showing and started killing them but cannot kill the last 2 in the D 
>> state.
>>
>> And cannot find .disktest.txt running in a root htop and the2 copy's 
>> of dd can't be killall'd.
>>
> It's not possible for me to know what went wrong.
> Have you created "reftestfile" inside "/mnt/disktest" directory?
> How many "testfile*" files, if any, were created on the filesystem 
> mounted at "/mnt/disktest"?
> Was there anything relevant in the syslog about "sdm" drive after the test?
> If you'd followed my instructions step by step, you'd end up inside 
> "/mnt/disktest" directory and for the last step all you had to do is 
> copy and paste that one-liner 'for' loop into the command line.
> It's a long line and it really meant to be copied and pasted not typed 
> by hand, and also to give you the idea of the process, so you could 
> adjust it if needed.
> I've tested it again on my computer and it worked as expected, 
> synchronously created "testfiles" inside current directory and 
> calculated their hashes one by one.
> 
Someone else advised me of the f3 package, designed to do exactly this, 
disclosed that the first one tested was actually an undersized and slow 
64G drive. Got them packed up and return authorization already for a 
mailing label,  Thank you very much for your assistance Alexander, 
interest much apprecaited.
> 
> -- 
> With kindest regards, Alexander.
> 
> ⢀⣴⠾⠻⢶⣦⠀
> ⣾⠁⢠⠒⠀⣿⡁ Debian - The universal operating system
> ⢿⡄⠘⠷⠚⠋⠀ https://www.debian.org
> ⠈⠳⣄⠀⠀⠀⠀

Cheers, Gene Heskett, CET.
-- 
"There are four boxes to be used in defense of liberty:
  soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author, 1940)
If we desire respect for the law, we must first make the law respectable.
  - Louis D. Brandeis

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

#268531

On 2/9/24 20:36, Alexander V. Makartsev wrote:
> On 10.02.2024 03:34, gene heskett wrote:
>> On 2/8/24 07:22, Alexander V. Makartsev wrote:
>>> This is how I would test it.
>>> First create a new GPT partition table and a new 2TB partition:
>>>      $ sudo gdisk /dev/sdX check
>>>
>>> /!\  Make double sure you've selected the right device by using 
>>> "lsblk" and "blkid" utilities.  /!\
>>> /!\                            It could change from 'sdm' to another 
>>> name after reboot.                              /!\
>>>
>>> At gdisk prompt press "o" to create a new GPT table, next press "n" 
>>> to create a new partition, accept default values by pressing "enter".
>>> To verify setup press "p", to accept configuration and write it to 
>>> device press "w". check
>>>
>>> Next format partition to ext4 filesystem:
>>>      $ sudo mkfs.ext4 -m 0 -e remount-ro /dev/sdX1 check
>>>
>>> Next mount the filesystem:
>>>      $ sudo mkdir /mnt/disktest check
>>>      $ sudo mount /dev/sdX1 /mnt/disktest check
>>>
>>> Next create reference 1GB file filled with dummy data:
>>>      $ cd /mnt/disktest check
>>>      $ sudo fallocate -l 1G ./reftestfile check
>>>      $ sudo badblocks -w -s -t random ./reftestfile check
>>>
>>> Now we can use script to create 1830 1GB files and check their checksum:
>>>      $ for i in $(seq 1830); do sudo dd if="./reftestfile" 
>>> of="./testfile${i}" status=none; md5sum -b "./testfile${i}" ;done
>>>
>>> This procedure will take a very long time to complete. "md5sum" will 
>>> output the checksum for each file and they should be equal to 
>>> checksum of "reftestfile":
>>>      $ md5sum -b ./reftestfile
>> Got a problem Alexander:
>> I had to put the script someplace else. So I put it in my private 
>> /home/gene/bin as disktest.txt with nano. couldn't find it.
>> But:
>> gene@coyote:/mnt/disktest$ sudo /home/gene/bin/disktest.txt
>> sudo: /home/gene/bin/disktest.txt: command not found
> If you put that 'for' loop one-liner inside, I think you forgot to make 
> "/home/gene/bin/disktest.txt" executable:
>      $ chmod +x /home/gene/bin/disktest.txt
> 
>> And:
>> gene@coyote:/mnt/disktest$ ls /home/gene/bin/disktest.txt
>> /home/gene/bin/disktest.txt
>> So I think I found the problem with my script, ancient eyeballs can't 
>> tell the diff between () and{} so I fixed that but it still won't run 
>> or be killed. I don't care how big you've made the t-bird font, by the 
>> time you've read 2 more msgs, its back to about 6 point text.  Grrrrrrr.
>>
>> So I fired up a root session of htop, found about 8 copies of dd 
>> showing and started killing them but cannot kill the last 2 in the D 
>> state.
>>
>> And cannot find .disktest.txt running in a root htop and the2 copy's 
>> of dd can't be killall'd.
>>
> It's not possible for me to know what went wrong.
> Have you created "reftestfile" inside "/mnt/disktest" directory?
> How many "testfile*" files, if any, were created on the filesystem 
> mounted at "/mnt/disktest"?
> Was there anything relevant in the syslog about "sdm" drive after the test?
> If you'd followed my instructions step by step, you'd end up inside 
> "/mnt/disktest" directory and for the last step all you had to do is 
> copy and paste that one-liner 'for' loop into the command line.
> It's a long line and it really meant to be copied and pasted not typed 
> by hand, and also to give you the idea of the process, so you could 
> adjust it if needed.
> I've tested it again on my computer and it worked as expected, 
> synchronously created "testfiles" inside current directory and 
> calculated their hashes one by one.
> 
And by now, I've forgotten what it was that we were trying to 
accomplish.  One of the hazards of my next b-day being the 90'th.
Sorry. Or t-bird is messing  with my mind by reserectiing older messages.
> 
> -- 
> With kindest regards, Alexander.
> 
> ⢀⣴⠾⠻⢶⣦⠀
> ⣾⠁⢠⠒⠀⣿⡁ Debian - The universal operating system
> ⢿⡄⠘⠷⠚⠋⠀ https://www.debian.org
> ⠈⠳⣄⠀⠀⠀⠀

Cheers, Gene Heskett, CET.
-- 
"There are four boxes to be used in defense of liberty:
  soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author, 1940)
If we desire respect for the law, we must first make the law respectable.
  - Louis D. Brandeis

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

#268537

On Tue 26 Mar 2024 at 04:38:52 (-0400), gene heskett wrote:
> On 2/9/24 20:36, Alexander V. Makartsev wrote:
[ … ]
> > It's not possible for me to know what went wrong.
> > Have you created "reftestfile" inside "/mnt/disktest" directory?
> > How many "testfile*" files, if any, were created on the filesystem
> > mounted at "/mnt/disktest"?
> > Was there anything relevant in the syslog about "sdm" drive after the test?
> > If you'd followed my instructions step by step, you'd end up
> > inside "/mnt/disktest" directory and for the last step all you had
> > to do is copy and paste that one-liner 'for' loop into the command
> > line.
> > It's a long line and it really meant to be copied and pasted not
> > typed by hand, and also to give you the idea of the process, so
> > you could adjust it if needed.
> > I've tested it again on my computer and it worked as expected,
> > synchronously created "testfiles" inside current directory and
> > calculated their hashes one by one.
> > 
> And by now, I've forgotten what it was that we were trying to
> accomplish.  One of the hazards of my next b-day being the 90'th.
> Sorry. Or t-bird is messing  with my mind by reserectiing older messages.

You seem to have mislaid your first reply to Alexander, at:
  https://lists.debian.org/debian-user/2024/02/msg00422.html
which appears to show that the drive was a dud 64GB disk, and
not 2TB in capacity.

Cheers,
David.

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

#267145

On 2/7/24 23:14, gene heskett wrote:
> gene@coyote:/etc$ sudo smartctl --all -dscsi /dev/sdm
> smartctl 7.3 2022-02-28 r5338 [x86_64-linux-6.1.0-17-rt-amd64] (local 
> build)
> Copyright (C) 2002-22, Bruce Allen, Christian Franke, www.smartmontools.org
> 
> === START OF INFORMATION SECTION ===
> Vendor:
> Product:              SSD 3.0
> Revision:             2.00
> Compliance:           SPC-2
> User Capacity:        2,097,152,000,000 bytes [2.09 TB]
> Logical block size:   512 bytes
> scsiModePageOffset: response length too short, resp_len=4 offset=4 bd_len=0
> scsiModePageOffset: response length too short, resp_len=4 offset=4 bd_len=0
>  >> 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.
> gene@coyote:/etc$
> 
> And then again, it worked, sorta
> 
> Cheers, Gene Heskett, CET.


Please try again with the drive connected directly to a motherboard USB 
3.0 port.


I seem to recall that you have a lot of USB devices connected to your 
computer(s).  The Asus PRIME Z370-A II Series manual page ix states:

Intel ® Z370 Chipset
- 6 x USB 3.1 Gen 1 ports (4 ports @mid-board, 2 ports @back panel)
USB
- 6 x USB 2.0/1.1 ports (4 ports @mid-board, 2 ports @back panel)
Asmedia ® USB 3.1 Gen 2 controller
- 1 x USB 3.1 Gen 2 port @back panel (teal blue, Type-A)
- 1 x USB 3.1 Gen 2 port @back panel (USB Type CTM)


Page 1-16 states:

USB 3.1 Gen 1 connectors (20-1 pin U31G1_12; U31G1_34)

This connector allows you to connect a USB 3.1 Gen 1 module for 
additional USB 3.1 Gen 1 front or rear panel ports. With an installed 
USB 3.1 Gen 1 module, you can enjoy all the benefits of USB 3.1 Gen 
1including faster data transfer speeds of up to 5 Gb/s, faster charging 
time for USB-chargeable devices, optimized power efficiency, and 
backward compatibility with USB 2.0.

The USB 3.1 Gen 1 module is purchased separately.


Page 1-17 states:

USB 2.0 connectors (10-1 pin USB910; USB1112)

These connectors are for USB 2.0 ports. Connect the USB module cable to 
these connectors, then install the module to a slot opening at the back 
of the system chassis. This USB connector complies with USB 2.0 
specification that supports up to 480 Mb/s connection speed.

The USB 2.0 module is purchased separately.


STFW including asus.com, I am unable to find "USB 3.1 Gen 1 module" or 
"USB 2.0 module" (?).


Does your chassis have front panel USB 2.0 and/or USB 3.1 Gen 1 ports 
with cables and matching connectors?  Have you connected them to the 
motherboard headers?  Do they work?


Alternatively, if you have an available chassis expansion slot:

https://www.startech.com/en-us/cables/usbplate4


I am unable to find a similar part for the motherboard USB 3.1 Gen 1 
20-pin headers.  Perhaps a USB 3.0 will work (?):

https://www.amazon.com/RIITOP-Female-Connector-Adapter-Bracket/dp/B01KJPUI5W


Or, if you have an available motherboard PCIe slot:

https://www.startech.com/en-us/cards-adapters/usb-30/cards?filter_bustype=pci%2520express


David

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

#267147

On 2/8/24 10:24, David Christensen wrote:
> On 2/7/24 23:14, gene heskett wrote:
>> gene@coyote:/etc$ sudo smartctl --all -dscsi /dev/sdm
>> ...
>> scsiModePageOffset: response length too short, resp_len=4 offset=4 
>> bd_len=0
>> scsiModePageOffset: response length too short, resp_len=4 offset=4 
>> bd_len=0
>>  >> 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.
>> ...
> Please try again with the drive connected directly to a motherboard USB 
> 3.0 port.


Error:  The motherboard has no USB 3.0 ports.


Correction:  Please try connecting the drive to each and every 
motherboard USB port to see if and which ports work with the drive and 
smartctl(8).


David

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

#267148

David Christensen wrote: 
> 
> Page 1-16 states:
> 
> USB 3.1 Gen 1 connectors (20-1 pin U31G1_12; U31G1_34)
> 
> This connector allows you to connect a USB 3.1 Gen 1 module for additional
> USB 3.1 Gen 1 front or rear panel ports. With an installed USB 3.1 Gen 1
> module, you can enjoy all the benefits of USB 3.1 Gen 1including faster data
> transfer speeds of up to 5 Gb/s, faster charging time for USB-chargeable
> devices, optimized power efficiency, and backward compatibility with USB
> 2.0.
> 
> The USB 3.1 Gen 1 module is purchased separately.
> 
> 
> STFW including asus.com, I am unable to find "USB 3.1 Gen 1 module" or "USB
> 2.0 module" (?).

USB 3.0 Gen 1 is a rename of USB 3.0.

2x Type A from standard motherboard header:
https://www.newegg.com/p/181-0783-00017?Item=9SIAPY9F266548

-dsr-

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

#267178

On 2/8/24 13:25, David Christensen wrote:
> On 2/7/24 23:14, gene heskett wrote:
>> gene@coyote:/etc$ sudo smartctl --all -dscsi /dev/sdm
>> smartctl 7.3 2022-02-28 r5338 [x86_64-linux-6.1.0-17-rt-amd64] (local 
>> build)
>> Copyright (C) 2002-22, Bruce Allen, Christian Franke, 
>> www.smartmontools.org
>>
>> === START OF INFORMATION SECTION ===
>> Vendor:
>> Product:              SSD 3.0
>> Revision:             2.00
>> Compliance:           SPC-2
>> User Capacity:        2,097,152,000,000 bytes [2.09 TB]
>> Logical block size:   512 bytes
>> scsiModePageOffset: response length too short, resp_len=4 offset=4 
>> bd_len=0
>> scsiModePageOffset: response length too short, resp_len=4 offset=4 
>> bd_len=0
>>  >> 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.
>> gene@coyote:/etc$
>>
>> And then again, it worked, sorta
>>
>> Cheers, Gene Heskett, CET.
> 
> 
> Please try again with the drive connected directly to a motherboard USB 
> 3.0 port.
> 
That is where it still is, on a blue usb3.0 port on a 3 yo ASUS mobo.
> 
> I seem to recall that you have a lot of USB devices connected to your 
> computer(s).  The Asus PRIME Z370-A II Series manual page ix states:
> 
> Intel ® Z370 Chipset
> - 6 x USB 3.1 Gen 1 ports (4 ports @mid-board, 2 ports @back panel)
> USB
> - 6 x USB 2.0/1.1 ports (4 ports @mid-board, 2 ports @back panel)
> Asmedia ® USB 3.1 Gen 2 controller
> - 1 x USB 3.1 Gen 2 port @back panel (teal blue, Type-A)
> - 1 x USB 3.1 Gen 2 port @back panel (USB Type CTM)
> 
> 
> Page 1-16 states:
> 
> USB 3.1 Gen 1 connectors (20-1 pin U31G1_12; U31G1_34)
> 
> This connector allows you to connect a USB 3.1 Gen 1 module for 
> additional USB 3.1 Gen 1 front or rear panel ports. With an installed 
> USB 3.1 Gen 1 module, you can enjoy all the benefits of USB 3.1 Gen 
> 1including faster data transfer speeds of up to 5 Gb/s, faster charging 
> time for USB-chargeable devices, optimized power efficiency, and 
> backward compatibility with USB 2.0.
> 
> The USB 3.1 Gen 1 module is purchased separately.
> 
> 
> Page 1-17 states:
> 
> USB 2.0 connectors (10-1 pin USB910; USB1112)
> 
> These connectors are for USB 2.0 ports. Connect the USB module cable to 
> these connectors, then install the module to a slot opening at the back 
> of the system chassis. This USB connector complies with USB 2.0 
> specification that supports up to 480 Mb/s connection speed.
> 
> The USB 2.0 module is purchased separately.
> 
> 
> STFW including asus.com, I am unable to find "USB 3.1 Gen 1 module" or 
> "USB 2.0 module" (?).
> 
> 
> Does your chassis have front panel USB 2.0 and/or USB 3.1 Gen 1 ports 
> with cables and matching connectors?  Have you connected them to the 
> motherboard headers?  Do they work?
> 
> 
> Alternatively, if you have an available chassis expansion slot:
> 
> https://www.startech.com/en-us/cables/usbplate4
> 
> 
> I am unable to find a similar part for the motherboard USB 3.1 Gen 1 
> 20-pin headers.  Perhaps a USB 3.0 will work (?):
> 
> https://www.amazon.com/RIITOP-Female-Connector-Adapter-Bracket/dp/B01KJPUI5W
> 
> 
> Or, if you have an available motherboard PCIe slot:
> 
> https://www.startech.com/en-us/cards-adapters/usb-30/cards?filter_bustype=pci%2520express
> 
> 
> David
> 
> .

Cheers, Gene Heskett, CET.
-- 
"There are four boxes to be used in defense of liberty:
  soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author, 1940)
If we desire respect for the law, we must first make the law respectable.
  - Louis D. Brandeis

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

#267212

On 2/9/24 00:51, gene heskett wrote:
> On 2/8/24 13:25, David Christensen wrote:
>> On 2/7/24 23:14, gene heskett wrote:
>>> gene@coyote:/etc$ sudo smartctl --all -dscsi /dev/sdm
>>> ...
>>> scsiModePageOffset: response length too short, resp_len=4 offset=4 
>>> bd_len=0
>>> scsiModePageOffset: response length too short, resp_len=4 offset=4 
>>> bd_len=0
>>>  >> 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.
>>> gene@coyote:/etc$
>>>
>>> And then again, it worked, sorta
>>> ...
>> Please try again with the drive connected directly to a motherboard 
>> USB 3.0 port.
>>
> That is where it still is, on a blue usb3.0 port on a 3 yo ASUS mobo.


Does smartctl(8) fail when you connect the USB SSD to other USB ports?


David

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

#267237

On 2/10/24 00:46, David Christensen wrote:
> On 2/9/24 00:51, gene heskett wrote:
>> On 2/8/24 13:25, David Christensen wrote:
>>> On 2/7/24 23:14, gene heskett wrote:
>>>> gene@coyote:/etc$ sudo smartctl --all -dscsi /dev/sdm
>>>> ...
>>>> scsiModePageOffset: response length too short, resp_len=4 offset=4 
>>>> bd_len=0
>>>> scsiModePageOffset: response length too short, resp_len=4 offset=4 
>>>> bd_len=0
>>>>  >> 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.
>>>> gene@coyote:/etc$
>>>>
>>>> And then again, it worked, sorta
>>>> ...
>>> Please try again with the drive connected directly to a motherboard 
>>> USB 3.0 port.
>>>
>> That is where it still is, on a blue usb3.0 port on a 3 yo ASUS mobo.
> 
> 
> Does smartctl(8) fail when you connect the USB SSD to other USB ports?
> 
Allready packed up for return, I found enough fraud with the f3 package 
to jail somebody.
> 
> David
> 
> .

Cheers, Gene Heskett, CET.
-- 
"There are four boxes to be used in defense of liberty:
  soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author, 1940)
If we desire respect for the law, we must first make the law respectable.
  - Louis D. Brandeis

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

Back to top | Article view | linux.debian.user

csiph-web