2009-04-12
-
L4_Mutexが失敗する。
2009-04-11
-
割り込みを有功にした。
-
SH7780では割り込みのマスクを解除するだけでなく、割り込みの優先度を２以上にしなければならなかった。
-
-
Pckは５０MHz。ティックは１０ms。Pck/4のタイマーで１０msを測るには？
-
TMUの割り込み要因がクリアされていない。
-
TMU_TCRのUNFをクリアしなければならない。
-
-
キャッシュをフラッシュする区間を割り込み禁止にしていたのだが、これはその区間外が割り込み許可であることが前提。ところが、実際には、まわりの区間は 割り込み許可である。キャッシュをフラッシュした後も割り込み禁止でなければならないのだが、割り込みを許可してしまっていた。
-
カーネルモードでの割り込みの処理に間違いがあった。
-
以上、Rev.125
-
結果、KTESTが最後まで走るようになった！
2009-04-10
-
CACHE0600で落ちる。
-
キャッシュをフラッシュする際にアドレスが有効かどうか調べる機能をONにする。
-
-
CACHE0600の状況を修正する過程でページフォルトが処理されない問題が発生。
-
UTCB参照アドレスのキャッシュが更新されていない。
-
（ワークアラウンド）UTCB参照アドレスのUTLBエントリをライトスルーにすることでなんとなく動いているが…Rev.120 -
大量に出ていたinvalid page faultも嘘のように消えてしまった。
-
UTCB参照アドレスをキャッシング不可にした。
-
-
-
TODO UTCB参照ページをキャッシュするかどうかについては、調査が必要。
-
L4_NotifyがエラーでかえってくるIPC3400
-
システムコールを修正。Rev.121
-
-
KMEM02でUTCBの上限値を設定。Rev.122
-
L4_Yieldでブロックする。
-
どうやらタイマーが有功になっていないみたいだ。
-
2009-04-09
-
IPCがうまく行っていない。
-
スレッド1がスレッド2を生成し、スレッド2にBlock Sendする。スレッド2はまだ走っていないので、このBlock Sendは一旦スケジューリングキューに登録される。スレッド2はページャと通信し、メモリページを取得する。スレッド2はスレッド1からのメッセージを 受信する。
-
最後のスレッド2がスレッド1からのメッセージを受信するところが、受信されていない。
-
スレッド1からスレッド2へのIPCはコンティニュエーションを使って復帰される。(restart_ipc)
-
restart_ipcはSYS_IPC_RESTART（アーキテクチャ依存コード）を呼び出す。SYS_IPC_RESTARTはcall_with_asm_continuation（アーキテクチャ依存コード）を呼び出す。
-
call_with_asm_continuationが正しく状態を復帰していなかった。
-
この関数を実装した当初は、continuationを呼び出すものだと思っていたので、continuationにジャンプしていたが、これは間違い。
-
正しくは、continuationをPRレジスタに格納し、functionを呼び出さなければならない。Rev.116
-
-
-
新しくアドレス空間を生成した時にkmem_resourceが確保されていないようだ。
-
kmem_resourceはどのタイミングで確保されるのか？
-
この場合には、そもそもkmem_resourceを使ってはいけない。kmem_resourceはUTCB参照ページを参照するページテーブルエント リの確保に使われている。つまり、このページテーブルエントリを作成するのが間違いということになる。幸いなことに、UTCB参照ページを共有ページにす ればページテーブルエントリの確保は必要なくなる。ただし、以下の条件を満たす必要がある。
-
UTCB参照ページはTLBから追い出されない。
-
UTCB参照ページのエントリはTLBの中で最大一つ。
-
-
直した。Rev.119
-
-
キャッシュテストで落ちる。
2009-04-08
-
ページフォルト（TLB例外）後、ページフォルトハンドラが例外アドレスをマッピングする。この操作はアドレスをページテーブルに登録するだけで、TLB に登録するわけではない。したがって、ページフォルトを発生したスレッドに一旦処理は戻り、再び、TLB例外を発生させ、TLBをフィルするという流れに なっていた。
-
ページテーブル登録後にTLBをフィルするように変更。Rev.113
-
-
（ワークアラウンド） ipc_handler内でTLBにないUTCBアドレスにアクセスする可能性がある。UTCBアドレスはP0領域の仮想アドレスなのでTLB例外を発生 させる。現在の実装では、ipc_handlerは割り込み禁止区間に設定されている。そのため、TLBにないUTCBアドレスにアクセスすると処理が進 まなくなり、クラッシュする。
-
（方法１）割り込み禁止区間を撤廃する
-
TLB例外以外の優先度の高い例外や割り込みが発生する可能性がある。
-
データTLB例外の優先順位は6番め。
-
-
-
（方法２）物理アドレスでUTCBにアクセスする。
-
TCB経由でUTCBの物理アドレスを得られる。
-
-
とりあえず方法1を試す。動作はするが、最終的にはエラーが出てKDBに落ちる。
-
kernel access raised user page fault (space.cc l212)
-
-
ここから得られる結論は、そもそもカーネルモードでUTCBに対するTLB例外を発生させてはならないということである。
-
方法2でうまくいった。
-
2009-04-07
-
ページテーブルエントリが思ったように更新されていない。
-
ページテーブルエントリのバグ（pgent_t::clear）
-
-
get_current_kmem_resourceが失敗する。アサーションに引っかかる line 149 @ kmem_resource.cc。
-
generic_space_t::activate内でUTCB参照ページのマッピングを常に新しく作成していたため、メモリリークしていた。
-
-
ipc_syscall_return内でUTCBにアクセスするとき、ページフォルトが発生する場合がある。この場合に対処していなかったため、クラッシュしていた。
2009-04-06
-
（ワークアラウンド） データキャッシュにもTLBにも存在しないエントリをライトバック（OCBP）しようとして、クラッシュしている。Rev.108
-
ページテーブルに登録されているが、TLBに登録されていない場合には次の二つが考えられる。
-
マッピングしたがそのアドレスにアクセスしていない。
-
マッピング後アクセスし一旦はTLBに登録されたが、追い出された。
-
-
2.の場合はデータはキャッシュされるのでOCBP命令は成功する。
-
2009-04-02
-
ktestがアボートされる。
-
irqのリストが取れないのが原因。ElfWeaverがNO_DEVICE_IRQ_LISTという構造体をアロケーションするのだが、どのような仕組みでアロケーションするのかよくわからない。
-
とりあえずアサーションを無視。
-
-
ThreadControlでアサーションに引っかかる。
-
システムコールの引数の処理の間違いだった。
-
-
IPCでデッドロック
-
IPCの受信時に送信元を正しく返していなかった。Rev.101
-
-
KDBのスタック管理にバグがあった。修正。Rev.99
-
KDB呼び出しのレジスタ管理にバグがあった。修正。Rev.100
-
IPCのメッセージが配送されない。
-
KDB呼び出しがレジスタを破壊していた。Rev.105
-
2009-04-01
-
IPCがおかしい。ブロックしない。
-
UTCBをカーネルが読み取れていない。L4_WaitはフラグをセットしL4_Ipcを呼び出す。このフラグがセットされることでIPCはブロックする 仕組みになっている。このフラグはMsgTagにセットされ、UTCBに保存される。カーネルはUTCBからこのフラグを読み出す。カーネルがブロックし ないということは、このフラグを正しく読み出せていないことを意味する。
-
IPCの実装が未完成だった。Rev.93
-
-
UTCBでTLB多重ヒット例外が出る。
-
generic_space_t::activate内
-
UTCBを参照するためのページは共有ページに設定されていたのだが、この設定ではASIDが比較されない。結果としてTLB多重ヒット例外を発生させていた。Rev.95
-
メモ：UTCB参照ページは共有にすることでUTLBを節約できる。
-
