$ guides / smartctl-disk-monitoring / smartctl-udma-crc-error-count ▌

Operations Guides

UDMA_CRC_Error_Count rising: it's the cable, not the drive

Rising UDMA CRC Error Count (SMART attribute 199) is one of the most misdiagnosed signals in production. Operators see the counter climbing, swap the drive, and the replacement develops the same errors because the cable, backplane port, or HBA was the actual cause. The original drive goes back as an RMA, the replacement fails the same way, and the real fault is still in the chassis.

UDMA CRC errors indicate data corruption on the wire between the host and the drive, caught by CRC and retransmitted. They are almost never caused by the drive itself. Data integrity is preserved: each error triggers a retransmission. This is usually a TICKET-level problem, not a PAGE. The drive is not dying and your data is not being corrupted. But the retries reduce effective throughput, and in severe cases the SATA link downshifts speed to compensate.

What this means

UDMA CRC Error Count (ATA SMART attribute ID 199) is a cumulative counter of CRC errors detected during UltraDMA data transfers between the host controller and the drive. Each error means a data packet was corrupted in transit and had to be retransmitted. The counter tracks transport-layer integrity, not media health.

The critical diagnostic signal is the relationship between CRC errors and media errors. If UDMA CRC Error Count is rising but Reallocated Sector Count (ID 5), Current Pending Sector (ID 197), and Offline Uncorrectable (ID 198) are all zero, the drive’s media is healthy. The problem is purely in the physical connection: cable, connector, backplane, or HBA port.

This counter is cumulative and never resets. A drive that accumulated CRC errors in a previous server carries that count forward. You must record the baseline value and watch for growth, not react to the absolute number. A static count of 200 from months ago is acceptable. A count that went from 0 to 200 since yesterday is an active problem.

flowchart TD
    A["UDMA CRC Error Count rising"] --> B{"Media errors IDs 5, 197, 198 also rising?"}
    B -->|"No, all zero"| C["Transport problem: cable, backplane, HBA"]
    B -->|"Yes, also rising"| D["Both problems: media degradation + bad connection"]
    C --> E{"Multiple drives affected?"}
    E -->|"Yes"| F["Backplane or HBA failure"]
    E -->|"No, one drive"| G["Cable or connector on that drive"]
    D --> H["Fix cable first, then re-evaluate media errors"]
    G --> I["Reseat cable, swap with known-good"]
    F --> J["Inspect backplane, HBA firmware, port health"]

Common causes

Cause	What it looks like	First thing to check
Bad or kinked SATA cable	CRC errors on one drive, stable after cable swap	Reseat both ends, then replace cable
Loose connector	CRC errors started after chassis vibration or maintenance	Physical inspection of connector seating
Failing backplane port	Multiple drives on same backplane showing CRC errors	Move drive to different bay
HBA port failure	CRC errors on all drives attached to one HBA port	Check dmesg for link resets on that controller
Electromagnetic interference	Intermittent CRC spikes in dense disk shelves	Check cable routing near power lines
SFF-8087 cable damage	CRC errors on multiple drives behind same mini-SAS cable	Inspect cable for bent pins, replace

Quick checks

# Check UDMA CRC Error Count alongside media error attributes
smartctl -A /dev/sdX | grep -iE "UDMA_CRC|Reallocated|Pending|Uncorrectable"

# Full SMART overview including SATA link speed
smartctl -a /dev/sdX

# Check kernel logs for SATA link errors and speed downshifts
dmesg | grep -iE "ata.*error|SError|link is slow|downshift" | tail -20

# Check SATA negotiated speed vs maximum capability
# Look for "current:" in the SATA Version line
smartctl -a /dev/sdX | grep -i "SATA Version"

# For SAS drives, use PHY error counters instead of attribute 199
smartctl -l sasphy /dev/sdX

# Check the drive's internal error log for ICRC (interface CRC) entries
smartctl -l error /dev/sdX | grep -iE "ICRC|ABRT|UNC"

The single most important check: compare the UDMA CRC Error Count against media error attributes (IDs 5, 197, 198). If CRC errors are climbing but those three are zero or stable, stop investigating the drive and start investigating the physical layer.

NVMe drives do not have this attribute. It is an ATA/ATAPI SMART attribute only, applying to SATA HDDs and SATA SSDs. NVMe transport errors surface through PCIe Advanced Error Reporting in the host kernel, not in SMART data. SAS drives use SCSI PHY error counters instead, accessible via smartctl -l sasphy.

How to diagnose it

