我在一些地方有一个非常奇怪的系统行为，可以简单描述：在用户或内核空间中有一个等待事件的进程，尽管事件发生，但进程不会被唤醒。 / p>
我将在下面对此进行描述，但由于问题出现在许多不同的地方（至少4个），我开始寻找系统问题，而不是像preemption flag（已经检查过，而不是问题）那样的本地问题。会有所作为。
该系统是Linux上运行的飞思卡尔IMX6，它是全新的，仍处于测试阶段。相同的代码在许多其他Linux系统上运行良好。
系统正在运行2个独立的进程，一个是使用gstreamer从文件播放显示视频，使用从未使用过的新图像处理器。如果这个过程单独运行，系统可以运行一夜。
另一个过程是使用通过USB连接的数字调谐器。该过程仅在循环中获取设备版本，再次单独运行时可以运行过夜。
如果这两个进程在系统上同时运行，则会在几分钟内停止运行。如果我们更改测试参数（如定期获取版本时间），则其他过程将被卡住
这些进程始终坚持等待事件（内核驱动程序中的wait_event_interruptible或pthread_cond_wait上的用户空间）。事件本身发生，我有日志看到。但这个过程并没有唤醒。
在Zombie中试图杀死那个进程。我设法找到一个具有非常具体的时间问题的地方，其中条件检查是错误的，如果过程在正确的位置切换，可能会导致这种卡住。它解决了一个问题，我得到了另一个具有相同特征的问题。无论如何，发现的错误无法解释为什么它经常发生，它可以解释在很多时候会卡住一次的理论错误，但不是这么快。
无论如何 - 即使问题是真的，系统中的某些东西也会导致它显示得非常快。再次 - 这个代码（除了新的显示驱动程序）在其他系统中工作，甚至在单独工作时在同一系统上工作。这些过程没有关联，也没有相互合作，关于它们的共同点是它们正在运行的机器。
它可能与系统资源有关（内存使用1G中的100M，CPU使用率为5％），调度程序行为或系统配置上的某些内容。任何人都有可能导致这类问题的想法吗？
答案 0 :(得分：0)
如果它是Linux的一个全新的端口，那么它可能实际上有一个真正的内核错误 - 或者如果它是新硬件则是硬件错误。
但是，你需要非常好的证据，所以strace，ftrace甚至可能是相关内核代码的一些工具向可以解决问题的人展示 - 我猜因为你以你的方式提出这个问题，所以你不是常规的内核黑客。
很抱歉，如果这不是你想要的答案。