Grundlegendes zur Kernel-Meldung "serial8250: zu viel Arbeit für irq4"


16

dmesg zeigt viele Nachrichten von serial8250:

$ dmesg | grep -i serial
[    0.884481] Serial: 8250/16550 driver, 32 ports, IRQ sharing enabled
[    6.584431] systemd[1]: Created slice system-serial\x2dgetty.slice.
[633232.317222] serial8250: too much work for irq4
[633232.453355] serial8250: too much work for irq4
[633248.378343] serial8250: too much work for irq4
...

Ich habe diese Nachricht noch nicht gesehen. Was bedeutet es allgemein? Sollte ich besorgt sein?

(Nach meinen Recherchen ist es nicht verteilungsspezifisch, aber wenn es relevant ist, werden die Meldungen auf einer EC2-Instanz angezeigt, auf der Ubuntu 16.04 ausgeführt wird.)


Warum benötigt eine EC2-Instanz einen seriellen Treiber? Was ist mit diesen seriellen "Ports" verbunden? (Vermutung: Etwas anderes verursacht viele irq4-Signale und der Treiber ist verwirrt. Lösung: Deaktivieren Sie den Treiber, da er wahrscheinlich nicht benötigt wird.)
Dirkt

Vielleicht kann das passieren, wenn Sie sich über SSH anmelden und mit der Konsole interagieren?
Philipp Claßen

2
Die serielle Schnittstelle in einer EC2-Instanz ist der EC2- "Konsolenausgang", dirkt.
JdeBP

Antworten:


19

An Ihrem Kernel oder Ihren Gerätetreibern ist nichts auszusetzen. Das Problem liegt in der Hardware Ihrer Maschine. Das Problem ist, dass es keine Hardware gibt.

Dies ist ein Fehler auf mehreren Virtualisierungsplattformen (einschließlich mindestens XEN, QEMU und VirtualBox), der die Menschen seit mindestens einem Jahrzehnt plagt. Das Problem ist, dass sich die UART-Hardware, die von verschiedenen Marken virtueller Maschinen emuliert wird, unmöglich verhält und Zeichen mit einer unglaublich hohen Zeilengeschwindigkeit sendet. Für den Kernel ist dies nicht von fehlerhafter realer UART-Hardware zu unterscheiden, die kontinuierlich einen Interrupt für einen leeren Ausgabepuffer / vollen Eingabepuffer auslöst. (Es gibt solche fehlerhaften realen Hardwares, und Sie werden feststellen, dass Embedded-Linux-Leute dieses Problem auch hier und da diskutieren.) Der Kernel schiebt die Daten heraus / zieht die Daten hinein, und der UART löst sofort einen Interrupt aus, der besagt, dass er für mehr bereit ist .

H. Peter Anvin hat 2008 einen Patch zur Verfügung gestellt, um QEMU zu reparieren. Sie müssen Amazon fragen, wann EC2 aufholen wird.

Weitere Lektüre


1
Ein Patch erschien 2008? und "Sie müssen Amazon fragen, wann EC2 aufholen wird". Ich erhalte diesen Fehler unter Azure auf einem Ubuntu-Server in Azure (18. Juli) Linux 4.15.0-1013-azure x86_64.
KevinY

2

Nur um einen Datenpunkt zur Unterstützung von JdeBP hinzuzufügen : Ich habe dies auf meinen XEN-VMs gesehen, und ich habe es nur gesehen, wenn ich dmesg ausführe. Ich vermute, dass ich beim Ausführen von dmesg den virtuellen UART überlade (und den oben beschriebenen Fehler manifestiere), weil dmesg eine ganze Reihe von Dingen auf einmal ausspuckt. Auf jeden Fall ist es für mich kein Problem, nur ein roter Hering.


Ich kann ein drittes Betriebssystem-Setup melden: Debian Stretch Docker-Container in Docker für Mac 18.06.1-ce-mac73 (26764) auf Mac Os High Sierra 10.13.6 eine Python-App) reagiert von Zeit zu Zeit nicht mehr ...
Henning
Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.