Comprendre le message du noyau «serial8250: trop de travail pour irq4»


17

dmesg affiche beaucoup de messages de 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
...

Je n'ai jamais vu ce message auparavant. Qu'est-ce que cela signifie généralement? Devrais-je m'inquiéter?

(D'après mes recherches, ce n'est pas spécifique à la distribution, mais si c'est pertinent, je vois les messages sur une instance EC2 exécutant Ubuntu 16.04.)


Pourquoi une instance EC2 a-t-elle besoin d'un pilote série? Qu'est-ce qui est connecté à ces "ports" série? (Devinez: Quelque chose d'autre provoque beaucoup de signaux irq4, et le pilote est confus. Solution: désactivez le pilote, car il n'est probablement pas nécessaire).
dirkt

Peut-être que cela peut se produire si vous vous connectez via SSH et interagissez avec la console?
Philipp Claßen

2
Le port série dans une instance EC2 est la "sortie console" EC2, dirkt.
JdeBP du

Réponses:


19

Il n'y a rien de mal avec vos pilotes de noyau ou de périphérique. Le problème vient du matériel de votre machine. Le problème est qu'il s'agit d'un matériel impossible.

Il s'agit d'une erreur dans plusieurs plates-formes de virtualisation (y compris au moins XEN, QEMU et VirtualBox) qui tourmentent les gens depuis au moins une décennie. Le problème est que le matériel UART qui est émulé par diverses marques de machines virtuelles se comporte de manière impossible, envoyant des caractères à une vitesse de ligne incroyablement rapide. Pour le noyau, cela ne se distingue pas du matériel UART réel défectueux qui déclenche continuellement une interruption pour un tampon de sortie vide / un tampon d'entrée complet. (De tels vrais matériels défectueux existent, et vous trouverez des personnes Linux embarquées discutant également ici et là de ce problème.) Le noyau pousse les données vers l'extérieur / les récupère, et l'UART déclenche immédiatement une interruption en disant qu'il est prêt pour plus .

H. Peter Anvin a fourni un correctif pour corriger QEMU en 2008. Vous devrez demander à Amazon quand EC2 va rattraper son retard.

Lectures complémentaires


1
Un patch est sorti en 2008? et "Vous devrez demander à Amazon quand EC2 va rattraper son retard" .. Je reçois cette erreur sur Azure sur un serveur Ubuntu dans Azure (juillet / 18) Linux 4.15.0-1013-azure x86_64.
KevinY

2

Juste pour ajouter un point de données à l'appui de JdeBP : je l'ai vu dans mes machines virtuelles XEN, et je ne l'ai vu que lorsque j'exécute dmesg. Je suppose que lorsque j'exécute dmesg, je surcharge l'UART virtuel (et manifeste le bogue décrit ci-dessus), car dmesg crache tout un tas de choses à la fois. En tout cas, ce n'est pas un problème pour moi, juste un hareng rouge.


Je peux signaler une troisième configuration de système d'exploitation: conteneur Debian Stretch Docker dans Docker pour Mac 18.06.1-ce-mac73 (26764) sur Mac Os High Sierra 10.13.6. une application python) ne répond plus de temps en temps ...
Henning
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.