Understanding "serial8250: too much work for irq4" kernel message

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

Asked By: Philipp Claßen


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

Answered By: JdeBP

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.

Answered By: pdelong

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.

Answered By: codingdave
Categories: Answers Tags: ,
Answers are sorted by their score. The answer accepted by the question owner as the best is marked with
at the top-right corner.