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.)

  • 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, 2017 at 9:40
  • Maybe that can happen if you log in via SSH and interact with the console? Aug 22, 2017 at 10:06
  • 2
    The serial port in an EC2 instance is the EC2 "console output", dirkt.
    – JdeBP
    Aug 22, 2017 at 11:30

3 Answers 3


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

  • 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, 2018 at 14:12
  • Amazon is pathetic. It's 2022, and it's not patched.
    – xZero
    Aug 11, 2022 at 12:19

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.

  • 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, 2018 at 19:07

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.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .