You are not logged in.
This output from journalctl doesn't look like good news. ata1.00 is sda, and arch is on sda2. Linux mint on sda5 gives the same errors. Help appreciated.
Jun 14 15:09:25 arch kernel: ata1.00: status: { DRDY }
Jun 14 15:09:25 arch kernel: ata1.00: failed command: WRITE FPDMA QUEUED
Jun 14 15:09:25 arch kernel: ata1.00: cmd 61/38:48:f0:7d:86/00:00:05:00:00/40 tag 9 ncq dma 28672 out
res 40/00:48:f0:7d:86/00:00:05:00:00/40 Emask 0x1 (device error)
Jun 14 15:09:25 arch kernel: ata1.00: status: { DRDY }
Jun 14 15:09:25 arch kernel: ata1.00: failed command: WRITE FPDMA QUEUED
Jun 14 15:09:25 arch kernel: ata1.00: cmd 61/08:b8:b0:b1:b0/00:00:07:00:00/40 tag 23 ncq dma 4096 out
res 40/00:48:f0:7d:86/00:00:05:00:00/40 Emask 0x1 (device error)
Jun 14 15:09:25 arch kernel: ata1.00: status: { DRDY }
Jun 14 15:09:25 arch kernel: ata1.00: failed command: WRITE FPDMA QUEUED
Jun 14 15:09:25 arch kernel: ata1.00: cmd 61/08:c0:c8:b1:b0/00:00:07:00:00/40 tag 24 ncq dma 4096 out
res 40/00:48:f0:7d:86/00:00:05:00:00/40 Emask 0x1 (device error)
Jun 14 15:09:25 arch kernel: ata1.00: status: { DRDY }
Jun 14 15:09:25 arch kernel: ata1.00: failed command: WRITE FPDMA QUEUED
Jun 14 15:09:25 arch kernel: ata1.00: cmd 61/08:c8:f0:b1:b0/00:00:07:00:00/40 tag 25 ncq dma 4096 out
res 40/00:48:f0:7d:86/00:00:05:00:00/40 Emask 0x1 (device error)
Jun 14 15:09:25 arch kernel: ata1.00: status: { DRDY }
Jun 14 15:09:25 arch kernel: ata1.00: failed command: WRITE FPDMA QUEUED
Jun 14 15:09:25 arch kernel: ata1.00: cmd 61/08:d0:10:b2:b0/00:00:07:00:00/40 tag 26 ncq dma 4096 out
res 40/00:48:f0:7d:86/00:00:05:00:00/40 Emask 0x1 (device error)
Jun 14 15:09:25 arch kernel: ata1.00: status: { DRDY }
Jun 14 15:09:25 arch kernel: ata1.00: failed command: WRITE FPDMA QUEUED
Jun 14 15:09:25 arch kernel: ata1.00: cmd 61/08:d8:38:b2:b0/00:00:07:00:00/40 tag 27 ncq dma 4096 out
res 40/00:48:f0:7d:86/00:00:05:00:00/40 Emask 0x1 (device error)
Jun 14 15:09:25 arch kernel: ata1.00: status: { DRDY }
Jun 14 15:09:25 arch kernel: ata1.00: failed command: WRITE FPDMA QUEUED
Jun 14 15:09:25 arch kernel: ata1.00: cmd 61/08:e0:58:b2:b0/00:00:07:00:00/40 tag 28 ncq dma 4096 out
res 40/00:48:f0:7d:86/00:00:05:00:00/40 Emask 0x1 (device error)
Jun 14 15:09:25 arch kernel: ata1.00: status: { DRDY }
Jun 14 15:09:25 arch kernel: ata1.00: failed command: WRITE FPDMA QUEUED
Jun 14 15:09:25 arch kernel: ata1.00: cmd 61/08:e8:70:b2:b0/00:00:07:00:00/40 tag 29 ncq dma 4096 out
res 40/00:48:f0:7d:86/00:00:05:00:00/40 Emask 0x1 (device error)
Jun 14 15:09:25 arch kernel: ata1.00: status: { DRDY }
Jun 14 15:09:25 arch kernel: ata1.00: failed command: WRITE FPDMA QUEUED
Jun 14 15:09:25 arch kernel: ata1.00: cmd 61/08:f0:50:c6:d8/00:00:05:00:00/40 tag 30 ncq dma 4096 out
res 40/00:48:f0:7d:86/00:00:05:00:00/40 Emask 0x1 (device error)
Jun 14 15:09:25 arch kernel: ata1.00: status: { DRDY }
Jun 14 15:09:25 arch kernel: ata1.00: supports DRM functions and may not be fully accessible
Last edited by bpeary (2021-06-18 00:32:40)
Offline
Samsung SSDs are somewhat notorious for issues with power saving that's enabled by default, check if setting the relevant disk to max_power helps: https://wiki.archlinux.org/title/Power_ … Management
Other than that, maybe post a
sudo smartctl -a /dev/sda
smartctl is part of the smartmontools package and it should be present on most self respecting live disks.
Last edited by V1del (2021-06-15 21:37:33)
Offline
Seems OK
SMART Self-test log structure revision number 1
Num Test_Description Status Remaining LifeTime(hours) LBA_of_first_error
# 1 Extended offline Completed without error 00% 337 -
Researching this more, I've added the kernel parameter
libata.force=noncq
which stopped the errors.
I guess I can live with that -- this is a moderately-used desktop, not a server. Wish there'd been more discussion online other than 'this is the best SSD ever'. No mention of problems with Samsung, Linux, and AMD until you search on the actual errors you're getting.
Offline
if you have a second sata controller controlling some of your sata ports, try plugging it into that as it depends on sata controller whether it has this issue or not. Swapping from my motherboards sata ports to the chipset's solved it for me without the performance loss of disabling native command queuing,
Offline