ADATA SU680 SSD on Dell Vostro 15 3510 shows repeated SATA resets, GPT/metadata instability, SMART reset-counter inflation, freezes, and I/O errors under Ubuntu until link power management is forced to max_performance

Support and Help
, , , ,
1

Ubuntu Version:
24.04 LTS (HWE kernel 6.17)

Desktop Environment:
GNOME

Problem Description:
A Dell Vostro 15 3510 running Ubuntu from an ADATA SU680 1TB SATA SSD (/dev/sda, firmware VE1R910D) experienced repeated storage instability that appears related to Linux SATA link power management.

Update:
A Linux/libata maintainer indicated that this SSD model (ADATA SU680) likely needs an ATA_QUIRK_NOLPM quirk entry in drivers/ata/libata-core.c. This makes my case look like a model-specific SATA LPM compatibility issue rather than classic SSD media failure. Similar issues can also affect other SSD models, and some models may simply not be quirked yet, so readers with similar symptoms on different drives should still review this topic.

Main symptoms observed:

  • Initial symptom: apparent GPT/partition-table corruption or unreadability on the ADATA SATA SSD, causing the machine to skip the GRUB menu and boot directly into Windows 11. In Windows, the SATA disk appeared as if its GPT/partition metadata might require initialization. The GPT was later restored successfully from the backup GPT.
  • repeated SATA/libata transport-layer failures
  • failed WRITE/READ FPDMA QUEUED commands
  • Emask 0x4 (timeout) and Emask 0x10 (ATA bus error)
  • repeated ata1 hard link resets
  • transient I/O errors on /dev/sda
  • SMART Power_Cycle_Count / Lifetime Power-On Resets increasing during normal Ubuntu runtime without any real reboot or shutdown event
  • broader system-level effects including slow OS behavior, temporary hangs/freezes, and application instability

The issue was reproducible during normal Ubuntu runtime before the workaround.

Reproduction pattern:

  1. Boot Ubuntu from the ADATA SU680 SATA SSD
  2. Leave the system running normally
  3. Monitor SMART counters and kernel logs
  4. Observe that Lifetime Power-On Resets keeps increasing during runtime and libata/SATA errors appear

Relevant System Information:

  • Laptop: Dell Vostro 15 3510
  • Ubuntu installed on: ADATA SU680 1TB SATA SSD
  • Device: /dev/sda
  • SSD firmware: VE1R910D
  • Windows is installed separately on an NVMe SSD
  • Before the workaround, the Linux SATA power-related state was:

/sys/class/scsi_host/host0/link_power_management_policy:min_power_with_partial
/sys/class/scsi_host/host1/link_power_management_policy:min_power_with_partial
/sys/class/block/sda/device/power/control:on

SMART did not suggest classic SSD media failure:

  • SMART overall health: PASSED
  • Reallocated_Sector_Ct = 0
  • Reported_Uncorrect = 0
  • UDMA_CRC_Error_Count = 0
  • Available_Reservd_Space = 100
  • Percentage Used Endurance Indicator = 0
  • SMART error log was empty
  • A full raw-disk read succeeded
  • A later extended SMART self-test completed without error

Error Messages:
Representative kernel log patterns included:

ata1.00: failed command: WRITE FPDMA QUEUED
ata1.00: failed command: READ FPDMA QUEUED
Emask 0x4 (timeout)
Emask 0x10 (ATA bus error)
irq_stat 0x08000000, interface fatal error
ata1: SError: { PHYRdyChg CommWake }
ata1: SError: { UnrecovData CommWake Handshk }
ata1: hard resetting link
sd 0:0:0:0: [sda] Sense Key : Aborted Command
I/O error, dev sda, sector ...

Representative SMART runtime counter growth before the workaround:

2026-03-12 15:18:08  Lifetime_Power_On_Resets=16467
2026-03-12 15:18:13  Lifetime_Power_On_Resets=16468
2026-03-12 15:18:19  Lifetime_Power_On_Resets=16470
2026-03-12 15:18:25  Lifetime_Power_On_Resets=16473
2026-03-12 15:18:30  Lifetime_Power_On_Resets=16475

