smartctl -a shows SATA Version is: SATA 3.2, 6.0 Gb/s (current: 3.0 Gb/s). The advertised maximum and the current link speed do not match. Throughput is halved, but SMART health says PASSED and there are no reallocated, pending, or uncorrectable sectors.

This is a SATA link downshift. The kernel’s libata driver detected persistent CRC errors on the interface and automatically negotiated a lower link speed to maintain data integrity. At 3.0 Gbps the error rate drops enough for transfers to complete, but you have lost half your bandwidth. If the physical layer degrades further, the link may drop again to 1.5 Gbps.

The drive is almost never the problem. The fault is in the cable, backplane, connector, or power delivery. Replacing the drive without fixing the physical layer will reproduce the same downshift on the replacement.

What this means

A SATA link runs at a negotiated speed: 6.0, 3.0, or 1.5 Gbps. Under normal conditions, both the host controller and the drive agree on the highest speed both support. When CRC errors accumulate on the interface, libata stepwise reduces the link speed. Each reduction halves raw bandwidth and is sticky: the link stays at the lower speed until the next reset or reboot, and if the physical fault persists, it downshifts again.

CRC errors are tracked in SMART attribute ID 199 (UDMA_CRC_Error_Count). This counter is cumulative and never resets. A static value from months ago is harmless. A value that is increasing now means the physical connection is actively corrupting data transfers.

The critical diagnostic distinction: if CRC errors are rising but media attributes (ID 5 Reallocated, ID 197 Pending, ID 198 Uncorrectable) are all zero, the drive’s media is healthy. The problem is the transport layer.

