(toppers-users 886) Re: SH3 dispatcher バグ？

[Honda Hiroki]

アイピーフレックス株式会社の本田です。

> ここは、カーネル内部処理用の　lock_cpu() ですね。

そうです。

> >   (8) 割り込みハンドラからリターンし、割り込み前の処理の
> >       続きを行うべく、sleep 命令のところに戻った。
> 
> 何故、ここに戻るのでしょうか？

過去ログで何度か話題になったように、sleep の際には「割り込みネストカウ
ント」ワーク (r7_bank レジスタ) を 1 にしてますので、受け付けた割り込
みはあたかも多重割り込み (_interrupt_from_int) であるかのように扱われ
て、素直に rte するフローになります。

現状の dispatcher が意図している通常ケースを考えればわかりやすいと思い
ます。

JSP カーネルが loc_cpu() してから (3)(4) を処理しているわずかな期間を
狙いすまして外部割り込みが発生する、というのはレアケースであり、たいて
いはもっとあとで割り込みが発生するでしょう。そういう通常ケースでは、

  (4) dispatcher は「schedtsk == NULL だから sleep しよう」
      と判断し、dispatcher_2 に飛んだ。
  (5') dispatcher_2 が ldc r9,sr して sleep した。
  (6') 外部割り込みが発生し、割り込みハンドラに制御が移った。
       [戻り先 PC = ldc r8,sr]
  (7') 割り込みハンドラが iwup_tsk() だか isig_sem() だかを
       呼んで、どこかのタスクを起こした。
  (8') 割り込みハンドラからリターンし、割り込み前の処理の
       続きを行うべく、ldc r8,sr 命令のところに戻った。
  (9') ldc r8,sr 命令を実行した後、reqflg を調べ、FALSE では
       ないので r7_bank1 をクリアして reqflg を FALSE にして
       dispatcher に飛ぶ。
  (10') dispatcher は「shedtsk != NULL だからそのタスクを
        実行しよう」と判断し…以下略。

となります。これは意図通りの正しい挙動です。

それに対して、「狙いすまして割り込み発生」という悪運ケースでは、前回
のメールのような不当 sleep に陥るのではないか、ということです。

====
アイピーフレックス株式会社
R&D センター
本田広樹 (hhonda ＠ ipflex.com)