22

dmesg shows lots of messages from 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
...

I have not seen this message before. What does it generally mean? Should I be worried?

(From my research, it is not distribution specific, but in case it is relevant, I see the messages on an EC2 instance running Ubuntu 16.04.)

Philipp Claßen
  • 4,689
  • 7
  • 29
  • 41
  • Why does an EC2 instance need a serial driver? What is connected to those serial "ports"? (Guess: Something else is causing lots of irq4 signals, and the driver gets confused. Solution: disable driver, as it's probably not needed). – dirkt Aug 22 '17 at 09:40
  • Maybe that can happen if you log in via SSH and interact with the console? – Philipp Claßen Aug 22 '17 at 10:06
  • 2
    The serial port in an EC2 instance is the EC2 "console output", dirkt. – JdeBP Aug 22 '17 at 11:30

3 Answers3

29

There is nothing wrong with your kernel or device drivers. The problem is with your machine hardware. The problem is that it is impossible hardware.

This is an error in several virtualization platforms (including at least XEN, QEMU, and VirtualBox) that has been plaguing people for at least a decade. The problem is that the UART hardware that is emulated by various brands of virtual machine behaves impossibly, sending characters at an impossibly fast line speed. To the kernel, this is indistinguishable from faulty real UART hardware that is continually raising an interrupt for an empty output buffer/full input buffer. (Such faulty real hardwares exist, and you will find embedded Linux people also discussing this problem here and there.) The kernel pushes the data out/pulls the data in, and the UART is immediately raising an interrupt saying that it is ready for more.

H. Peter Anvin provided a patch to fix QEMU in 2008. You'll need to ask Amazon when EC2 is going to catch up.

Further reading

JdeBP
  • 66,967
  • 12
  • 159
  • 343
  • 4
    A patch came out in 2008? and "You'll need to ask Amazon when EC2 is going to catch up".. I'm getting this error on Azure on an Ubuntu Server in Azure (July/18) Linux 4.15.0-1013-azure x86_64. – KevinY Jul 10 '18 at 14:12
  • Amazon is pathetic. It's 2022, and it's not patched. – xZero Aug 11 '22 at 12:19
2

Just to add a data-point in support of JdeBP: I've been seeing this in my XEN VMs, and I've only been seeing it when I run dmesg. My guess is that when I run dmesg, I'm overloading the virtual UART (and manifesting the bug described above), because dmesg is spewing a whole bunch of stuff at once. In any case, it's a non-problem for me, just a red herring.

pdelong
  • 21
  • 2
  • I can report a third OS setup: Debian Stretch Docker container in docker for Mac 18.06.1-ce-mac73 (26764) on Mac Os High Sierra 10.13.6 Coming across this post while analyzing why the container (that i use for development of a python app) gets unresponsive from time to time... – Henning Dec 29 '18 at 19:07
0

You could also have serial8250: too much work for irq4 on a phsyical system with broken UART. I am debugging an ARM chipset via UART and have already broken two UART devices in 1 week. I am using serial to USB based on the cp2102 chip.

If you are dealing with physical hardware you can test if your serial works fine by short TxD and RxD and doing a stress test. You should see the data you're sending.

codingdave
  • 101
  • 1