flowchart TD
    A["smartctl -a: SATA Version mismatch"] --> B{"ID 199 CRC count increasing?"}
    B -- No --> C["Port may be physically limited
or historical downshift"]
    B -- Yes --> D{"IDs 5, 197, 198 zero?"}
    D -- No --> E["Both cable and media issues
Fix cable first, then evaluate drive"]
    D -- Yes --> F["Transport-only problem
Cable, backplane, or power"]
    F --> G["Reseat cable"]
    G --> H{"CRC count still rising?"}
    H -- No --> I["Resolved: bad connection"]
    H -- Yes --> J["Swap cable or move port"]
    J --> K{"CRC count still rising?"}
    K -- No --> L["Resolved: bad cable or port"]
    K -- Yes --> M["Check backplane, power, EMI"]

Common causes

CauseWhat it looks likeFirst thing to check
Bad or loose SATA cableCRC count rising steadily, link at 3.0 or 1.5 Gbps, no media errorsReseat both ends of the cable, then swap with a known-good cable
Failing backplane portSame drive downshifts in the same bay but not in a different bayMove the drive to another bay; if the problem follows the bay, it is the backplane
SATA power delivery issueCRC errors on multiple drives on the same power rail, possibly with spin retries on HDDsCheck power splitter quality, PSU rail voltage, and connector seating
Electromagnetic interferenceIntermittent CRC bursts, worse under specific workloads or nearby hardwareCheck cable routing near power lines, fans, or high-current components
SATA link power managementSpurious downshifts on specific drive-controller combinationsDisable ALPM or SLPM and observe whether downshifts stop
Port physically limited to 3.0 GbpsLink shows 3.0 Gbps from first boot, CRC count zero, never was 6.0 GbpsCheck motherboard or controller documentation for port speed limits

Quick checks

All commands are read-only and safe for production. Replace /dev/sdX with your device.

# Check current vs maximum SATA link speed
smartctl -a /dev/sdX | grep -i "SATA Version"

# Check UDMA CRC error count (ID 199)
smartctl -A /dev/sdX | grep -i "UDMA_CRC"

# Check media health attributes (should all be zero if cable is the problem)
smartctl -A /dev/sdX | grep -iE "Reallocated|Current_Pending|Offline_Uncorrectable"

# Check current link speed from sysfs
cat /sys/class/ata_link/link*/sata_spd 2>/dev/null

# Check speed limit imposed by libata
cat /sys/class/ata_link/link*/sata_spd_limit 2>/dev/null

# Check downshift count from sysfs (may not exist on all kernels)
cat /sys/class/ata_device/*/spdn_cnt 2>/dev/null

# Check kernel log for link speed changes and errors
dmesg | grep -iE "limiting SATA|SATA link up|ata.*error|hard resetting link" | tail -30

# Check drive-side error log for ICRC (interface CRC) entries
smartctl -l error /dev/sdX | grep -iE "ICRC|ABRT|error"

# Check throughput on the suspect device
iostat -x 1 /dev/sdX

How to diagnose it

  1. Confirm the downshift. Run smartctl -a /dev/sdX and compare the “SATA Version is” line’s advertised maximum against the parenthetical current speed. If current is lower than maximum, the link has downshifted. Rule out a port limitation first: if the drive has always run at 3.0 Gbps and CRC count is zero, the port itself may be a 3.0 Gbps port. This is common on older boards where secondary ports are capped.

  2. Check CRC error trend. Poll smartctl -A /dev/sdX | grep UDMA_CRC twice, a few minutes apart. If the raw value is increasing, the physical layer is actively generating errors right now. A static value means the downshift happened previously and the link has been stable since.

  3. Verify media health is clean. Check IDs 5, 197, and 198. If all are zero or stable at historical baselines, the drive’s media is not the problem. This confirms a transport-layer fault. If media attributes are also degraded, you may have both a cable problem and a media problem. Fix the cable first, then re-evaluate.

  4. Check dmesg for the downshift event. Look for messages like ataX: limiting SATA link speed to 3.0 Gbps and SATA link up 3.0 Gbps. These confirm libata took action. Also look for ICRC errors in the ATA error log, which are interface-level CRC errors recorded by the drive firmware.

  5. Check for vendor-specific downshift counters. Some Samsung SSDs expose ID 243 (SATA_Downshift_Ct) or ID 250. Some Intel SSDs expose ID 183 (SATA_Downshift_Count). If present, these directly count link-speed reductions and confirm the downshift history.

  6. Check sysfs for downshift count. The file /sys/class/ata_device/devX.Y/spdn_cnt shows how many times libata has lowered the speed on that link. A non-zero value confirms repeated downshift events. Not all kernels expose this file.

Metrics and signals to monitor

SignalWhy it mattersWarning sign
UDMA CRC Error Count (ID 199)Directly measures interface data corruptionAny increase from baseline
SATA link speed (smartctl or sysfs)Shows whether the link has downshiftedCurrent speed below drive maximum
Reallocated Sector Count (ID 5)Confirms media is not the problemNon-zero and growing alongside CRC errors
Current Pending Sector (ID 197)Can be falsely elevated by CRC errorsNon-zero but stops growing after cable fix
Kernel ATA errors (dmesg)Shows real-time link eventslimiting SATA, hard resetting link, ICRC
I/O throughput (iostat)Quantifies the performance impactHalved bandwidth with no workload change
Downshift count (sysfs spdn_cnt)Tracks cumulative link-speed reductionsIncreasing over time
Vendor downshift counter (Samsung 243/250, Intel 183)Drive-side confirmation of downshift historyNon-zero and growing

Fixes

Reseat the cable

The simplest fix. Power down, disconnect and reconnect both ends of the SATA data cable. Also reseat the SATA power connector. Vibration, thermal cycling, and handling during maintenance can loosen connectors over time.

After reseating, reboot and check whether the link negotiates at full speed. If CRC count stops increasing, the connection was the problem. If it downshifts again within hours, the cable or connector is marginal.

Swap the cable

Replace the SATA data cable with a known-good one. SATA cables are not all equal: cable length, shielding quality, and connector tolerance vary. A cable that worked at 6.0 Gbps for years can degrade due to oxidation, bending, or heat exposure.

Use a cable rated for SATA 6 Gbps (SATA III). Latch-type connectors (with the metal clip) are preferable in dense chassis because they resist vibration loosening.

Move to a different port or bay

If the drive is in a hot-swap backplane, move it to a different bay. If the problem follows the drive, suspect the drive’s connector or PCB. If the problem stays with the bay, the backplane port or its cabling is the fault.

If the drive is directly cabled to the motherboard or HBA, try a different port. A marginal port on the controller can produce the same symptoms as a bad cable.

Check power delivery

CRC errors can be caused by power supply issues, not just data cables. Loose SATA power connectors, overloaded PSU rails, and poor-quality power splitters all introduce noise on the power line that corrupts the data signal.

Symptoms that point to power rather than data:

  • Multiple drives on the same power rail showing CRC errors or spin retries simultaneously
  • CRC errors that correlate with high disk activity, when power draw spikes
  • Drives that drop off the bus entirely under load

On some drive-controller combinations, SATA link power management (ALPM or SLPM) can cause spurious downshift events. This has been reported on Seagate Exos drives paired with Intel controllers. If the drive downshifts without an obvious physical cause and the controller is known to have ALPM issues, try disabling link power management.

Force a speed limit with libata.force (last resort)

If the physical layer cannot sustain 6.0 Gbps and you need stability while awaiting a cable or backplane replacement, you can cap the link speed at 3.0 Gbps using the kernel boot parameter:

libata.force=1:3.0Gbps

Replace 1 with the ATA port number. This requires a reboot to take effect. It prevents the error-retry cycle that causes intermittent hangs at 6.0 Gbps. It is a workaround, not a fix. The underlying physical fault still exists, and you are accepting permanently halved bandwidth.

Prevention

  • Use quality cables with latching connectors. Non-latching SATA cables work loose in vibrating chassis. Latch clips prevent the most common cause of CRC errors.
  • Route cables away from power lines and fans. EMI from adjacent power conductors can induce CRC errors on unshielded or poorly shielded SATA cables.
  • Baseline CRC count at deployment. Record the ID 199 raw value when each drive is installed. Alert on growth from that baseline, not on absolute value. A drive that shipped with 12 CRC errors from factory testing should not trigger an alert, but any new errors should.
  • Monitor CRC count continuously. The most common operational mistake is ignoring UDMA CRC errors until throughput degrades. Tracking ID 199 growth catches cable degradation before it forces a downshift.
  • Check backplane health during routine maintenance. Hot-swap backplane connectors accumulate dust and contact wear. Inspect and clean contacts during scheduled maintenance windows.
  • Track CRC errors across the fleet. If multiple drives in the same chassis or backplane develop CRC errors simultaneously, the root cause is infrastructure: power, backplane, or EMI, not individual cables.

How Netdata helps

  • Correlates CRC error growth with link speed changes and I/O throughput. When ID 199 starts climbing, the same dashboard shows whether the link has already downshifted and how much throughput has dropped.
  • Distinguishes transport faults from media faults. By monitoring IDs 5, 197, 198, and 199 together, Netdata surfaces rising CRC with clean media, pointing to a cable problem rather than a drive problem.
  • Catches CRC growth before downshift occurs. Per-second metric collection shows the CRC count increasing in real time, often before libata forces a speed reduction.
  • Cross-drive correlation for infrastructure problems. When multiple drives in the same host show CRC errors or spin retries simultaneously, the dashboard makes the pattern visible, pointing to power or backplane failure rather than individual drives.
  • Host-side I/O metrics alongside SMART data. Netdata pairs kernel-level disk latency and throughput with SMART attributes, so you can confirm the performance impact of a downshifted link without switching between tools.