ARM Linuxカーネル（msleep（））をデバッグするにはどうすればいいですか？

Question

まず、デバッグのヒントを探しています。変更する1行のコードまたは問題を解決するために設定する1つの周辺設定ビットを指摘できる人がいれば、それはすばらしいでしょう。しかし、それは私が望んでいるものではありません。私はそれをデバッグする方法をもっと探しています。

グーグル "msleepハングlinuxカーネルサイト：stackoverflow.com"は13の答えを返しますが、何も意味がないので、私は質問するのが安全だと思います。

組み込みTI AM1808 ARMプロセッサ用のARM Linuxカーネル（Sitara/DaVinci？）を再構築します。シリアル・ポートから出てくるログイン：プロンプトまでのすべてのブート・ログが表示されますが、ログインしようとすると応答がなくなり、入力したものがエコーされなくなります。

多くのデバッグの後、私はカーネルに到着し、828行目と830行目の間にデバッグコードを追加しました（カーネルバージョンは2.6.37です）。私は永遠にループのprintkを追加し、私は結果を参照してください右ライン830の前に

http://lxr.linux.no/linux+v2.6.37/init/main.c#L815

：これは「sbinに/ initを」前に、カーネルモードでこの点にあると呼ばれています。私はそれを約2時間実行させ、それは約200万に数えます。サンプル行：

dbg:init/main.c:1202: 2088430 

したがって、問題なしで6000万バイトを吐き出しました。

しかし、ループにmsleep（1000）を追加すると、msleep（）は返されません。

詳細：

： は上記永久テストループの開始時に設定され得るフラグに関する条件は、それがハングアップしたときにスケジュールを（）はもはや呼び出されることを示していないことをスケジューラにライン4073で条件付きのprintkを追加

http://lxr.linux.no/linux+v2.6.37/kernel/sched.c#L4064

の.config/'デバイスドライバ' の下の唯一の選択肢は以下のとおりです。 ブロックデバイス I2Cサポート SPIサポート

カーネルとRAMディスクはloadeですd uboot/TFTPを使用します。 私はそれがイーサネットを使用しようとしているとは思わない。 これらはすべて '/ sbin/init'の前に起こったので、ほとんど起こってはいけません。

詳細： 私は同じCPUを持つ非常に似たボードを持っています。私は同じuImageと同じramdiskを実行することができ、そこではうまく動作します。私はログインして通常のことをすることができます。

私はメモリテストを実行しました（合計64MB、カーネルを32Mに制限し、もう1つの32Mをテストしています;これはシングルチップDDR2です）、問題は見つかりませんでした。 1つのボードがUART0ともう1つのUART2を使用しますが、ブートログが両方から出てくるので、問題ではありません。

どのようなデバッグのヒントもありがとうございます。 私は適切なJTAGを持っていないので使えません。

Answer 1

msleepが返されない場合、またはscheduleになっていない場合、デバッグするためにコールスタックに従うことができます。それがチェックする一つのことがあるので、

msleepは、デフォルトの場合には、それに渡された単位jiffiesタイムアウトが< 0であれば、スケジュールを呼び出すことなく終了しschedule_timeout(timeout)を呼び出すschedule_timeout_uninterruptible(timeout)を呼び出します。

timeoutが肯定の場合は、scheduleを呼び出す前にsetup_timer_on_stack(&timer, process_timeout, (unsigned long)current);が呼び出され、次に__mod_timer(&timer, expire, false, TIMER_NOT_PINNED);が呼び出されます。

scheduleに達していない場合は、setup_timer_on_stackまたは__mod_timerのいずれかで何かが発生している必要があります。 setup_timer_on_stackため

calltraceはCONFIG_DEBUG_OBJECTS_TIMERS場合は、外部のいずれかであるinit_timer_on_stack_keyを呼び出しsetup_timer_on_stackコールsetup_timer_on_stack_keyで有効または__init_timer(timer, name, key)続い debug_initを呼び出しinit_timer_key(timer, name, key);を呼び出しています。

__mod_timer最初にtimer_stats_timer_set_start_info(timer);を呼び出し、他の関数呼び出しを大量に呼び出します。

setup_timer_on_stackコールのいずれかの側か__mod_timerコールのいずれかの側にprintkまたは2を入れておくことをお勧めします。

Answer 2

この問題は解決されました。

prinkを自由に使用すると、schedule（）は実際にアイドルタスクである別のタスクに切り替わると判断されました。この例では、組み込みLinuxであり、インストールされたアイドルタスクからコピーした元のコードベースです。そのアイドルタスクは私のボードには適していないと思われ、CPUをロックしてクラッシュを引き起こしました。アイドルタスク問題の周り

http://lxr.linux.no/linux+v2.6.37/arch/arm/mach-davinci/cpuidle.c#L93

作品への呼び出しをコメントアウト。