Dennis HilkLinux Fix LabDE

Storage & Filesystems

SATA CRC errors and repeated link resets

Separate SATA transport corruption from failing media when games or file copies stall alongside BadCRC or ICRC reports in the kernel log.

Editorial source review: Start with the evidenceShare this guide
On this page
  1. Symptoms & scope
  2. Possible causes
  3. Diagnose safely
  4. Evidence-guided next steps
  5. References & review
  6. Related problems

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.

Did this solution help you?

Share this solution#

References & review

This guide was prepared from primary project or distribution sources and reviewed on the date shown. This is an editorial source check, not evidence that a fix was reproduced on your hardware. Diagnostic log examples are synthetic fixtures. Version-dependent details must be checked against your installed release.

Related hardware and driver context

These profiles explain relevant driver paths. They do not establish that your device has this fault. Identify your device and binding first.

Identify hardware locally

Investigate the gaming failure path

Connect these system observations to Proton, Vulkan and frame-time evidence. A detected GPU or a reset message alone does not establish the cause of a game crash.

Follow the gaming diagnostic questions · Inspect gaming logs locally