[x68k/-current] 初めてユーザランドを -current にしてみた。 そいつは NFS root な x68k なので、別のマシンからも NFS しといて pax -zrpe base.tgz とかやるだけ。ちょっと反則か?。 初めて etcupdate も使ってみた。噂には聞いてたけどこれは便利。 でもこのマシンは base.tgz しか展開してないので pkgsrc を make できないから、 別の x68k で etcupdate を make package してから tgz を持ってきて pkg_add(1) する。ちょっと間抜け。 /bin と /sbin がダイナミックリンクに変わったので一悶着あるかと思ったら まったく何も起こらずにちょっとガカーリ(2ch風)。 base.tgz を展開した直後に ls とか使えたもんなあ。 せっかく毎週ビルドだけやってるので、これからも時々は -current の ユーザランドもおっかけてみよう。 って言っても起動させてるだけでやることないんだけどね。 PRO-II + Xellent30 + NFS root だと X68030 (with HDD) に比べて 2〜3倍は遅くてとてもじゃないけど使えない。

[commit] $NetBSD$ タグの後ろの $ が抜けてるために タグとして認識されてないファイルを見つけたので、commit しておく。

というのも、etcupdate 使ってる時に既にインストールされてる ファイルよりもこれからインストールしようとするファイルの方が 古いタグがついたものがあった。1.6_BETAx を 1.6K に更新しようとしてる のでタグが古くなるなんてことは普通はあり得ないのだが、うちでは 一時期変則的な cvs update をしていた時期があってその時に update した ファイルは NetBSD タグが展開されてないことが原因だった。 以前にも気付いて一掃したつもりだったが、あれは sys 以下だけだったのかも 知れない。CVS/Entries に書いてあるリビジョンと $NetBSD: ... 行の リビジョンが違ってるものを抜き出すスクリプト書いて実行してみると これが 200〜300くらいあったので、それらだけ消して cvs update し直す。 その後、もう一度チェックスクリプトを走らせてる時に見つけたってわけ。

[etc/HDD] Human68k を使わなくなってから毎冬恒例の Human68k の 500MB HDD の火入れ式をしてみる。 夏場から今日までずっと電源入れてなかったせいか、 電源入れた瞬間ちょっと鈍い音がしたが無事回った。 そろそろ定期的に通電させて回さないとグリスが固まりそう。

[x68k/bmd] とりあえず commit してみる。

[x68k/hdc] ダイナミックリンクの /bin, /sbin でも何も起こらなくて ガカーリしてたせいか、hdc の実験でふと newfs してみたら、以後すべての コマンドが segmentation fault するようになった。 早くも (早すぎ..) /rescue の恩恵を受ける羽目になる...。 スタティックリンク、マンセー。

[MI/ktrace(1)] ktrace の使いかたが分かった。 おうちではデバイスドライバばっか書いてるからあんまり恩恵を受けることは ないけど、お仕事プログラム (のテストプログラム) をなにげに NetBSD で 動かしたら動かなくて、その時使ってみた。 ちなみにこんな感じ。

% ktrace ./a.out
% kdump ktrace.out

[x68k/hdc] 以前(数カ月前)試した時は newfs、mount は出来て、 ファイルエントリがなければ ls も成功したが、ファイルを作成してその後 ディレクトリエントリをなめる操作をすると panic してた。 けど今日やってみたら出来た。 あれからこっちのソースは何も変更してないんだけどな。 そういえばちょっと前に何だったか忘れたけどファイルシステム周りの 結構クリティカルっぽいバグが修正されて、その時「これなら hdc が動くかも」と 思った記憶があるような気がするので、たぶんそのせいだと思うことにしておこう。 hdc ドライバ完成かなあ。bmd の耐久試験と合わせて ./build.sh でも 走らせてみようかな。って bmd をスワップに使ったら死んだとしても どこで死んだか分からんなあ。むう。

[x68k/hdc] てか bus_dma 使うように書き直さんといかんねえ。 めんどいよう。ていうより bus_dma 分からんよう。しくしく。

[x68k/hdc] なんで sd0 をマウントすると、バイナリファイルが 動かなくなるんだろ。先週は全ダイナミックリンクが死亡したけど、 今週は /usr 以下の実行ファイルが全滅。むう。 KTRACE 入りカーネルに作りなおそう。起動の ftp に時間かかるなあ。

[x68k/hdc] ってやっぱり死ぬし。単に再現性がないだけなんかなあ。

[evbppc] walnut が evbppc になったらしい。 てか openblockss はどうなってんだろ。

