吉祥寺にて撮影大会。
初めての着物。
締めつけられて動きづらいというかなんというか。
ポーズを決めるのもけっこう大変です。同じ体勢でいると足がつってきたり。
撮影後、あっというまに確認して選択して紙を指定しておしまい。今どきはデジタルカメラなのだねぇ。確かに便利なんだけど、味気ないというかなんというか。
今度やるときはデジタルじゃないのがいいなぁ。もしくはデジタルと銀塩の併用ができたらいいな。
また始めてみる。
SHLIB_LINKのパッチをあてれば大体すみそうな感じ。
20050928ts版に更新。じゃないと、コンパイルエラーになるらしい。
で、更新したけどコンパイルエラー。なんでじゃー。
公園で蚊に刺されまくる。蚊がまだ生きているのか。
なんか変な時間に昼寝して、生活リズムがぐちゃぐちゃになってしまった。
bfdに関するパッチも当てるが進展せず。
i386ならうまくいくらしいのでそっちにbuild環境を変更する。
起きられませんとも。えぇ。
色々とパッチを当てて、やっとbuild.shを完走させることができた。
20050924で作っていたrelease物をインストール。
MicroDrive 4Gだよ。うれしいな。
せっかくなので操作手順を保存する。インストール手順書を作れればいいなと思っている。
起きられませんとも。えぇ。
朝のおはよう大切かも。
大きな容器のヨーグルトは全部食べきれないほど入っている。
さて、苦労して作ったmpc860のバイナリをインストールしようとOBS50に火を入れる。
あれ、シリアルに何も出ないぞ。
あれ、LEDに0が出て、消えて、を繰り返しているな
何か変だな。とりあえず、シリアルがおかしいのかもしれないから、同じケーブルでOBS266につないでみる。
OBS266ならちゃんと動くみたいだから、ケーブルやシリアルの設定の問題じゃなさそうだ。
うーむ、HDDはずしてみるか。
うーむ、やることなくなったな。
壊れちゃったのかな。
最後に動いた記録は2005/08/02の日記にあるとおりか。あれから一度も電源を入れていないはずなので、二か月の間に何かがあったのでしょうね。
OBS50は自分がNetBSDに大きく傾くきっかけを与えてくれた計算機だけに愛着もあり、使いつづけてきたのだけれど、ついに壊れてしまった。
とても悲しい。
修理できたらいいのだけど、どうなんだろうか。
ここに書くのも変ですが、初代OpenBlockSであるOBS50を譲ってくれる人はいないでしょうか? 色は問いません。付属品の有無も問いません。ぜひメールください。よろしくお願いします。
少し早く起きて、少し早く出かけた。
やればできる!
昨日はOBS50が故障したことに悲しんでいたけれど、悲しんでいてもしかたがない。
先に進もう、わたしにはOBS200もある。
ということで、emacおかしい件についてメーリングリストに出されたパッチを見ながらふと思う。
phyが二つattachされてしまっておかしくなるという話をNetBSD BoFのあとに聞いていた。
実際にやってみると教えてもらったとおりにukphy0, ukphy1の二つがattachされている。
emac0 at opb0 addr 0xef600800 irq 9: 405GP EMAC emac0: interrupting at irqs 9 .. 15 emac0: Ethernet address 00:80:6d:51:0e:7d ukphy0 at emac0 phy 0: Generic IEEE 802.3u media interface ukphy0: 78Q2120 10/100 media interface (OUI 0x00039c, model 0x0014), rev. 11 ukphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto ukphy1 at emac0 phy 1: Generic IEEE 802.3u media interface ukphy1: 78Q2120 10/100 media interface (OUI 0x00039c, model 0x0014), rev. 11 ukphy1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto
それを回避するパッチを見たところ、#ifndef _obs200_という感じでif_emac.cに条件分岐を設けている。
ネットワークインタフェースのソースコードに機種名による条件分岐は入れたくないよなぁと思い、こういうのこそconfigファイルで逃げらるようになっているんじゃないかなぁ。ということでconfigファイルを見る。
するとphyに値がわたせるみたい。
さっそく次のようなパッチを当てて動かしてみる。
--- sys/arch/evbppc/conf/OPENBLOCKS200.orig 2005-10-06 14:51:34.000000000 +0000 +++ sys/arch/evbppc/conf/OPENBLOCKS200 2005-10-06 15:08:41.000000000 +0000 @@ -173,10 +173,9 @@ viaide* at pci? dev ? function ? # VIA/AMD/Nvidia IDE controllers atabus* at ata? -tlp* at pci? dev ? function ? # DECchip 21x4x and clones +rtk* at pci? dev ? function ? # Realtek 8129/8139 -lxtphy* at mii? phy ? # Level One LXT-970 PHYs -ukphy* at mii? phy ? # generic unknown PHYs +tqphy* at mii? phy 0 # TDK Semiconductor PHYs #cardslot* at cbb? #cardbus* at cardslot?
すると、ちゃんとtqphy0だけがattachされて動作も正常である。
emac0 at opb0 addr 0xef600800 irq 9: 405GP EMAC emac0: interrupting at irqs 9 .. 15 emac0: Ethernet address 00:80:6d:51:0e:7d tqphy0 at emac0 phy 0: 78Q2120 10/100 media interface, rev. 11 tqphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto OUI 0x00039c model 0x0014 rev 11 at emac0 phy 1 not configured
なんか最後の行に余計なものが付いているが、まぁ、if_emac.cに直接手を入れるよりはよいかなぁと思う。
ただ、これが対処として良いのかどうかわからないのでnetbsd-obs@freemlにメールを出してみた。
できればsend-prして直してもらうようにお願いしたいな。
もしかしたらファームウェアの更新をしてみたら正常に戻るのじゃないかと思ってきた。
が、今日はもう寝よう。
朝も夜もかと思いつつ朝だけだった。
12時すぎても起きているのはいかがなものか。
寝ようといっていたが実は昨日の夜にファームウェアを一番最初に配布されたLinuxに戻してみた。
おー、Linuxは起動するじゃないか。ということは、完全に壊れているというわけでは内みたいだな。
よかったよかった。
tqphyネタについてメールをもらった。
メールによると、tqphyはアドレス0に常に反応するそうで、tqphy側でアドレス0を無視するようにするのが正しいらしい。
ということで調べてみると、tqphyreg.hには次のような記述がある。
/* * http://cesdis.gsfc.nasa.gov/linux/misc/100mbps.html has this to say: * * TDK Semiconductor (formerly Silicon Systems) 78Q2120 (10/100) and 78Q2121 * (100Mbps only) MII transceivers. The first PHY available which worked at * both 5.0 and 3.3V. Used on the 3Com 3c574 and Ositech products. The OUI * is 00:c0:39, models 20 and 21. Warning: The older revision 3 part has * several bugs. It always responds to MDIO address 0, and has clear-only * semantics for the capability-advertise registers. The current (3/99) * revision 11 part, shipping since 8/98, has reportedly fixed these problems. */
なるほど、そのように書いてあるみたい。ということで、tqphy.cではどのような対策をしているのかを見てみると、
static int
tqphymatch(struct device *parent, struct cfdata *match, void *aux)
{
struct mii_attach_args *ma = aux;
if (mii_phy_match(ma, tqphys) != NULL) {
/* The DIAG register is unreliable on early revisions. */
if (MII_MODEL(ma->mii_id2) == MII_MODEL_xxTSC_78Q2120 &&
MII_REV(ma->mii_id2) <= 3)
return (0);
return (10);
}
return (0);
}
ということとでrevが古いものは問答無用でnot configured扱いされていることがわかる。
しかし、OBS200のtqphyはrev 11だと主張していて、バグ修正済だと思われる。が、先のコメントにあるようなバグと同じ動きをしていることになる。
バグ解消済みのはずだがバグがある?
よくわからなくなってしまった。
いずれにせよ、「tqphy側でアドレス0を無視するようにするのが正しい」としないと問題は解決しない。しかし、アドレスってなんだろう、とmiiディレクトリにあるソースを眺めてみたけれど、やっぱりよくわかりません。
と、メールで返してしまった (無責任なやつ)。
天気が悪いので昼間はずっと家のなか。
夜になって車で錦糸町方面にお出かけ。
やっぱり天気が悪いな。
ちょっとビデオ見すぎな気がする。
Linuxが動いて故障の危機から脱出したこともあり、気を取り直してNetBSDを入れるべく作業する。
NetBSD/mpc860を動かすにはブートローダをflashに書くのが第一歩。
ということでやってみたが、例の故障時と同じ動作をする。つまり、LEDに0をしばらく表示し消灯するのを繰り返す。
うーん、動作実績のあるブートローダをnandraからもらってきて書き込んでみたが同じ。
Windowsからやるのがいけないのかと思い、tcpdwl.cを引っ張り出してきてNetBSDでコンパイルして書き込んでみても同様の症状で動かない。
Linuxだとなんの問題もなく動く。なぜだろう。
気づいた点として、Linuxの場合はファームウェア更新時にLEDが1から順に8までカウントとアップして、8の激しい点滅で終わるが、NetBSDのブートローダの場合は3でおわる。でも、これはこれで良かったような気がする (が、覚えていない)。
あとなぜかLinuxの最新ファームウェアに更新したら、以前の設定が復活していてびっくりした。しかもrootのパスワードを忘れていたのでさらにびっくり。
いったいどこに書き込んでいたのだろうなぁ。
tqphyの件についてさらにメールをもらう。
「tqphy側でアドレス0を無視するようにするのが正しい」という件については、「実は難しい」ということ。
対策案としては次の三つを教えてもらう。
まず、1番目のtqphymatchでma->mii_phynoが0ならreturn0;してmatchしないようにする方法は、ukphyが定義されてるとそれが使われてしまうため抜本的な解決にはならない。
2番目のmii.cでtqphyを特別扱いするのは、いわく「なんだかなー」という感じで積極的に採用することは難しい。
3番目のtqphyattachでma->mii_phynoが0ならreturn;して実質的にattachしないようにする方法は有力そうに思える。
ということでtqphy.cを修正して動作確認を行った。
実際に動かしてみたところ、通信時に
emac0: MII timed out
を連発してemac0が使えない。これは対策前と同じ状態なので効果がないということになる。逆に、tqphy1をattachしないようにma->mii_phynoが0ならreturn;するようにしてみたけれども同様のエラーメッセージを出してemac0は使えない。
やはり、動作させるためにはmatchさせないのが前提条件となるようだ。これだとukphyにmatchしてしまう問題を解決しなければならず、configで回避するしかないということになるのかなぁ。
ukphyを書かなければ良いわけだけれど、良く考えてみたらOBS200のもう一つのネットワークインタフェースであるrtk0のPHYはukphyであることを思い出す。
つまり、
ということになり同時に両方のネットワークインタフェースが使えないということになる。
昔は両方使えていた記憶があるんだけどなぁ。どうやっていたのだろう。
と、またメールした (とことん無責任なやつ)。
隣町でしばらく。
重要な決断をしているそばで自転車にのってコケてみたり。
バタバタしているが、とりあえず電話して色々決めた。
なんか反応が無くなっている。pingでの応答もない。
電源断して再起動。前回はNICかHUBがおかしくなっていたけれど、今回は無事にあがってきたみたい。
さて、なにが原因でしょうね。emacs+screenでメモリを食いつぶしておかしくなったとか。swapなしの運用がいけないのかなー。もう一顧MicroDriveが必要ということか。うーむ。
やっぱりシリアルつなぎっぱなしでログを取らないと駄目かも。
メールはこちらへ...[BSD小僧 (tokuda @(at) tokuda .(dot) net)]
この日記は、GNSを使用して作成されています。