übermäßiges Drucken des Kernelprotokolls bnx2x: [bnx2x_get_regs: 987 (eth2)] Generieren des Registerdumps. Könnte harmlose GRC-Timeouts auslösen

462
arifisik

Mein Server druckt das Protokoll über "bnx2x: [bnx2x_get_regs: 987 (eth *)]] Erstellen eines Registerdumps. Kann stündlich harmlose GRC-Timeouts auslösen". Es hat heute begonnen und druckt das Protokoll jede Stunde weiter. Warum druckt der Kernel dieses Protokoll stündlich und wie kann ich die Ursache finden?

Anmerkung: Ich habe sosreport und ethtool -d nicht ausgeführt

0
Ich habe diesen Sosreport gefunden, der von abrtd erstellt wurde. Aber ich verstehe nicht, was die "abrtd" geändert hat. Normalerweise wird kein neues Verzeichnis erstellt, und sosreport schreibt nur die Datei "last_occurrence" in das Verzeichnis / var / spool / abrt / pyhook. Wie stoppe ich den generierten Sosreport jedes Mal? arifisik vor 5 Jahren 0
Dies ist die Protokolldatei: abrt-server [61601]: Gespeicherter Python-Absturzabbild von pid 61598 in / var / spool / abrt / pyhook-2018-05-19-01: 41: 46-61598 abrtd: DUP_OF_DIR: / var / spool / abrt / pyhook-2018-04-02-10: 41: 45-8931 abrt-server [22654]: Gespeicherter Python-Absturzspeicherauszug von pid 22651 in / var / spool / abrt / pyhook-2018-05-19-02 : 41: 46-22651 abrtd: Neues Problemverzeichnis / var / spool / abrt / pyhook-2018-05-19-02: 41: 46-22651 wird verarbeitet arifisik vor 5 Jahren 0

1 Antwort auf die Frage

0
arifisik

Die Dump-Datei wurde von einem anderen Prozess erstellt und löscht daher alle Dump-Dateien über etc / abrt / abrt.conf.So. Meine Python-Absturz-Dump-Datei wurde gelöscht und nach jeder Wiederholung vom Arbtd neu erstellt, und jedes Mal wird ein SOS-Bericht erstellt.

Verwandte Probleme