What I’ve Tried:

  • checked SMART using smartctl
  • reviewed kernel logs across multiple boots
  • compared behavior under Ubuntu and Windows
  • ran a full raw-disk read test successfully
  • ran SMART self-tests
  • changed SATA link power management policy to max_performance:
for f in /sys/class/scsi_host/host*/link_power_management_policy; do
  echo max_performance | sudo tee "$f"
done

This stopped the abnormal SMART reset-counter growth immediately.

After forcing max_performance:

  • the SMART counter stabilized
  • later long boots were clean
  • the extended SMART self-test passed
  • system responsiveness improved
  • hangs/freezes and related instability stopped being observed

Current conclusion:
This looks like a Linux SATA ALPM / DIPM / AHCI / libata incompatibility with this SSD/platform combination rather than classic SSD NAND/media failure.

Additional Note:
If others have seen similar behavior with the ADATA SU680 or comparable SATA SSDs under Ubuntu, especially where forcing link power management to max_performance resolves the issue, I would appreciate comparison and confirmation.

References:
This is an Ubuntu kernel bug I filed. It contains full technical evidence in an archive there including SMART output, affected-boot logs, clean post-fix logs, storage layout, and system identification.

1 Like
2

Welcome to Ubuntu Discourse :slight_smile:

Thanks for sharing your findings with the community and, more importantly, filing a bug report.

2 Likes
3

Update on the issue:

The problem is now confirmed to be a device-specific SATA link power management compatibility issue rather than classic SSD media failure and not a generic Linux storage failure affecting all SSDs.

I received a response from the Linux/libata maintainer indicating that this device needs an ATA_QUIRK_NOLPM quirk entry in drivers/ata/libata-core.c and that such a patch is rather simple.

The exact IDENTIFY model string reported from hdparm -I /dev/sda for my affected SSD is:

Model Number: ADATA SU680

Current understanding:

  • the issue appears to be tied to this specific SSD model / firmware interacting badly with SATA link power management
  • Linux should handle this model by forcing NOLPM through a libata quirk
  • this does not look like classic SSD NAND/media failure based on the SMART evidence and later successful testing

Important note about this type of fix:
These libata quirk patches are device-model-specific. In other words, if a new SSD model is discovered to have similar LPM-related problems, that model must usually be added separately with its own quirk entry. A quirk added for one SSD model does not automatically fix other models unless they are explicitly matched by the quirk table.

For anyone investigating a similar issue:

  1. Check the exact SSD model string using:
    sudo hdparm -I /dev/sdX
  2. Check whether your model is already covered by a quirk in:
    drivers/ata/libata-core.c
  3. Also check whether a recent patch already exists for your model but is not yet present in your current kernel version
  4. If no existing quirk or Ubuntu-delivered fix is found for your exact SSD model and kernel version, report it:
    • on Launchpad for Ubuntu kernel tracking
    • and on linux-ide if it appears to be a device-specific libata/LPM compatibility issue

Persistent Workaround

While waiting for an upstream kernel patch, the persistent workaround currently being used successfully on this machine is to force SATA link power management to max_performance on every boot with a systemd service.

File:
/etc/systemd/system/disable-sata-alpm.service

Contents:

[Unit]
Description=Disable SATA ALPM for AHCI hosts
After=multi-user.target

[Service]
Type=oneshot
ExecStart=/bin/sh -c ‘for f in /sys/class/scsi_host/host*/link_power_management_policy; do echo max_performance > “$f”; done’
RemainAfterExit=yes

[Install]
WantedBy=multi-user.target

After creating it:

sudo systemctl daemon-reload
sudo systemctl enable disable-sata-alpm.service
sudo systemctl start disable-sata-alpm.service

Important note:
This is a persistent workaround, not the real upstream fix. The real fix should be a kernel quirk for the affected device model.

