Apr 5, 1999 frc7v-cl1: Server Solaris 2.6、cc ドライバのテスト --- クライアントシステム上での cc ドライバのデバッグ#01(その18） ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ (http://www-online.kek.jp/~inoue/CAMAC/onl8v1-sol2.6-serv/ Cli1-CAMAC/debug-step18.txt) 高エネルギー加速器研究機構 素粒子原子核研究所 物理、オンライングループ 井上 栄二 (1). 現状確認 (A). 株式会社ロジックハウスの白田様より SPARC CPU-8VT と、VMEドライバ v2.3.1 を借用した。 (B). 株式会社ロジックハウスの白田様より Server Solaris 2.6 のシステム がインストールされているハードディスクを借用した。 (C). 借用したハードディスクのサーバ側のシステム設定を変更して、KEK の FP クラスタ上で立ち上げた。 (D). ファイルを直接修正する方法で、クライアント(その１)側のシステム 設定を変更したがクライアントは立ち上がれなかった。 (E). Solsticeを起動してホストマネージャを使って、frc7v-cl1ディスクレス クライアントの設定をやり直した。 (F). ディスクレス・クライアントのシステム、frc7v-cl1 が起動できること を確認した。 (G). frc7v-cl1 のシステムにVMEドライバ、FRCvme-2.3.1 をインストールし、 その後、frc7v-cl1 のシステム設定をやり直した。 (H). Solsticeを起動してホストマネージャを使って、frc7v-cl2ディスクレス クライアントの設定をやり直した。 (I). ディスクレス・クライアントのシステム、frc7v-cl2 が起動できること を確認した。 (J). frc7v-cl1、クライアントのシステムに ccドライバをインストールした。 (K). frc7v-cl1、クライアントのシステム上でサンプル・プログラムを実行 シングルアクションの 24ビットread/write は ok. LAM割り込み処理は、ok. ブロック転送 read/write は NG. (L). CPU-7Vのボードで FRCvme2.3.1 が正しく動作できることを確認した。 (M). frc8vt、サーバ・システムに ccドライバをインストールした。 (N). frc8vt、サーバ・システム上でンプル・プログラムを実行 シングルアクションの 24ビットread/write は ok. LAM割り込み処理は、ok. ブロック転送 read/write は 16 および 24ビットとも、ok. (O). 株式会社ロジックハウスの高橋様の修正された ccドライバを実行したが 状況に変化はなかった。 (P). 株式会社ロジックハウスの白田様の提案より、デスクレス・クライアント のシステムにローカル・ディスクをつなぎ、マウントした後で ccドライバ を実行したが状況に変化はなかった。 (Q). cam2 プログラムを実行すると、 cc.cプログラム中のどの命令を実行 した時にパニックを起こすのか調べた。 (R). 株式会社ロジックハウスの高橋様の提案より、savecore について調べる。 savecoreコマンドにより、vmcore.x および unix.x ファイルを入手した。 (S). ドライバ・プログラムが DMA完了の待ち状態のままになっているのを 確認 (T). cam2プログラムを frc8vt、frc7v-cl1上で実行して結果を調べた。 　　　frc8vt上での実行: (1). cv_wait_sig()コールが入っていると、そこで待ち状態が続く。 (2). cv_wait_sig()コールが入っていないと、正常終了する。 　　　frc7v-cl1上での実行: (1). cv_wait_sig()コールが入っていると、そこで待ち状態が続く。 (U). cv_wait_sig() を while文でループさせることで、シグナルを受け取れた (V). DMA 開始前に以前の割り込み信号が残って影響を与えていないことを 確認した。 (W). バーチャル・アドレス・スペースの割り当てを追加して動作させてみたが 症状は変わらない。 (X). cc->bp へのアクセスを camac_b()ルーチンでやらないようにしてみたが 症状は変わらない。 (Y). Soft State Managementルーチンを使ってみたが症状は変わらない。 (Z). minphys のバッファサイズを大きくして試してみたが症状は変わらない。 (2-A). camac_b（）を呼び出す箇所で渡す値をチェックしたが症状は変わらない。 (2-B). クラッシュダンプのチェック。 physio()でエラー。 (2-C). cc_strategy()ルーチンをチェック。 physio()でエラー。 (2-D). cc_strategy()ルーチンのcv_wait() を mutexロックした。変化なし。 (2). ここでやるべきこと クラッシュダンプのチェック(その4)。 (3). クラッシュダンプのチェック(その4) (3-1). crashプログラムによるチェック Solaris には crashプログラムというプログラムがある。 これは生きている システムと検死ファイルの両方でメモリを調査するプログラムである。 frc7v-cl1 システムのクラッシュ・ファイルをチェックしてみる。 frc7v-cl1[60]% crash -d vmcore.42 -n unix.42 dumpfile = vmcore.42, namelist = unix.42, outfile = stdout > ? as kmausers prnode strstat b (buffer) l (lck) proc t (trace) base lck pty trace buf (bufhdr) linkblk q (quit) thread buffer lwp qrun ts bufhdr m (vfs) queue tsdptbl c (callout) major quit tsproc callout map rd (od) tty class mblk redirect u (user) cpu mblkusers rtdptbl user defproc mode rtproc ui (uinode) defthread mount (vfs) rwlock uinode dispq mutex s (stack) v (var) ds mutextable search var f (file) nfs (nfsnode) sema vfs file nfsnode size vfssw findaddr nm snode vnode findslot od socket vtop fs (vfssw) p (proc) soconfig ? help page stack !cmd kfp pcb status kmastat pcfsnode stream > help p p [-e] [-f] [-l] [-w filename] [([-p] [-a] tbl_entry | #procid)... | -r] tbl_entry = slot number | address | symbol | expression | range process table alias: proc acceptable aliases are uniquely identifiable initial substrings > p -e PROC TABLE SIZE = 1002 SLOT ST PID PPID PGID SID UID PRI NAME FLAGS 0 t 0 0 0 0 0 96 sched load sys lock 1 s 1 0 0 0 0 58 init load 2 s 2 0 0 0 0 98 pageout load sys lock nowait 3 s 3 0 0 0 0 60 fsflush load sys lock nowait 4 s 313 1 313 313 0 58 sac load jctl 5 s 233 1 233 233 0 58 sendmail load jctl 6 s 175 1 175 175 0 58 automountd load 7 s 150 1 150 150 0 58 inetd load 8 s 122 1 122 122 0 58 rpcbind load 9 s 124 1 124 124 0 41 keyserv load 10 s 179 1 179 179 0 35 syslogd load 11 s 155 1 155 155 0 52 statd load 12 s 157 1 157 157 0 52 lockd load 13 s 354 352 354 354 1002 58 csh load jctl 14 s 255 1 255 255 0 52 vold load jctl 15 s 336 150 336 336 0 18 in.rlogind load 16 s 199 1 199 199 0 52 nscd load 17 s 191 1 191 191 0 58 cron load 18 s 209 1 209 209 0 52 lpsched load nowait 19 s 230 1 230 230 0 20 powerd load 20 s 243 1 243 243 0 58 utmpd load 21 s 260 1 0 0 0 27 dpkeyserv load 22 s 264 1 0 0 0 11 jserver load 23 s 265 264 0 0 0 53 jserver_m load 24 s 314 1 314 314 0 33 ttymon load 25 s 307 1 307 307 0 43 snmpXdmid load nowait 26 s 338 336 338 338 1002 58 csh load jctl 27 s 294 1 294 294 0 58 snmpdx load nowait 28 s 317 294 317 317 0 58 mibiisa load 29 s 316 313 313 313 0 58 ttymon load jctl 30 s 299 1 299 299 0 58 dtlogin load 31 s 352 150 352 352 0 41 in.rlogind load 32 s 306 1 306 306 0 53 dmispd load 33 s 513 150 513 513 0 8 in.rlogind load 34 s 554 515 554 515 0 45 sh load 35 s 515 513 515 515 1002 58 csh load jctl 36 s 555 554 555 515 0 58 csh load jctl 37 p 592 338 592 338 1002 58 cam2 load > crashプログラムによるチェックは一時中断する。 (3-2). adb によるチェック frc7v-cl1[43]% adb -k unix.42 vmcore.42 physmem 3e2d $c complete_panic(0x0,0x4401ce7,0x0,0x44010e7,0x0,0xf5ae8f40) + 5c do_panic(0x1,0xfbfe978c,0x0,0x48010e7,0x8,0xf00) + a8 vcmn_err(0x3,0xf0269878,0xfbfe978c,0x3,0xffeec000,0x0) + 180 cmn_err(0x3,0xf0269878,0xfbfea,0x53,0x53,0xf025e400) + 1c die(0x9,0xfbfe98dc,0xf5b37f5c,0x326,0x1,0xf0269878) + bc trap(0x0,0xfbfe98dc,0xf0000000,0x0,0x6,0x1) + 930 fault(?) + 84 physio(0x0,0xf028c49c,0xa,0x40,0xf5914420,0xfbfe9ad8) camac_b(0x0,0x2a,0x600,0xfbfe9ad8,0xf00000,0xf5bf1dc8) + 1e8 cc_write(0xf00000,0x5,0x600,0x2a,0xfbfe9b08,0xf5bf1dc8) + 434 writev(0xf5b1ab30) + 2b0 $