Confirm the counter is actually rising. Take two readings separated by a few minutes to an hour. The counter is cumulative, so a single reading tells you nothing about whether the problem is active. A static count is historical. A growing count is active.
Cross-check media error attributes. Run smartctl -A /dev/sdX and check IDs 5 (Reallocated Sector Count), 197 (Current Pending Sector), and 198 (Offline Uncorrectable). If all three are zero or stable while CRC errors climb, the drive media is healthy and the problem is transport.
Check SATA link speed. In smartctl -a /dev/sdX, look at the “SATA Version” line for the “(current: X.X Gb/s)” value. A downshift from 6.0 Gbps to 3.0 Gbps or 1.5 Gbps means the kernel or controller has lowered speed to cope with excessive CRC errors. This masks the problem but reduces throughput.
Check kernel logs for transport errors. Run dmesg and look for ATA error messages. Key patterns include SError fields containing “BadCRC”, SATA link speed renegotiation messages, and bus reset events. These corroborate the SMART counter from the host side.
Check whether multiple drives are affected. If several drives on the same backplane or HBA port show CRC errors, the shared infrastructure (backplane, SFF-8087 cable, HBA) is the likely culprit, not individual drive cables.
Re-evaluate pending sectors after fixing transport. Pending sectors and CRC errors can coexist; a transport error alone does not prove that media is bad, and no universal mechanism makes every CRC failure mark a sector pending. Fix the cable or connector first, then re-read the drive under stable transport and watch whether ID 197 continues to increase.
Note that the counter never resets. After you fix the cable, the raw value stays at whatever it accumulated. You will know the fix worked when the counter stops incrementing, not when it returns to zero. There is no standard tool that clears attribute 199.

Metrics and signals to monitor

Signal	Why it matters	Warning sign
UDMA CRC Error Count (ID 199)	Primary indicator of transport-layer integrity	Any increase from baseline
Reallocated Sector Count (ID 5)	Rules out media degradation	Non-zero and rising alongside CRC errors
Current Pending Sector (ID 197)	May correlate with CRC errors; fix transport first	Non-zero while CRC errors climb
Offline Uncorrectable (ID 198)	Confirmed data loss if non-zero and growing	Any increase
SATA link speed	Downshift means compensating for errors	Current speed below maximum capability
Kernel ATA errors (dmesg)	Host-side view of transport failures	BadCRC, link reset, speed downshift messages
I/O latency (iostat await)	CRC retries cause measurable latency	Elevated await on the affected device

Fixes

Reseat or replace the cable

The most common fix. Power down the drive (or the system if hot-swap is not available), remove the SATA cable at both ends, inspect for damage, and reseat firmly. If CRC errors continue after reseating, swap with a known-good cable. SATA cables are cheap. Replacing one costs minutes, while replacing a healthy drive costs hours and does not fix the problem.

If the drive is part of a RAID array (mdadm, ZFS, hardware RAID), removing it may trigger a rebuild. Plan maintenance windows accordingly.

Move the drive to a different port or bay

If cable replacement does not resolve the issue, move the drive to a different SATA port or drive bay. This isolates whether the problem follows the drive or stays with the port. If CRC errors follow the drive to the new port, the drive’s SATA connector or internal PHY may be physically damaged. If the errors stop in the new port, the original port or backplane contact was the problem.

Inspect the backplane and HBA

When multiple drives on the same backplane show CRC errors, the backplane or its connection to the HBA is degraded. Check for bent pins in the backplane connectors, oxidation on contact pads, and SFF-8087 or SFF-8643 cable damage. If the HBA port itself is failing, check for firmware updates from the vendor and consider moving drives to a different HBA port.

Address electromagnetic interference

In dense disk shelves with many cables routed together, signal integrity can degrade. Separate data cables from power cables where possible. Use shielded SATA cables if the environment demands it. This is less common than mechanical cable issues but is the explanation when physical inspection reveals nothing wrong and the errors are intermittent.

Reset expectations on the counter

After any fix, the counter will not return to zero. Record the post-fix value and monitor for further growth. Zero new increments over days or weeks confirms the fix worked.

Prevention

Baseline every drive at deployment. Capture a full SMART snapshot when a drive is first installed. This establishes whether CRC errors existed from factory testing (single-digit values are common on new drives) or developed in your environment. Without a baseline, you cannot distinguish historical noise from active problems.

Use quality cables and route them properly. Avoid kinking SATA cables or bending them sharply near connectors. Ensure cables are fully seated and secured against vibration. In chassis with significant vibration, connectors can work loose over time.

Monitor CRC error growth rate, not absolute value. Alert on any increase from the last reading, not on the raw count. A drive with 50 historical CRC errors that has been stable for a year is fine. A drive that gained 5 errors since the last check has an active problem.

Check CRC errors before replacing any drive. If CRC errors are rising with zero media errors, fix the cable first. This prevents the cycle of replacing healthy drives and having the replacement develop the same symptoms.

Watch for backplane-wide patterns. If CRC errors appear on several drives connected to the same backplane or HBA port simultaneously, the shared infrastructure is degraded. Individual cable swaps will not fix this.

How Netdata helps

Per-second collection with rate-of-change alerting is the correct way to monitor a cumulative counter like UDMA CRC Error Count. Alert on growth from baseline, not absolute value. A drive with 200 historical errors that has been stable for a year stays quiet; a drive gaining errors right now fires.
Cross-attribute correlation on a shared timeline lets you compare UDMA CRC Error Count against media error attributes (IDs 5, 197, 198). CRC errors rising with zero media errors points immediately to the physical layer.
ML-based anomaly detection flags unexpected CRC error growth without requiring static thresholds, which matters for drives with non-zero baselines from factory testing or prior deployment.
I/O correlation (disk latency, IOPS, queue depth) shows whether CRC retries are actually affecting application performance. Elevated await on a drive with rising CRC errors confirms real impact.