2 Answers
2

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.

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.
– KevinYJul 10 '18 at 14:12

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...
– HenningDec 29 '18 at 19:07