Fix & Frage zu SATA Read log 0x00 page 0x00 failed, Emask 0x40

[Kay Martinen]

Hallo

Ein FYI und eine Frage ob es Nebeneffekte dazu gäbe.

Meine 60 GB S-ATA SSD Bootplatte (TEAM L7 EVO SSD 60GB, FwRev=V2.10)
hier verursachte beim Start immer die Meldung im Betreff die sich auch
in dmesg findet, verbunden mit einer Bootpause. Der Kernel
(6.1.0-18-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.1.76-1 (2024-02-01)
x86_64 GNU/Linux) listet die hier als 'ata3.00'.

Jetzt fand ich mit https://syndamia.com/tutorials/fix-qc-timeout/
endlich die Passende Seite mit einem "Fix" dafür.

Und nachdem ich 'libata.force=3.00:nodmalog' in /etc/default/grub in der
Default Commandline eintrug ist die Meldung auch weg. Anzupassen ist nur
das x.yy mit dem Laufwerk wie es der Kernel identifiziert hier eben '3.00'

Seltsam finde ich ja das Logs für DMA Transfers auf einem speziellen (?)
Bereich der Platte selbst gespeichert sein sollen und der Kernel das nur
durch trial-and-error raus finden könnte weil's kein Feature des
Laufwerks geben soll das dies Anzeigt. So lese ich die Erklärung dazu.

Anyway, 'hdparm -i' auf dem Laufwerk zeigt die immer noch mit udma6 als
aktivem Modus und dmesg zeigt das nach 'update-grub' und reboot jetzt so an

ata3: SATA max UDMA/133 abar ***@0xfe02f000 port 0xfe02f100 irq 35
ata3: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
ata3.00: FORCE: horkage modified (nodmalog)
ata3.00: ATA-10: TEAM L7 EVO SSD 60GB, V2.10, max UDMA/133
ata3.00: NCQ Send/Recv Log not supported
ata3.00: 117231408 sectors, multi 0: LBA48 NCQ (depth 32), AA
ata3.00: Features: Dev-Sleep
ata3.00: NCQ Send/Recv Log not supported
ata3.00: configured for UDMA/133

Die Pause und read log fail meldung ist weg und die Platte läuft.

N.B. Und durch das deaktivieren des Onboard Marvell RAID Controllers ist
jetzt auch dessen Fake/Virtual laufwerk ata16 weg die ich in einem
anderen Post erwähnte.

Ist vielleicht nur eine rein kosmetische Sache. Oder weiß jemand ob das
- Andere Effekte haben könnte (Trim o.ä.)?
- Mit/Ohne das Störungen mehr/weniger werden könnten?

Der Punkt ist ja das dieses Board (GA-790XTA-UD4) in den letzten Tagen
mehrmals mit Kernel-panic stecken blieb. Ein Einfacher memtest-lauf
heute zeigte erst mal keine Fehler. Installiert sind vier exakt gleiche
4 GB DDR3 Module. Ob irgendwas im System über diese Fehlende DMA LOG
Funktion der Platte stolpern kann, auch stunden nach dem Boot oder bei
größeren Datentransfers?

Bye/
/Kay

[Marcel Mueller]

Post by Kay Martinen
Meine 60 GB S-ATA SSD Bootplatte (TEAM L7 EVO SSD 60GB, FwRev=V2.10)
hier verursachte beim Start immer die Meldung im Betreff die sich auch
in dmesg findet, verbunden mit einer Bootpause. Der Kernel
(6.1.0-18-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.1.76-1 (2024-02-01)
x86_64 GNU/Linux) listet die hier als 'ata3.00'.
Jetzt fand ich mit https://syndamia.com/tutorials/fix-qc-timeout/
endlich die Passende Seite mit einem "Fix" dafür.
Und nachdem ich 'libata.force=3.00:nodmalog' in /etc/default/grub in der
Default Commandline eintrug ist die Meldung auch weg. Anzupassen ist nur
das x.yy mit dem Laufwerk wie es der Kernel identifiziert hier eben '3.00'
Seltsam finde ich ja das Logs für DMA Transfers auf einem speziellen (?)
Bereich der Platte selbst gespeichert sein sollen und der Kernel das nur
durch trial-and-error raus finden könnte weil's kein Feature des
Laufwerks geben soll das dies Anzeigt. So lese ich die Erklärung dazu.

Vermutlich Firmware-Bug.
Die werden die Implementierung des Kommandos ATA Befehls READ LOG DMA
EXT versemmelt haben. Dabei hängt sich die Firmware auf und nach einer
Weile löst der Kernel einen Link-Reset aus, was sie wieder erweckt.

=> SSDs am besten nur von echten Flash-Herstellern kaufen und nicht von
Resellern, deren Name niemand kennt.
Samsung, Micron (Crucial), Hynix, Kioxia (früher Toshiba) und Kingston
ist so die gängige Liste; obwohl Kingston auch nur ein Reseller ist,
aber mit einer guten Qualitätssicherung.

Post by Kay Martinen
N.B. Und durch das deaktivieren des Onboard Marvell RAID Controllers ist
jetzt auch dessen Fake/Virtual laufwerk ata16 weg die ich in einem
anderen Post erwähnte.
Ist vielleicht nur eine rein kosmetische Sache. Oder weiß jemand ob das
- Andere Effekte haben könnte (Trim o.ä.)?
- Mit/Ohne das Störungen mehr/weniger werden könnten?

Vermutlich keine.

Post by Kay Martinen
Der Punkt ist ja das dieses Board (GA-790XTA-UD4) in den letzten Tagen
mehrmals mit Kernel-panic stecken blieb. Ein Einfacher memtest-lauf
heute zeigte erst mal keine Fehler. Installiert sind vier exakt gleiche
4 GB DDR3 Module. Ob irgendwas im System über diese Fehlende DMA LOG
Funktion der Platte stolpern kann, auch stunden nach dem Boot oder bei
größeren Datentransfers?

Bei letzterem sehe ich keinen Zusammenhang.

Aber ein Hardwarefehler ist schon nicht unwahrscheinlich. Kannst ja mal
schauen, ob die Kernel-Panics bevorzugt in bestimmten Modulen auftreten.
Das gibt manchmal Hinweise.


Marcel