I think, I found the root cause.
Kernel 6.12.11 and Kernel 6.13 do _not_ exhibit the problem and to my
untrained eye, the affected layer has been reworked quite a bit in these
versions.
After reviewing the mailing list archives and the kernel commit logs I
suspect the following patch is missing from the kernel 6.6 stable
series. It was developed by Igor together with the patches to
libata-sata, but it did not make it into the 6.6 stable branch of
offical kernel.
After applying this to 6.6.74, that version also works like a charm
(without backing out the libata-sata patch).
From 18676c6aab0863618eb35443e7b8615eea3535a9 Mon Sep 17 00:00:00 2001
From: Igor Pylypiv <ipylypiv@xxxxxxxxxx>
Date: Tue, 2 Jul 2024 02:47:34 +0000
Subject: ata: libata-core: Set ATA_QCFLAG_RTF_FILLED in fill_result_tf()
ATA_QCFLAG_RTF_FILLED is not specific to ahci and can be used generally
to check if qc->result_tf contains valid data.
Reviewed-by: Hannes Reinecke <hare@xxxxxxx>
Reviewed-by: Damien Le Moal <dlemoal@xxxxxxxxxx>
Reviewed-by: Niklas Cassel <cassel@xxxxxxxxxx>
Signed-off-by: Igor Pylypiv <ipylypiv@xxxxxxxxxx>
Link: https://lore.kernel.org/r/20240702024735.1152293-7-ipylypiv@xxxxxxxxxx
Signed-off-by: Niklas Cassel <cassel@xxxxxxxxxx>
---
drivers/ata/libata-core.c | 8 ++++++++
1 file changed, 8 insertions(+)
(limited to 'drivers/ata/libata-core.c')
diff --git a/drivers/ata/libata-core.c b/drivers/ata/libata-core.c
index 4f35aab81a0a38..45e3acb466c32a 100644
--- a/drivers/ata/libata-core.c
+++ b/drivers/ata/libata-core.c
@@ -4794,8 +4794,16 @@ static void fill_result_tf(struct ata_queued_cmd *qc)
{
struct ata_port *ap = qc->ap;
+ /*
+ * rtf may already be filled (e.g. for successful NCQ commands).
+ * If that is the case, we have nothing to do.
+ */
+ if (qc->flags & ATA_QCFLAG_RTF_FILLED)
+ return;
+
qc->result_tf.flags = qc->tf.flags;
ap->ops->qc_fill_rtf(qc);
+ qc->flags |= ATA_QCFLAG_RTF_FILLED;
}
static void ata_verify_xfer(struct ata_queued_cmd *qc)
--
cgit 1.2.3-korg
Am 28.01.2025 um 12:14 schrieb Christian Kühnke:
Hi all,
i recently noticed that on my oldish Fujitsu Primergy Server with a
C602 SAS controller and SATA disks, I would get strange SMART results
from smartctl:
