Re: CASSIOPEIA report

[suz@hpc.bs1.fc.nec.co.jp (Koji Suzuki)]

鈴木(康)です。
<200005170416.NAA03736@ninja.hpc.bs1.fc.nec.co.jp>の記事において
suz@hpc.bs1.fc.nec.co.jpさんは書きました。

  | callout_xx について私が誤解していなければ(... って自信ないんですが)
  | 本質的な違いはつぎの点になると思います。
  | 
  | 	o 最低 1 回の hardclock() イベントが発生しないと実行されない。
  | 		-- 時間的に 間が空く
  | 		-- 割り込みをマスクしていると実行されない
  | 
  | ハードウェアと密接に関係したもの以外では、
  | この点が気になるケースは、ほとんどないと思います。
  | 
  | しかし、全く同じことをするわけではなく、
  | 今回はそれが引っかかるケースだと思います。

どうもこれは、間違いですね。

したい実験は、
	o 割り込み処理の中で スタンバイもしくはサスペンド命令を
	  実行して意図的にフリーズさせる。
	o 何らかの割り込みが入ればフリーズは 解除されるので、
	  割り込み処理はどうでもよい。

というものなので、(後のメールの問題がなければ)callout で十分ですね。

  | ちなみに software interrupt は、仕組み的に INTR0 と INTR1 の両方
  | で動くようです。
  | 
  | callout は、(ほとんど?)INTR1 で動くことになるので、ここで CPU を止めると
  | フリーズしそうです。
  | 
  | 作ってみた software interrupt にしても、INTR0 動くとは限らない上に
  | INTR1 の割り込み は rtc に限られるので、POWER ボタンの
  | 割り込みが受けつけられないことになりそうです。
  | 
  | このやりかたの延長でテストしたければ、INTR2 を setup してから 止めることを
  | しないといけないんでしょうね。
  | 
  | なんだか頭痛くなってきました。

こちらについてですが、実験とは関係ないレベルで問題あるんじゃないかと
いう気がしてきました。

software interrupt が、割り込み実行レベルを無視して実行されてしまうので
はないでしょうか？

たとえば、こんなことが起きるように思います。

   o INTR0 での割り込み処理(たとえば KIU の処理)が実行されているときに、
     INTR1 の割り込みが起きて hardclock() が実行される。
     ( このこと自体は  hardclock() の方が 優先度が高く問題ない。)

   o hardclock() の後 続いて softclock() も実行されてしまう。
     ( この場合、INTR0 で low level の spl制御をしていても
       無視されて 最も低いレベルのはずの割り込み処理が動いてしまう。)


このようなことが起きそうなら、softclock() 等の処理をしない というロジック
が cpu_intr() の処理に入っていないといけないと思うのですが、
どうも入っていなさそうです。

具体的にどうすればいいか提示できなくて心苦しいのですが、
INTR2 で割り込みが入ってきても、software interrupt 実行中は、
INTR1 , INTER2 の割り込みマスクを外すことができるといいとおもいます。

( 単にマスクを解除するだけではダメでちゃんと設計しないと
いけないのですが... )

--
					鈴木　康司 ＠ＮＥＣソリューションズ
					suz@hpc.bs1.fc.nec.co.jp
					TEL 042-333-6465














--
					鈴木　康司  (１ソフ四開 ＡＬｉ)
					suz@hpc.bs1.fc.nec.co.jp
					8-23-26604  ←変更になりました。