Freezes accompanied by ATA WRITE FPDMA QUEUED timeout messages point at the SATA command-queuing path rather than — or at least not only — at failing flash media. Since SMART, vendor diagnostics, and a read-only e2fsck all passed, the most informative next experiment is booting with NCQ disabled via libata.force=noncq. If the timeouts vanish, you are dealing with a firmware/driver interoperability problem; if they persist, the evidence shifts toward genuine hardware failure.
What the log lines are telling you
"FPDMA QUEUED" is how the kernel prints NCQ commands. Native Command Queuing lets the drive receive several read and write requests at once and reorder them internally for efficiency. A timeout on a queued write means the drive never completed the command within the allotted time. The libata layer then resets the SATA link, the failed command surfaces as an I/O error to the block layer, ext4 aborts its journal and remounts read-only as a protective measure, and eventually the kernel can no longer page binaries from disk — which is why even ls and sudo start failing with "Input/output error". Every symptom in a case like this is one cascade from a single storage-level fault, and that fault can live in the drive's firmware, the controller, or the driver — not necessarily in the flash itself.
Why "everything passed" doesn't clear the drive
- SMART extended self-test exercises the media internally. It does not stress the host interface with a deep queue of concurrent commands.
- Vendor diagnostics have similar scope: a quick pass/fail of the device, not a long interoperability soak test.
e2fsck -f -nverifies metadata consistency of a static filesystem. It cannot test the live command path between kernel and drive, and read-only mode skips journal replay entirely.
A clean bill of health from all three is therefore entirely consistent with an NCQ-related fault that only appears under real queued write load.
Preserve the evidence first
Before changing anything, capture the kernel log and SMART data to external storage:
journalctl -b -k > ~/kernel-$(date +%F).log
sudo smartctl -a /dev/sda > ~/smart-$(date +%F).txt
Patterns worth searching later: FPDMA, hard resetting link, COMRESET, I/O error, dev sda, and EXT4-fs. In the smartctl output, look at the ATA Error Count and the stored error log — entries there often name the exact failed command (frequently WRITE FPDMA QUEUED) and the affected sectors. Also note the circumstances of each freeze: idle or under load, right after resume from suspend, or during the weekly fstrim run. The pattern matters when interpreting the next step.
The NCQ experiment
Edit /etc/default/grub so the line reads:
GRUB_CMDLINE_LINUX_DEFAULT="quiet splash libata.force=noncq"
Run sudo update-grub, reboot, and confirm the parameter reached the kernel with cat /proc/cmdline. Then use the machine normally while watching journalctl -k -f in a terminal, and give it several days to reproduce whatever workload previously triggered the freezes.
A more surgical variant exists: libata.force=noncqtrim disables queuing only for TRIM/DSM commands. Ubuntu runs fstrim.timer weekly, and some SSD firmwares are known to mishandle queued TRIM while handling queued reads and writes fine. If your freezes cluster around that weekly window, try noncqtrim first; if timeouts appear at random times, use the full noncq setting for a cleaner experiment.
Interpreting the outcome
Errors stop with NCQ off. Keep the parameter as a permanent workaround — on a modern SSD used for desktop work, the performance cost is negligible. Then address the root cause properly: check the laptop and SSD vendor for firmware updates, install any pending BIOS update, and test newer kernels. Queued-command mishandling in specific SSD firmware revisions is a well-documented class of bug.
Errors continue with NCQ off. The failing commands are now plain, non-queued ones, which strengthens the hardware hypothesis. Useful next tests: run a full read sweep from the live USB with sudo dd if=/dev/sda of=/dev/null bs=1M status=progress while watching dmesg; re-run smartctl -a immediately after the next failure and compare error counts; and if possible, test the drive in a USB enclosure or another machine — or a different drive in this laptop.
Either way, once storage is stable again, run a writable sudo e2fsck -f /dev/sda2 from the live USB. Your earlier check was read-only and the journal was aborted mid-flight, so a full pass is warranted before trusting the filesystem again.
Other suspects worth eliminating
- Link power management. You already forced
max_performance— verify it actually stuck by checking/sys/class/scsi_host/host*/link_power_management_protocol. Conversely, some SSDs misbehave at aggressive power saving, so both directions are worth testing. - The CUPS error. A misconfigured print service can make the desktop feel sluggish, but no userspace service can generate ATA timeouts. Treat responsiveness complaints and storage errors as two separate problems.
- Physical connection. Reseating the SSD is free and rules out a marginal board connector, which can produce intermittent link resets that look exactly like this.
Frequently Asked Questions
Will disabling NCQ hurt performance?
For typical desktop workloads on an SSD, barely. NCQ mainly benefits spinning disks and deep-queue server storage; a laptop rarely notices the loss of command reordering.
What does "WRITE FPDMA QUEUED" actually mean?
It is the kernel's name for an NCQ write — First Party DMA, queued. The word "queued" is the clue that the failure involves the drive's command-queue handling rather than a simple read error.
Can I leave libata.force=noncq set permanently?
Yes. It is a standard kernel parameter and survives package updates as long as the line remains in /etc/default/grub. Re-run update-grub after any manual edit.
Should I try noncqtrim before noncq?
If failures correlate with the weekly TRIM window, yes — it is the narrower fix. If failures are random, go straight to noncq so the experiment is unambiguous.
My root filesystem was remounted read-only. Is my data damaged?
Usually not. The read-only remount is ext4 protecting itself from further writes. Once the storage fault is fixed, run a full e2fsck -f on the unmounted partition and let it replay the journal.
SMART passed twice — do I still need to suspect the drive?
Conditionally, yes. SMART measures media health, not interface and queue behavior under host load. A drive can pass every self-test and still time out on queued commands due to a firmware bug.