Current status:

  • Linux/libata maintainer replied
  • maintainer indicated that ATA_QUIRK_NOLPM is needed for this device
  • exact model string has now been sent upstream
  • I am available to test the patch once proposed
4

Update:

This issue has now been fully validated on this hardware and appears to be resolved by the kernel ATA_QUIRK_NOLPM fix for ADATA SU680.

Ubuntu-side testing and validation were tracked on the corresponding Launchpad bug, where Alice C. Munduruca prepared the patch and the PPA test kernel used for validation.

Test system:

  • Dell Vostro 15 3510
  • ADATA SU680 1TB SATA SSD
  • firmware VE1R910D

What was tested:

The purpose of the testing was to verify whether the kernel quirk actually resolves the SATA link power management issue on this SSD model. To validate that cleanly, three separate boot sessions were tested:

  1. a baseline boot session on the official Ubuntu kernel with the affected SATA path held at max_performance
  2. a reproduction boot session on the official Ubuntu kernel with low-power LPM re-enabled
  3. a patched-kernel boot session using the Launchpad/PPA kernel prepared by Alice, with the workaround not relied on for validation, so the fix itself was being tested directly

1) Baseline boot session

Kernel:

  • 6.17.0-14-generic

Session duration:

  • 01:27:57

Configuration:

  • SATA link power management on the affected path held at max_performance

Observed result:

  • system remained stable
  • no SATA timeout / reset / I/O-error symptoms were observed
  • SMART reset counters remained stable during the recorded session

2) Reproduction boot session on the official kernel

Kernel:

  • 6.17.0-14-generic

Session duration:

  • 01:24:04

Configuration:

  • low-power LPM manually re-enabled using min_power_with_partial

Observed result:

  • the original issue reproduced again
  • kernel logs showed repeated:
    • WRITE FPDMA QUEUED
    • Emask 0x4 (timeout)
    • ata1: hard resetting link
  • SMART monitoring showed abnormal runtime growth of:
    • Power_Cycle_Count / Lifetime Power-On Resets
    • from 17439 to 18347 throughout the session
  • the affected ADATA SSD is on ata1 / scsi host0

3) Patched-kernel boot session

Kernel:

  • 6.17.0-16-generic

Session duration:

  • 01:34:51

Configuration:

  • Launchpad/PPA test kernel prepared by Alice C. Munduruca
  • patch tested directly, without relying on the old workaround to mask the issue

Observed result:

  • kernel log explicitly shows:
    • ata1.00: Model 'ADATA SU680', rev 'VE1R910D', applying quirks: nolpm
    • ata1.00: LPM support broken, forcing max_power
  • attempts to switch the affected host (host0) back to low-power LPM fail with:
    • Operation not supported
  • SMART monitoring remained stable at:
    • 18370 -> 18370
    • throughout the whole session
  • no timeout / hard-reset / I/O-error behavior was observed during the recorded session

Conclusion

On this machine, the patch resolves the issue. The problem is reproducible on the official Ubuntu kernel when low-power SATA LPM is re-enabled, and it no longer reproduces on the patched Launchpad/PPA kernel.

This strongly supports that the issue was a model-specific SATA link power management compatibility problem rather than classic SSD media failure.

The Ubuntu-side fix validation was done through the Launchpad bug, and the patched test kernel used for validation was prepared by Alice C. Munduruca.

For anyone seeing similar symptoms on a different SSD model:

  • do not assume it is automatically the same exact quirk
  • get the exact model string with:
    sudo hdparm -I /dev/sdX
  • collect:
    • sudo smartctl -x /dev/sdX
    • relevant kernel logs
    • current SATA link power management policy
  • and report the exact model string together with the logs

Resolved on this machine for ADATA SU680 by the kernel ATA_QUIRK_NOLPM fix. Users who observe the same verified issue on other SSD models should still collect the exact hdparm -I model string and report it to the kernel maintainers, since separate model-specific quirks may still be required.

5

This topic was automatically closed 18 hours after the last reply. New replies are no longer allowed.