[MI/slhci] BSD-USB ML より。 REX-CFU1 ていう PCMCIA-USB アダプタが SL811HS/T 使ってるらしい。 のぐちさんて方が遊んでらっしゃる模様。 あんないい加減なドライバでも commit しといたので気軽に遊べたと見るか、 いい加減なので遊べてないと見るか。遊びがいはありそうだが(ぉ。 x68k でも DMA 使ってないんだけど、それは slhci じゃなくて USB 全般の話かな。 いままで PCMCIA に USB って attach されたことなかったのか。

[MI/slhci] てか rev 1.4 なら low speed のバグに悩まされずに 済みそうなので、これ買ってこようかなあ。でも i386 じゃテストマシンと 開発マシンが同じになってしまって効率悪いなあ。 x68k に PCMCIA つければいいのか...(爆)。

[x68k/hdc] 前回 sd0a がマウント中にお亡くなりになったので fsck をかけにゃならんのだが、なんせそのためのドライバを開発中なため fsck が動かなかったりする訳で、どうすりゃええんじゃ(笑)。 なんか一回の転送分をドライバは全部読み込んだと思ってフェーズを STATUS フェーズに変えたのに、コントローラがまだ DATA IN フェーズ だと言い張ってて、フェーズを変えっこしてぐるぐるしてるみたい。

[x68k/hdc] DMAC の MTC が 16bit なのに scsipi 層から 65536バイトのリクエストが来てぐるぐるしてたらしい。 うーむ、分かり易いバグだ。 それ直したところ fsck は一度は成功したっぽいけど、その後 fsck も mount も出来なくなってしまったので、さっさと newfs。 ほんとは他の HBA につないで fsck し直すとかってのが正しいんだろうけど。 相変わらず newfs だけは成功するのが幸い、、なのか?

[x68k/hdc] 相変わらず newfs して mount してなんか書き込むと 即死する。

mari# newfs /dev/sd0a
Warning: 328 sector(s) in last cylinder unallocated
/dev/sd0a:      2048000 sectors in 3161 cylinders of 4 tracks, 162 sectors
        1000.0MB in 7 cyl groups (484 c/g, 153.14MB/g, 18048 i/g)
super-block backups (for fsck -b #) at:
      32,  313856,  627680,  941504, 1254560, 1568384, 1882208,
mari# mount /dev/sd0a /mnt
mari# cd /mnt
mari# ls -la
total 3
drwxr-xr-x   2 root  wheel   512 Dec 22 21:09 .
drwxr-xr-x  22 root  wheel  1024 Dec 22 20:48 ..
mari# echo a > a
start = 1, len = 9800, fs = /mnt
offset=5328 5328
panic: ffs_alloccg: map corrupted

[x68k/loadbsd] NFS 起動な X68000 でいつもカーネル起動中に warning: scsi_find: can't get boot interface -- update boot loader というメッセージが出ててどうしたものか考えてたが、 よくよくソース読んでみたら loadbsd.x にオプション -r ne@0 を渡せば いいだけだった。なんのこった。

[x68k/hdc] panic しても次にログインプロンプトが出てくるまで 10分以上かかるので、なんで panic したんだったか忘れてるという罠。 なんか毎回 panic するきっかけとなる場所は同じなのに panic メッセージが 違うのでとりあえずメモっておこう。

[0x8,6,65536]->2 0x1009<NOSLEEP,ASYNC,DATAIN> hdc_sched()hdc_select()@SEL @CMD h
dc_intr()@DIN hdc_dmaintr()hdc_dmaintr()@STAT @MIN @FREE hdc_done()
panic: amap_wipeout: corrupt amap

uvm_fault(0x12fcc0, 0x70036000, 0, 0x1) -> 0xe
  type 8, code [mmu,,ssw]: 401074d
trap type 8, code = 0x401074d, v = 0x70036113
kernel program counter = 0x9ce10
panic: MMU fault

[x68k/NFSROOT] loadbsd.x に -r ne@0 を指定したので、 カーネルコンフィグの

config netbsd root on ne0 type nfs

config netbsd root on ? type ?

[x68k/hdc] ディレクトリエントリに何か書き込む処理はほぼ間違いなく panic するらしい。rename(2) は大丈夫だった。 fsck は成功したり panic したりで全然再現性がない。

mari# ktrace -i fsck -y /dev/sd0a
** /dev/rsd0a
** Last Mounted on /mnt
** Phase 1 - Check Blocks and Sizes
trap: bad kernel read/write access at 0xc
trap type 8, code = 0x802070d, v= 0xc
kernel program counter = 0xf305a
kernel: MMU fault trap
panic: MMU fault

[x68k/hdc] どうやったら panic した時に ddb じゃなくて gdb 使えるんだろ。正しいのかどうか分からんけど、ddb で panic した場所を 調べるには db の trace コマンドで出てきた番地を nm netbsd (| sort) の 結果と照らし合わせて推測すればよさげ。もちろんクロスの時は nm は m68k--netbsdelf-nm とかを使うことになる。 なんかもっと高尚な方法はないんかしらん。

[x68k/hdc] てか uvm_pageout 付近で panic されても困るなあ。 最近そのあたりで panic したっていうレポートをよく見るような気がするから もしかして最近の UVM あたりはちょっとアレなのかしら。