2

i2c-omap ドライバーの奇妙な問題に取り組んでいます。問題が他のときに発生するかどうかはわかりませんが、システムの電源を切ろうとしたときに約 5% 発生します。システムの電源オフ時に、I2C 経由で PMIC のいくつかのレジスタに書き込みます。i2c-omap.c では、呼び出しスレッドがタイムアウト値を 1 秒に設定して wait_for_completion_timeout で待機していることがわかります。そして、「完了」と呼ばれる IRQ を確認できます (「完了」の後に printk を追加しました)。ただし、「完了」が呼び出された後、wait_for_completion_timeout が返されませんでした。代わりに、戻るまでに最大 5 分かかります。また、wait_for_completion_timeout の戻り値は正であり、タイムアウトがないことを示します。そして、I2C トランザクション全体が成功しました。

その間、他のドライバーからの printk メッセージを確認できます。また、シリアル コンソールは引き続き動作します。これは Android 上にあり、「top」を使用すると、system_server が CPU の約 95% を使用していることがわかります。system_server を強制終了すると、wait_for_completion_timeout がすぐに戻る可能性があります。

だから私の質問は、カーネル「wait_for_completion_timeout」がウェイクアップしないようにするために、ユーザー空間アプリ (system_server) ができることは何ですか?

ありがとう！

4

2 に答える 2

2

wait_for_completion_timeout は、(i) 完了が発生するか、(ii) タイムアウトが期限切れになったときに、条件で待機しているスレッドが「実行可能」になることのみを保証します。
その後、そのスレッドをスケジュールし、その状態を「実行可能」から「実行中」に変更するのはスケジューラの仕事です。スレッド自体 (または完了フレームワーク) は、スレッドを実行可能にする責任はありません。これはスケジューラの仕事です。
ご指摘のとおり、system_server は CPU の 95% を消費しているため、完了スレッドをスケジュールするのが難しくなっています。これは、スレッドがスケジュールされていない理由を説明しています。

于 2012-11-22T00:26:21.647 に答える
0

まあ、私はそれをちょっと理解しました。CFSスケジューリングでは、enqueue_entityで、ある条件で「vruntime + = min_vruntime」を実行し、dequeue_entityでは、ある条件でその逆を実行します。ただし、これらは常にペアで実行されるとは限りません。したがって、不明な条件下で、min_vruntimeがかなり大きい場合、vruntimeがかなり大きくなる可能性があるため、タスクはrbtreeの右側に配置され、長時間スケジュールされません。根本的な原因からこれを修正する最善の方法がわかりません。私が行ったのはenqueue_entityのハックです。vruntime>min_vruntimeが見つかり、関数がWAKEUPに対して呼び出された場合、常にvruntime = min_vruntimeを設定するため、タスクが実行されます。 rbtreeの比較的左側に配置されます。私が使用しているカーネルのバージョンは2.6.37です。これをより良い方法で修正する方法について誰かが提案していますか？

于 2012-12-11T23:02:21.187 に答える