簡単に説明できるいくつかの場所で非常に奇妙なシステム動作があります。ユーザーまたはカーネル空間にイベントを待機するプロセスがあり、イベントが発生してもプロセスが起動しません。
これについては以下で説明しますが、問題はさまざまな場所 (少なくとも 4 つ) にあるため、ローカルの問題ではなく、システムの問題を探し始めています。違い。
システムは、真新しく、まだベータ段階にある Freescale IMX6 で動作する Linux です。同じコードは、他の多くの Linux システムでもうまく機能します。
システムは 2 つの別個のプロセスを実行しています。1 つは、使用されたことのない新しいイメージ プロセッサを使用して、ファイルから再生する gstreamer を使用してビデオを表示しています。このプロセスが単独で実行される場合、システムは一晩中実行できます。
別のプロセスは、USB 経由で接続されたデジタル チューナーで動作しています。このプロセスは、ループ内でデバイスのバージョンを取得するだけです。
これら 2 つのプロセスがシステム上で同時に実行されている場合、1 つが数分以内に停止します。テスト パラメーター (定期的なバージョン取得のタイミングなど) を変更すると、他のプロセスが停止します。
プロセスは常にイベントの待機で停止しました (wait_event_interruptibleカーネル ドライバーまたは のユーザー空間のいずれかpthread_cond_wait)。イベント自体が発生し、それを確認するためのログがあります。しかし、プロセスは起きません。
そのプロセスを強制終了しようとすると、ゾンビになります。条件チェックが誤って配置され、プロセスが適切な場所で切り替えられた場合にこの種のスタックが発生する可能性がある、非常に具体的なタイミングの問題がある場所を見つけることができました。それは 1 つの問題を解決し、同じ特性を持つ別の問題にたどり着きました。とにかく、発見されたバグは、なぜ頻繁に発生するのかを説明できませんでした。これは、多くの時間に 1 回スタックする理論上のバグを説明できますが、それほど速くはありません。
とにかく、システム内の何かが原因で、問題が実際のものであっても、これが非常に速く表示されます。繰り返しますが、このコード (新しいディスプレイ ドライバーを除く) は他のシステムで動作しており、単独で動作している場合でも同じシステムで動作しています。これらのプロセスは関連しておらず、互いに連携していません。それらの共通点は、それらが実行されているマシンです。
おそらく、システム リソース (メモリ使用量は 1G のうち 100M、CPU 使用率は 5%)、スケジューラの動作、またはシステム構成の何かと関係があります。この種の問題を引き起こす可能性のあるアイデアはありますか?