当“症状”（CPU 占用）和“日志”（dmesg 报错）在表面上完全一致时，如何通过深层逻辑抓出那个导致“生与死”差异的根本原因？
既然 `dmesg` 报错频率和 CPU 占用率在两台机器上几乎一样，那么“铁证”就不在报错本身，而在报错背后的“时间片特征”和“通讯成功率”。
以下是三个可以彻底区分“好坏设备”的深层逻辑证据，你可以通过以下手段去抓取“铁证”：
1. 铁证一：通讯成功率的“零与非零” (The Success Rate Gap)
`dmesg` 通常只记录 Error，不记录 Success。
OK 的设备：虽然报错很多（比如每秒 50 次），但它可能有 1% 的成功率。对于显示密码星号来说，只要 1 秒钟内有 1 次通讯成功拿到了按键状态，UI 就能刷新。
故障设备：它的成功率可能是 绝对的 0%。
如何证明：
*不要只看 `dmesg`。请查看 `/proc/tty/driver/`（如果是串口通讯）或者在驱动层加一个全局变量，统计 `total_count` 和 `success_count`。
结论：如果故障机连续 10,000 次 `ioctl` 成功率为 0，而 OK 机成功率为 0.5%，这就是硬件彻底失效的铁证。
2. 铁证二：内核态的“阻塞深度” (The D-State Evidence)
虽然 CPU 占用率都是 74%，但 CPU 在做什么完全不同。
OK 的设备：CPU 处于 User
