1996年8月23日(金)

「ｐｓコマンド・トラブル」

mpx.sへのパッチ後しばらくして、psコマンドの出力がめちゃくちゃな事に気付く(^^;。

あれー、確かps.cもコンパイルし直したし問題い無いはずやのに(-"-;。

(と、思い込んでいた...)。そこで無謀にもmpx.s(あせんぶら!!)を眺めたり、ps.cを読んだりしたのだが解決しない...。そうだ、こんな時こそ...

fj.os.minix頼みだっ!!

んで、数日様子見してたが色良いフォローはなかなか付かない(--;。やっぱり自力でなんとかせないかんかぁ...。

そこでふと思う。

ほんまにps.cコンパイルし直すだけでええんか？

確か、「MINIXを256倍使うための本」にはそう書いてあったような気が(ゴソゴソ)...あったあった...ふーむ...なになに...えーっ！。

まあ...そのー。結論から言うと

ps -U

をカーネル再作成後に実行する必要があるそうですf(^^;(P.232参照)。 (/etc/psdatabaseちゅうファイルを更新するらしい)それと、デバドラの数が変わった時等はps.cのリコンパイルがいるそうで、私はそこだけを覚えてたようですm(__;m。

とりあえず今後の事を考えて、/etc/rcに以下のように追加する。

# update /etc/psdatabase for ps command
echo update /etc/psdatabase;/usr/bin/ps -U > /dev/null

これで一安心v(^^)。

その後、mpx-patch作者の鈴木克宗＠電通大さんからfj.os.minixの方に同様の内容のフォローを頂きました。多謝m(__)m＞鈴木克宗＠電通大さん。

「TZについて」

みなさんは環境変数TZをどのように設定してますか？。うちの環境では当初、

TZ=JST+9

と設定して正しい時刻を刻んでました。まあそんなもんか...という事であまり気に止めてなかったんですが、256本によると本来は

TZ=JST-9

と設定した時に(日本国内においては)正しい時刻を示すべきものらしいのです (--;。

256本によりますと、かのPC-98版MINIXにおいては、このあたりの事情を考慮してカーネル(kernel/clock.c)に手心を加えてあるらしいのですが、 Minix/X68kにおいては特に考慮されてない...というか、本来UNIXマシンの有るべき姿のままなので上記のような状態になるようです。

結局Minix/X68k上で正しい時刻を刻むには

マシン日付を国内時間に合わせ、TZ=JST+9とする。
マシン日付を国内時間に合わせ、TZ=　　　(未設定)とする。
マシン日付をグリニッジ標準時に合わせ、TZ=JST-9とする。

の３パターンが考えられますが、まあ、2.あたりがHuman, OS-9 等と併用してる人には都合が良いかも知れません。

んが、私は本来有るべき姿にこだわってみて、3.の方法を取る事にしました。どうせMinix以外を立ち上げる時ってゲームする時ぐらいやし、この方がなんとなくカッコイイし(^^;。

「x6scsiパッチ」

ここ何日かGNU物の移植(後述)をしてるが、

謎なコンパイルエラー - > Minix再起動 - > fsck実行 - > ファイルシステム修復＆ファイル消失 - > ソースインストール - > 謎なコンパイルエラー

の堂々めぐりにはまりこんで、なかなか前進しない(--;。そんなおりついに、

File system panic ...

発生...(T_T)。 mpx-patch を施して以来、カーネルパニックは起こしてなかったのでかなりショック... (-_-;。うーん、なんとかせねば。

とは言うものの、SCSIのデバイスドライバに問題が有るんやろなーとおぼろげに思いながらも、デバドラなんて

雲上人のなせるワザ

とりあえず他力本願で、fj.os.minixの過去の記事を漁って見る。その結果

Message-ID: < JACK.96Jan18233129@mars.st.rim.or.jp >
Message-ID: < JACK.96Jan21020758@mars.st.rim.or.jp >

の記事において、jack(青山)さんが/usr/src/kernel/x6inscsi.cに対する不具合の修正情報を報告されている事を発見!。ただ、残念な事に現在のSCSIドライバは/usr/src/kernel/x6scsi.c に統合されているので記事の中に有るパッチをそのまま施す事が出来ない...。

と思ったが、両者(x6inscsi.c,x6scsi.c)のソースは非常に似通った物のようで、これなら手修正で何とかなりそうv(^^)。

で、ほぼ機械的に同様の修正をx6scsi.cに施して見る。あくまで＊機械的に＊であって修正の＊意味＊をさほど理解してないところがなんともデンジャラス(^^;;。

でもって、カーネルをサクッと構築し直して移植途中のGNU物のコンパイルを再開する。

...とりあえずパニックは起こさない。が、頻度はかなり減ったものfsckがファイルシステムの修復を報告する事が有る(特にGCCバスエラー停止後のマシン再起動時)。

やはり機械的に修正するだけではだめなのか、それとも修正の仕方が間違ってるのか？。うーん、やっぱり修正の＊内容＊が少しは分かってないとこれ以上はどうしようもなさそうな気配(--;。その時、１冊の本が本棚から私に呼びかけたような気がした(ア、アブナイ)。

「Inside X68000」

その昔、見栄で買ったもののほとんど開ける事無く本棚の肥やしと成っていた本だ...。どれどれ...、おっSCSIの扱いについて結構ページを割いて説明してるのね(^^;。し、しかし殆んど理解できない私(;_;)。

とは言いながら、jack(青木)さんの修正が基本的には各種SCSIコマンド発行後のステータスチェックの強化らしい事がおぼろげながら判った(ような気がする)。

そして、サンプルプログラム(P.514)の中に有って、x6scsi.cに無いステータスチェック(RESET ACKコマンド発行後にACK信号が確実にRESETされる事の監視。と私は理解したf(^^;)のコーディングを見つけ、なんの根拠も無いまま x6scsi.cにも同様のチェック処理を付け加えてみた。

結果は...。現在経観察中なるも、おおむね良好そう(^^)。

そんなわけで、命知らずな方又は正しいアドバイスをくださる方にこちらの x6scsiパッチはいかがでしょう？。