Prozessor meldet einen Machine-Check-Hardwarefehler · Linux Fix Lab

Symptome und Geltungsbereich

Der Kernel protokolliert mce- oder Hardware-Error-Daten.
Eine Arbeitslast kann abstürzen, der Rechner neu starten oder nur Zähler korrigierter Fehler können steigen.

Betroffene Umgebung

x86-Systeme mit Machine Check Architecture und optionaler rasdaemon-/EDAC-Erfassung; Umfang hängt von Hardware und Firmware ab.

Erkennbare Meldungen (synthetische Beispiele)

mce: [Hardware Error]: Machine check events logged

Detaillierte Bank-/Statusdaten und Korrekturstatus einholen; die Zusammenfassung identifiziert kein austauschbares Bauteil.

Mögliche Ursachen

Das sind mögliche Erklärungen, keine bestätigte Diagnose. Mehrere unabhängige Fehler können gleichzeitig vorliegen.

CPU-, Speicher-, Verbindungs- oder Plattformfehler können über MCA gemeldet werden.
Übertaktung, Undervolting und Firmware-Errata können beitragen; eine MCA-Banknummer ist nicht universell eine DIMM- oder Kernnummer.

Sicher prüfen

Führe jeweils einen Befehl in der passenden Sitzung aus. Lies zuerst die Erklärung. Großgeschriebene Platzhalter brauchen deine Werte; Werkzeuge und Rechte unterscheiden sich je nach Distribution. Die Website zeigt Befehle an und führt sie niemals aus.

Prüfschritt 1

Hardware-Fehlermeldungen dieses Starts lesen oder -b -1 für einen gespeicherten vorherigen Start nutzen. Administratorzugriff kann nötig sein.

journalctl -b -k --no-pager --grep='mce:|Hardware Error|EDAC'

Ergebnis einordnen: Status, Bank, CPU-Familie und Kennzeichnung korrigiert/unkorrigiert sichern. Eine Zusammenfassung events logged braucht Detaildaten statt sofortigen Teiletausch.

Prüfschritt 2

Bei bereits eingerichteter rasdaemon-Aufzeichnung liest dies gespeicherte Ereignisse; der Datenbankzugriff kann Administratorrechte benötigen. Diese Syntax dokumentieren etwa Pakete aus Debian trixie; neuere Upstream-Versionen verwenden ras-mc-ctl db --errors.

ras-mc-ctl --errors

Ergebnis einordnen: Wiederholt entschlüsselte Fehler derselben Komponente verdienen Herstellerprüfung. Eine leere Datenbank schließt bei fehlender oder nicht unterstützter Erfassung keine Fehler aus.

Nächste Schritte nach Befund

Dokumentierte CPU- und Speicherstandards wiederherstellen

Wurden eigene Taktraten, Speicherprofile oder Spannungen gesetzt, diese einzeln auf herstellerunterstützte Standardwerte zurückstellen und normale Arbeitslasten beobachten. Ursprüngliche Fehlerdaten für Vergleich behalten.

Vorsicht: Firmware-Einstellungen vorher dokumentieren und Verschlüsselungs-Wiederherstellungsdaten behalten. Spannung nicht erhöhen und Machine-Check-Meldungen nicht zum Verbergen abschalten.

Wiederherstellung / Rücknahme: Gesichertes Firmware-Profil nur verwenden, wenn unterstützt und nicht verdächtig; stabile Standards behalten, wenn Tuning Fehler reproduziert.

Hat dir dieser Hinweis geholfen?

Hinweis teilen #

Nach entschlüsseltem Hardware-Ereignis handeln

Kehren unkorrigierte Ereignisse bei unterstützten Standards wieder, wichtige Daten sichern und ausgewertete Fehlerdaten dem Hardware-Hersteller vorlegen. CPU-/Board-spezifische Firmware-Korrektur oder gezielte Bauteildiagnose nur anhand passender Daten und Herstelleranleitung nutzen.

Vorsicht: Korrigierte Ereignisse brauchen Verlauf und Kontext; ein unkorrigiertes Ereignis kann verlässliche Berechnung gefährden. Wiederholt ausfallenden Produktionsrechner nicht zu umfassendem Stresstest zwingen.

Wiederherstellung / Rücknahme: Herstellerunterstützte Rettungs-Firmware und ursprüngliche Konfiguration behalten; Hardware-Tausch sollte der verifizierten Diagnose folgen.