即使發生事件，Linux進程仍然等待事件

Question

我在幾個地方有一個非常奇怪的系統行爲，可以簡單描述：用戶或內核空間中有一個進程等待事件，儘管事件發生時，該過程不會醒來。

我下面會說明這一點，但因爲這個問題在許多不同的地方（至少4）我開始尋找一個系統問題，而不是一個地方一個類似搶佔標誌（已檢查，沒有問題）這將有所作爲。

該系統是Linux上的飛思卡爾IMX6，它是全新的，仍處於測試階段。相同的代碼在許多其他Linux系統上運行良好。

系統正在運行2個獨立的進程，一個是使用gstreamer從文件播放視頻，使用從未使用過的新圖像處理器。如果這個過程單獨運行，系統可能會運行過夜。

另一個過程是通過USB連接數字調諧器。該過程僅在設備版本處於循環狀態，再次單獨運行時可以運行整夜。

如果這兩個進程在系統上同時運行，則會在幾分鐘內卡住。如果我們改變測試參數（如週期性獲取版本時間），另一個過程將會卡住。
進程始終停留在等待事件（內核驅動程序中的wait_event_interruptible或pthread_cond_wait上的用戶空間）。事件本身發生，我有日誌可以看到。但這個過程並沒有醒悟。

試圖殺死殭屍中的進程。我設法找到了一個具有非常具體的時間問題的地方，其中檢查條件是錯誤的，如果過程在正確的地方切換，可能會導致這種卡住。它解決了一個問題，我得到了另一個具有相同特徵的問題。無論如何，發現的錯誤無法解釋爲什麼它經常發生，它可以解釋理論上的錯誤，它會在很長一段時間內停頓一次，但不是這麼快。

無論如何 - 即使問題是真實的，系統中的某些東西也會顯示得非常快。再次 - 這個代碼（除了新的顯示驅動程序外）在其他系統中工作，甚至在單獨工作時也在同一個系統上工作。這些進程是不相關的，不能彼此協作，關於它們的共同之處在於它們運行的​​機器。

它可能與系統資源有關（內存使用100M，CPU使用率爲5％），調度程序行爲或系統配置上的某些內容。任何人有想法可能會導致這些問題？

Answer 1

如果它是一個全新的Linux端口，那麼它可能實際上有一個真正的內核錯誤 - 或者是一個硬件錯誤，如果它是新硬件的話。但是，你需要非常好的證據，所以strace,ftrace，甚至可能有一些相關內核代碼的工具來向可以真正解決問題的人展示這一點 - 我在猜測，因爲你在問這個問題你的方式，你不是一個普通的內核黑客。

對不起，如果這不是你真正想要的答案。