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

Thread View: de.comp.hardware.laufwerke.festplatten

2 messages

[T] Back to Threads [V] Tree View [G] Group Articles

2 total messages Started by Kay Martinen Wed, 13 Mar 2024 22:07

#96979

Author: Kay Martinen
Date: Wed, 13 Mar 2024 22:07

56 lines
2433 bytes

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 m1024@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

--
nix

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

#96980

Author: Marcel Mueller
Date: Thu, 14 Mar 2024 20:28

56 lines
2568 bytes

Am 13.03.24 um 22:07 schrieb 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.


> 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.


> 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

Thread Navigation

This is a paginated view of messages in the thread with full content displayed inline.

Messages are displayed in chronological order, with the original post highlighted in green.

Use pagination controls to navigate through all messages in large threads.

Back to All Threads