☰

进一步阅读

tag-icon • tag-icon kernel dmesg
进一步阅读

dmesg显示来自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
...

我以前没有看到过这条消息。一般是什么意思？我应该担心吗？

（根据我的研究，它不是特定于发行版的，但如果相关，我会在运行 Ubuntu 16.04 的 EC2 实例上看到消息。）

答案1

您的内核或设备驱动程序没有任何问题。问题出在您的机器硬件上。问题是硬件不可能。

这是几个虚拟化平台（至少包括 XEN、QEMU 和 VirtualBox）中的错误，已经困扰人们至少十年了。问题在于，各种品牌的虚拟机模拟的 UART 硬件表现不佳，以快得令人难以置信的线速度发送字符。对于内核来说，这与错误是没有区别的真实的UART 硬件持续为空输出缓冲区/满输入缓冲区引发中断。 （这种有缺陷的真实硬件是存在的，你会发现嵌入式 Linux 的人们也在到处讨论这个问题。）内核将数据推出/拉入，UART 立即引发一个中断，表示它已准备好进行更多操作。 。

H. Peter Anvin 在 2008 年提供了修复 QEMU 的补丁。您需要询问 Amazon EC2 何时能赶上。

进一步阅读

答案2

只是添加一个数据点来支持杰德BP：我在我的 XEN VM 中看到了这一点，并且仅在运行 dmesg 时才看到它。我的猜测是，当我运行 dmesg 时，我会过载虚拟 UART（并显示上述错误），因为 dmesg 会立即吐出一大堆东西。无论如何，这对我来说不是问题，只是转移注意力。

答案3

您也可能使用serial8250: too much work for irq4一个 UART 损坏的物理系统。我正在通过 UART 调试 ARM 芯片组，并且已经在 1 周内损坏了两个 UART 设备。我使用的是基于cp2102芯片的串口转USB。

如果您正在处理物理硬件，您可以通过短 TxD 和 RxD 并进行压力测试来测试您的串行是否正常工作。您应该看到您正在发送的数据。

相关内容