[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: SSD Optimization - Crucial CT1000MX500SSD1



On 04/10/2022 03:56, David Christensen wrote:
On 10/3/22 09:23, piorunz wrote:
On 02/10/2022 21:33, David Christensen wrote:
On 10/2/22 06:19, Marcelo Laia wrote:
# cat /etc/debian_version ; uname -a

bookworm/sid
Linux marcelo 5.19.0-2-amd64 #1 SMP PREEMPT_DYNAMIC Debian 5.19.11-1
(2022-09-24) x86_64 GNU/Linux


Please install Debian Stable.

Why would he?
I have exactly the same SSD (two of them) in my machine, on Debian
Testing, drives in BTRFS Raid1 mode, everything works perfect. But I
have good SATA cables.
OS version has nothing to do with cabling errors in SSD drive SMART log.
He may as well be using DOS, Windows FreeBSD, any Linux - cabling errors
must never happen.

  uname -a
Linux ryzen 5.19.0-2-amd64 #1 SMP PREEMPT_DYNAMIC Debian 5.19.11-1
(2022-09-24) x86_64 GNU/Linux

$ sudo smartctl /dev/sda --all | grep "Device
Model\|SATA_Interfac\|DMA_CRC_Error"
Device Model:     CT1000MX500SSD1
183 SATA_Interfac_Downshift 0x0032   100   100   000    Old_age   Always
       -       0
199 UDMA_CRC_Error_Count    0x0032   100   100   000    Old_age   Always
       -       0

$ sudo smartctl /dev/sdb --all | grep "Device
Model\|SATA_Interfac\|DMA_CRC_Error"
Device Model:     CT1000MX500SSD1
183 SATA_Interfac_Downshift 0x0032   100   100   000    Old_age   Always
       -       0
199 UDMA_CRC_Error_Count    0x0032   100   100   000    Old_age   Always
       -       0


Even if you and the OP ran identical OS instances (e.g. clones), I do
not believe you two have the same make and model computers.  Therefore,
different code paths will be executed -- e.g. device drivers.  So, the
OP's computer may be hitting a bug that your computer does not.

Agree.

I am applying a trouble-shooting strategy -- change one variable, apply
a stimulus, and measure the result.  If the result is the same as it was
before, then the result is unlikely to be related to the variable and/or
change.  But if the result is different, then the result is likely to be
related to the variable and/or change.

Agree, troubleshooting strategy must be followed by elimination. In
general, when dealing with issues, OS is good choice to change (for
example run different system from LiveCD for couple of days)
Of course, this is all premised upon devising a stimulus that reliably
reproduces the result.  When my HDD's/SSD's were having SATA cable
and/or drive rack problems, reading 10 GB from them typically produced
at least one error.

I cannot comment on that, I very very rarely have this kind of issues.
Last time I had it turned out to be faulty RAM (very rare bit rots), not
SATA cable.

When the OP read 10 GB of the SSD using the d-i rescue shell, he was
applying a stimulus after changing the variable "OS instance".  The
result was different.  Therefore, the SATA UDMA CRC errors are related
to changing the OS instance

Maybe. But my bet this is hardware error. RAM or SATA Cable, or SSD
itself. Or motherboard, then this is dead in the water and laptop would
need to be recycled/sold as spares if this happens.

I would also suggest to OP at this point, to do full memtest86 by
passmark (UEFI only) https://www.memtest86.com/
Or old typical (but bugged sometimes) memtest86+ https://www.memtest.org/

Full run of either to make sure CPU/RAM is good.

--
With kindest regards, Piotr.

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


Reply to: