[gelöst, aber nicht erklärt] SATA-Geräte fahren periodisch runter und rauf

[kreuzschnabel]

Hallo, das Problem scheint zwar gelöst, aber mich interessiert, wie so was kommen kann.

Hier läuft ein handelsübliches Debian 11 auf einem Lenovo ThinkCentre, nichts Exotisches, an SATA1 hängt eine Samsung EVO 860, an SATA2 ein normaler DVD-Brenner.

Vor einigen Wochen fiel mir erstmals auf, dass die Oberfläche (KDE) regelmäßig für einige Sekunden einfror. Tasteneingaben wurden zwar gepuffert, kamen aber erst mit Verzögerung in die Zeile geschossen. Das stört beim Textschreiben natürlich sehr. Ein Blick ins Systemlog enthüllte folgenden Vorgang (Beispiel von gestern abend, sinngemäß sah es immer so aus):

Code: Alles auswählen

03.05.2022 19:01:00:952	kernel	ata2: SATA link down (SStatus 0 SControl 320)
03.05.2022 19:01:00:952	kernel	ata1: SATA link down (SStatus 0 SControl 300)
03.05.2022 19:01:00:952	kernel	ata1: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
03.05.2022 19:01:00:952	kernel	ata2: SATA link up 3.0 Gbps (SStatus 123 SControl 320)
03.05.2022 19:01:00:952	kernel	ata2.00: supports DRM functions and may not be fully accessible
03.05.2022 19:01:00:952	kernel	ata2.00: disabling queued TRIM support
03.05.2022 19:01:00:952	kernel	ata1.00: configured for UDMA/100
03.05.2022 19:01:00:952	kernel	ata2.00: supports DRM functions and may not be fully accessible
03.05.2022 19:01:00:952	kernel	ata2.00: disabling queued TRIM support
03.05.2022 19:01:00:952	kernel	ata2.00: configured for UDMA/133
03.05.2022 19:01:00:952	kernel	ata2.00: Enabling discard_zeroes_data

Dies wiederholte sich plusminus paar Sekunden sehr regelmäßig alle drei Minuten. In diesem Beispiel verging keine Zeit, das war wahrscheinlich unmerklich, aber es konnten auch mal sechs Sekunden und mehr zwischen „link down“ und „link up“ liegen. (Auch witzig, dass SATA1 als ata2 erscheint und vice versa, aber was solls.)

Zuerst habe ich mich einer alten Weisheit erinnert und das BIOS (sagt man im EFI-Zeitalter noch BIOS? Egal, sieht so aus) zurückgesetzt (Load Optimal Defaults). Danach war tatsächlich erstmal Ruhe, der Fehler war weg.

Gestern kam das Kernelupdate von 5.10.0-13 auf -14, und damit ging es wieder los. Das erklärte ich mir damit, dass der neue Kernel möglicherweise die optimized defaults in der EFI-Partition (aber die ist doch nur zum OS-Booten da?) mit irgendeinem Quatsch überschreibt, also hab ich nochmal ins Setup gebootet und resettet. Diesmal brachte „Load Optimal Defaults“ aber keine Besserung.

Zweiter erster Verdacht bei Hardwareproblemen sind die Kabel. Ein altes SATA-Kabel müsste noch rumliegen, ah da. Probehalber die SSD mit dem anderen Kabel angeschlossen, das ist zwar zur falschen Seite gewinkelt, passt aber, und weg ist der Fehler. System läuft jetzt so, wie es soll, mit beiden Geräten auf UDMA/133 und SSD auf 6 Gbps, nicht so wie oben und seit dem letzten Booten erscheint im Syslog keine Zeile mehr mit ata1 oder ata2.

Jetzt frage ich mich aber rein interessehalber:
- Welcher Kabelfehler kann dazu führen, dass die Geräte (das andere ist wohl deshalb mitbetroffen, weils derselbe Controller ist) regelmäßig alle drei Minuten runtergefahren und neu gestartet werden?
- Wieso ließ sich das über BIOS-Reset zunächst beheben? Oder war das Zufall?

--ks

[MSfree]

- Welcher Kabelfehler kann dazu führen, dass die Geräte ... regelmäßig alle drei Minuten runtergefahren und neu gestartet werden?

Ich weiß nicht, welcher Azubi sich diese SATA-Anschlüße ausgedacht hat. Da werden stecker- und buchsenseitig Kontaktflächen übereinander gelegt, Kontaktfedern (wie bei RJ45) oder Stiftkontakte mit Ferderbuchsen sind leider nicht vorhanden. Daß so eine lose "Verbindung" zu Problemen führen kann, sollte eigentlich jedem klar sein. SATA-Stecker und Buchsen sind schlicht auf billiger als billig optimiert, jede machanische Maßnahme zum dauerhaften Kontakterhalt wurde weggespart.

Wie es zu dem von dir beobachteten periodischen Verhalten kommen kann, kann viele Gründe haben. Termische Effekte, die sich periodisch verhalten, könnten eine Erklärung sein. Die Kontaktflächen erwärmen sich, bis es einen Aussetzer gibt. Durch den dann fehlenden Strom kühlt sich der Anschluß wieder ab, es gibt erneut Kontakt und der Kernel sorgt für Reconnect, bis die Aufwärmung wieder für einen Kontaktverlust sorgt.

Wieso ließ sich das über BIOS-Reset zunächst beheben? Oder war das Zufall?

Es könnte sein, daß der Reset vorübergehend für einen niedrigere Übertragungsrate (UDMA/100 bzw. SATA 1.5GBit/s statt UDMA/133 bzs. SATA 3/6 GBit/s) gesorgt hat. Mit niedirgeren Übertagungsraten wirken sich Wackelkontakte weniger häufig aus.

[kreuzschnabel]

Da werden stecker- und buchsenseitig Kontaktflächen übereinander gelegt, Kontaktfedern (wie bei RJ45) oder Stiftkontakte mit Ferderbuchsen sind leider nicht vorhanden.

Was kaufste auch fürn Billigkram … nee echt, die mir bekannten kabelseitigen SATA-Stecker haben gewölbte Kontaktzungen mit Federwirkung. Die freien Enden bewegen sich in einem Langloch. Schaus dir mal mit Lupe an

Kann natürlich immer an der falschen Stelle ein Staubkorn oder ein oxidierter Fleck sitzen.

--ks

[kreuzschnabel]

Hier mal ein Auszug der akuten Phase direkt aus der /var/log/syslog:

Code: Alles auswählen

May  3 18:04:04 marvin kernel: [12747.647822] ata2: SATA link down (SStatus 0 SControl 310)
May  3 18:04:09 marvin kernel: [12752.807926] ata1: SATA link down (SStatus 0 SControl 300)
May  3 18:04:15 marvin kernel: [12758.242978] ata1: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
May  3 18:04:15 marvin kernel: [12758.243193] ata2: SATA link up 1.5 Gbps (SStatus 113 SControl 310)
May  3 18:04:15 marvin kernel: [12758.245587] ata2.00: supports DRM functions and may not be fully accessible
May  3 18:04:15 marvin kernel: [12758.246408] ata2.00: disabling queued TRIM support
May  3 18:04:15 marvin kernel: [12758.249094] ata1.00: configured for PIO0
May  3 18:04:15 marvin kernel: [12758.249110] ata2.00: supports DRM functions and may not be fully accessible
May  3 18:04:15 marvin kernel: [12758.249968] ata2.00: disabling queued TRIM support
May  3 18:04:15 marvin kernel: [12758.252077] ata2.00: configured for UDMA/33
May  3 18:04:15 marvin kernel: [12758.252464] ata2.00: Enabling discard_zeroes_data
May  3 18:07:07 marvin kernel: [12930.470553] ata1: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
May  3 18:07:07 marvin kernel: [12930.474503] ata2: SATA link up 1.5 Gbps (SStatus 113 SControl 310)
May  3 18:07:07 marvin kernel: [12930.475855] ata1.00: configured for PIO0
May  3 18:07:07 marvin kernel: [12930.476466] ata2.00: supports DRM functions and may not be fully accessible
May  3 18:07:07 marvin kernel: [12930.477228] ata2.00: disabling queued TRIM support
May  3 18:07:07 marvin kernel: [12930.479590] ata2.00: supports DRM functions and may not be fully accessible
May  3 18:07:07 marvin kernel: [12930.480415] ata2.00: disabling queued TRIM support
May  3 18:07:07 marvin kernel: [12930.482439] ata2.00: configured for UDMA/33
May  3 18:07:07 marvin kernel: [12930.482496] ata2.00: Enabling discard_zeroes_data
May  3 18:10:08 marvin kernel: [13111.629157] ata1: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
May  3 18:10:08 marvin kernel: [13111.633174] ata2: SATA link up 1.5 Gbps (SStatus 113 SControl 310)
May  3 18:10:08 marvin kernel: [13111.634958] ata1.00: configured for PIO0
May  3 18:10:08 marvin kernel: [13111.635080] ata2.00: supports DRM functions and may not be fully accessible
May  3 18:10:08 marvin kernel: [13111.635827] ata2.00: disabling queued TRIM support
May  3 18:10:08 marvin kernel: [13111.638206] ata2.00: supports DRM functions and may not be fully accessible
May  3 18:10:08 marvin kernel: [13111.638988] ata2.00: disabling queued TRIM support
May  3 18:10:08 marvin kernel: [13111.640999] ata2.00: configured for UDMA/33
May  3 18:10:08 marvin kernel: [13111.641055] ata2.00: Enabling discard_zeroes_data
May  3 18:10:10 marvin kernel: [13113.553102] ata1: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
May  3 18:10:10 marvin kernel: [13113.553129] ata2: SATA link up 1.5 Gbps (SStatus 113 SControl 310)
May  3 18:10:10 marvin kernel: [13113.555031] ata2.00: supports DRM functions and may not be fully accessible
May  3 18:10:10 marvin kernel: [13113.555885] ata2.00: disabling queued TRIM support
May  3 18:10:10 marvin kernel: [13113.556478] ata1.00: configured for PIO0
May  3 18:10:10 marvin kernel: [13113.558249] ata2.00: supports DRM functions and may not be fully accessible
May  3 18:10:10 marvin kernel: [13113.559023] ata2.00: disabling queued TRIM support
May  3 18:10:10 marvin kernel: [13113.561027] ata2.00: configured for UDMA/33
May  3 18:10:10 marvin kernel: [13113.561072] ata2.00: Enabling discard_zeroes_data
May  3 18:13:09 marvin kernel: [13291.911841] ata1: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
May  3 18:13:09 marvin kernel: [13291.911881] ata2: SATA link up 1.5 Gbps (SStatus 113 SControl 310)
May  3 18:13:09 marvin kernel: [13291.914091] ata2.00: supports DRM functions and may not be fully accessible
May  3 18:13:09 marvin kernel: [13291.914925] ata2.00: disabling queued TRIM support
May  3 18:13:09 marvin kernel: [13291.917541] ata2.00: supports DRM functions and may not be fully accessible
May  3 18:13:09 marvin kernel: [13291.918367] ata2.00: disabling queued TRIM support
May  3 18:13:09 marvin kernel: [13291.920415] ata2.00: configured for UDMA/33
May  3 18:13:09 marvin kernel: [13291.920463] ata2.00: Enabling discard_zeroes_data
May  3 18:13:09 marvin kernel: [13291.921075] ata1.00: configured for PIO0
May  3 18:16:09 marvin kernel: [13472.554519] ata1: SATA link down (SStatus 0 SControl 300)
May  3 18:16:14 marvin kernel: [13477.794569] ata2: SATA link down (SStatus 0 SControl 310)
May  3 18:16:20 marvin kernel: [13483.228949] ata1: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
May  3 18:16:20 marvin kernel: [13483.233273] ata2: SATA link up 1.5 Gbps (SStatus 113 SControl 310)
May  3 18:16:20 marvin kernel: [13483.234767] ata1.00: configured for PIO0
May  3 18:16:20 marvin kernel: [13483.235316] ata2.00: supports DRM functions and may not be fully accessible
May  3 18:16:20 marvin kernel: [13483.236169] ata2.00: disabling queued TRIM support
May  3 18:16:20 marvin kernel: [13483.238502] ata2.00: supports DRM functions and may not be fully accessible
May  3 18:16:20 marvin kernel: [13483.239360] ata2.00: disabling queued TRIM support
May  3 18:16:20 marvin kernel: [13483.241499] ata2.00: configured for UDMA/33
May  3 18:16:20 marvin kernel: [13483.241578] ata2.00: Enabling discard_zeroes_data

Zu bemerken war es wahrscheinlich nur um 18:04 und 18:16 – mehrere Sekunden zwischen link down und link up.
Mich erstaunt halt, dass dieses Kontaktproblem, wenns eins ist, so präzise alle drei Minuten kommt.

--ks

[eggy]

Um sicherzustellen, dass es nicht doch an kaputten Kabeln/Kontakten liegt, könnte man zuerst mal das DVD Laufwerk abmachen, Kabel vom DVD LW für die SSD/Platte benutzen, schauen, ob's nen anderen Platz auf dem Board gibt etc.
Regelmäßiger Abstand hört sich aber schon sehr nach nem Timeout an, nach dem irgendwas in Tiefschlaf versetzt wird. Wenns nicht das DVD LW ist, könnt man, um zu klären, dass es nicht an nem überfleissigen Powermanagement liegt, in powertop erstmal sehr konsequent auf Energieverschwendung umstellen. Später kann man's dann ja wieder zurück drehen. Im Bios kannst auch mal nachsehn, evtl sind da noch irgendwelche Energiesparsachen an.
Irgendwas an neuer Hardware dazugekommen? Auch Sachen wie USB-Leseampe oder so, alles was evtl mehr Saft zieht, als das System verkraftet?

[kreuzschnabel]

Da das Problem nach der Neuverkabelung nicht mehr auftritt, lasse ich das mal ruhen. Gegebenenfalls melde ich mich wieder

Irgendeine Kombination von Hardwareproblem und einem Systemdienst, der regelmäßig nachschaut, über das Hardwareproblem stolpert und eine vorübergehende Maßnahme ergreift, muss es aber gewesen sein. Es trat, wie gesagt, nach dem Kernelupdate (+ Reboot) wieder auf, nachdem ich es vor Wochen durch einen BIOS-Reset abstellen konnte, und war nach Auswechslung des SATA-Kabels wieder weg (erst DVD mainboardseitig ausgesteckt und nur SDD dran, Fehler weg, DVD wieder dazu, Fehler immer noch weg, eine Stunde gewartet, Fehler immer noch weg, Gehäuse zugemacht).

Das kann natürlich dran liegen, dass der neue Kernel einen Dienst wieder aktiviert hat, der vorher abgeschaltet war.

--ks

[OrangeJuice]

Du kannst dir die Smart Werte ansehen, wenn dort die CRC Errors sehr hoch sind, kann das auf ein Verbindungsproblem hindeuten. Beobachte mal, ob der Wert ansteigt.
Vielleicht kann aber auch der Brenner eine Rolle spielen. Ein DVD-Laufwerk verhinderte bei einem PC, dass höhere Energiesparzustände als C2 erreicht wurden, wobei ich so ein Problem wie du hast, nicht hatte.
In Foren kann man auch lesen, dass es möglicherweise am Netzteil liegen könnte.

Das Dateisystem, falls du ext4 verwendest, würde ich überprüfen. Ich verwende in grub "fsck.mode=force fsck.repair=yes" dafür.

Vielleicht sind noch ein paar Meldungen in den Logs die auffällig sind.

Code: Alles auswählen

journalctl -p err...alert
dmesg -x -l crit,warn,err

journalctl | grep -i 'segfault'