SATA CRC errors and repeated link resets · Linux Fix Lab

Symptoms & scope

I/O pauses coincide with repeated ATA recovery.
A drive disappears briefly or the negotiated SATA speed falls.

Relevant environment

SATA HDD or SSD connected through AHCI/libata; USB bridges may hide ATA error details.

Recognizable messages (synthetic examples)

ata2: SError: { UnrecovData 10B8B BadCRC Handshk }

Investigate the SATA transport and correlate the port with the actual drive; this does not diagnose filesystem corruption.

ata2.00: error: { ICRC ABRT }

A cable or link investigation is justified; an aborted command without ICRC would be less specific.

Possible causes

These are possible explanations, not a confirmed diagnosis. Several independent faults can coexist.

BadCRC or ICRC supports a transport fault involving cable, connectors, power, controller or drive electronics; it does not identify one component.
A firmware or power-management issue remains possible if physical checks do not change the reproducible pattern.

Diagnose safely

Run one command at a time in the relevant session. Read the explanation first. Uppercase placeholders need your own values; tools and privileges vary by distribution. These commands are displayed here and never executed by the website.

Check 1

Read current-boot kernel events; journal access may require administrator privileges. Compare the ata port and timestamps with the pause.

journalctl -k -b --no-pager -n 300

Interpret the result: BadCRC/ICRC is transfer corruption; hard resetting link alone can also follow hotplug or other faults. Preserve the preceding exception line.

Check 2

Replace /dev/sdX with the whole drive identified by model and serial number. This reads SMART and error logs; it does not start a self-test.

sudo smartctl -x /dev/sdX

Interpret the result: A rising SATA CRC count across incidents supports the link hypothesis. A historical nonzero count is not proof of a current fault; SMART passing does not rule it out.

Evidence-guided next steps

Check one SATA data connection

If repeated CRC reports identify this drive, shut the machine down fully, replace its data cable with a known-good cable, and repeat the same bounded workload. Change the motherboard port only in a separate comparison.

Precautions: Back up important data first. Verify drive identity because ata numbers and /dev/sdX names can change after moving ports.

Recovery / rollback: Power off again and restore the recorded cable and port arrangement if the change makes detection worse.

Did this solution help you?

Share this solution #

Inspect power and controller evidence

If a fresh cable does not stop new errors, inspect power connectors and any adapter while powered off, then compare the same drive on another known-good controller if available. Use model-specific vendor firmware guidance only after identifying the drive.

Precautions: Do not hotplug internal power or disable NCQ globally as an unexplained first step. Firmware updates require a verified backup and reliable power.

Recovery / rollback: Restore the original connection after the comparison. Firmware downgrade support depends on the vendor; keep recovery media and backups.