即使发生事件，Linux进程仍然等待事件

Question

我在几个地方有一个非常奇怪的系统行为，可以简单描述：用户或内核空间中有一个进程等待事件，尽管事件发生时，该过程不会醒来。

我下面会说明这一点，但因为这个问题在许多不同的地方（至少4）我开始寻找一个系统问题，而不是一个地方一个类似抢占标志（已检查，没有问题）这将有所作为。

该系统是Linux上的飞思卡尔IMX6，它是全新的，仍处于测试阶段。相同的代码在许多其他Linux系统上运行良好。

系统正在运行2个独立的进程，一个是使用gstreamer从文件播放视频，使用从未使用过的新图像处理器。如果这个过程单独运行，系统可能会运行过夜。

另一个过程是通过USB连接数字调谐器。该过程仅在设备版本处于循环状态，再次单独运行时可以运行整夜。

如果这两个进程在系统上同时运行，则会在几分钟内卡住。如果我们改变测试参数（如周期性获取版本时间），另一个过程将会卡住。
进程始终停留在等待事件（内核驱动程序中的wait_event_interruptible或pthread_cond_wait上的用户空间）。事件本身发生，我有日志可以看到。但这个过程并没有醒悟。

试图杀死僵尸中的进程。我设法找到了一个具有非常具体的时间问题的地方，其中检查条件是错误的，如果过程在正确的地方切换，可能会导致这种卡住。它解决了一个问题，我得到了另一个具有相同特征的问题。无论如何，发现的错误无法解释为什么它经常发生，它可以解释理论上的错误，它会在很长一段时间内停顿一次，但不是这么快。

无论如何 - 即使问题是真实的，系统中的某些东西也会显示得非常快。再次 - 这个代码（除了新的显示驱动程序外）在其他系统中工作，甚至在单独工作时也在同一个系统上工作。这些进程是不相关的，不能彼此协作，关于它们的共同之处在于它们运行的​​机器。

它可能与系统资源有关（内存使用100M，CPU使用率为5％），调度程序行为或系统配置上的某些内容。任何人有想法可能会导致这些问题？

Answer 1

如果它是一个全新的Linux端口，那么它可能实际上有一个真正的内核错误 - 或者是一个硬件错误，如果它是新硬件的话。但是，你需要非常好的证据，所以strace,ftrace，甚至可能有一些相关内核代码的工具来向可以真正解决问题的人展示这一点 - 我在猜测，因为你在问这个问题你的方式，你不是一个普通的内核黑客。

对不起，如果这不是你真正想要的答案。