こんな感じで1980年頃製造の中国製のジャンクの機械式時計を直す練習をしているのだが。新品を分解して元通り動かすのはできても、故障品の調子がおかしい原因を探して解消するのは一筋縄じゃいかない。バネが折れたとかで放棄されたのはまあどうにかなるけど、そうじゃないのは状態がいいよなと思ってもそのうち止まってしまう。それが捨てられた原因なんだろう。
そういえば去年、大学で一人公共工事をしていた。コンクリ打設とかは学生が手伝ってくれたが穴歩掘るところが一人orz
これで腰と肩をやっちまってな。RTK-GNSSの基準基地局を作ってた。見通しが微妙な場所なんだけど。
SPARCstation 20のHDDを試しにSCSIKnifeというかZuluSCSIの変種にして、SDカードで代用できるようにしたんだが。書き込みが遅い気がする。HDDに戻すか...。
1995年製造、30歳の老体のSPARCstation 20をいじめてる。NetBSD 10.1のセルフビルドだけど、ビルドを始めて10日目にメモリ関係のエラーで止まってた。一昨日再開した。
とりあえず、これだけ液漏れしたけどプリント基板は腐食していなかった。ただし、ハンダを剥がしたら臭いこと臭いこと。
2週間でひどい液漏に発展したのは上の10V 470uFで、この時点で液漏れしてたのは下の10V 680uFのうちの1本だけ。
足が曇ってるな～、交換するか、でも在庫が切れたから補充待ち、の2週間で液漏れが進んだ。通電は当然していないんだが。日ケミLXFだからしょうがない?
UPSのバッテリーはいつもこれで交換してる。ケーブルとかコネクタがもう1セット余分にあればクリティカルな時間を減らせるんだが。でも組み替えるのに15分もかからんし。その間に停電なんてしないだろうと。
適切な道具があると安全にリワークできるし速い。SuperSPARC-IIモジュールのコンデンサ交換を2台やってた。
微妙に調子が悪いの、メモリだったか。負荷を掛けると突然死することがあって、理由がわからなかった。あと、stray interruptがやたらと起きるのは、quad first ethernetボードのせいらしい。
テープを作るのをミスっていたらしい。tapefile2の中身がtar.gzじゃなくてsparc executableだった。何をどうしたんだか。
gzipがstdinから読みとるときに4バイトと決めつけないでブロックサイズをチェックするパッチをNetBSDのgzipの作者から送ってもらったのだが。テープブートの場合はまだ問題があるようだ。
カーネル内のramdiskに入ってるtarの正体はpaxなのがわかったのだが、ブロックデバイスにたいしてなんでバッファを十分要しいしないでread()を呼ぶのか。謎だ。
SPARCstation 20をテープからブートしてNetBSDインストーラを起動するところまではやりたいのだが、インストーラが入ってるtarファイルを展開するところでtarが4バイトしかばっふぁがないのに4096バイトもブロックがあると怒ってしまう。
SPARCstation 20にDATドライブをつけたのだが、負荷が高いときにCPUモジュールによっては、またランダムで落ちるようになってだな。コンデンサ交換とかしてた。
いま、ウォルボックスを土台側鉄パイプに固定したところ。上にもう一本パイプを接続するのだが、こっちは人手が必要なんだけど、学生があまりいなくてなあ。
型枠を外して、1.1mの穴も埋め立てておわった。なお、大学建設時の廃材っぽいのが結構出てきたのだが。
地図から消されたムラの大学の悪いオタク。 【言わないとわからない人用注意書き】ポスト内容は大学当局の見解ではありませんし、大学当局の意に沿ったポストのこともあればそうでないこともあります。
2017年 4月に登録
