計算機暗号屋日記 (2004年11月 霜月)

2004年11月30日

• msnでもSCIS2005を検索して出てこないみたいだ。 皆さん、締切間に合ったかな？ 何件ぐらい発表申込があったんだろうか。

2004年11月29日

• PROOFとかいう例のHDケース(K3500TEA/BK)で、HDの抜き差しをしやすくするために、ケーブルの延長を試みている。
  • ATA66 cableについては、手持ちので何とかなったけど 4pin-4pin電源ケーブルについてはもともと手持ちの種類があんまり無いので、買いにいった。
  • 片側が小さい変わった形状なので、目的とするものは見つけられなかったが、普通の4pinの延長ケーブルDE-55というのがあったので買ってみた。 ヨドバシカメラ上大岡店で210円。 もうちょっと高いのを想像していたので、安くすんだ。
  • 早速接続。 ん？ なんか、DE-55のオス側の端子が固定されていないので、刺さりにくいんだけど… って、頑張って接続。 んで、HDにも接続。 お。 これは緩くていいぞ。
  • んでIEEE1394 cable接続して電源on。 あれ？ 全然反応しないぞ。 安物買いの銭失いか？ と、思ったら、DC adapterがcaseにつながっていなかった。 ^^;
  • 改めて接続してSW on。 ちゃんと認識するじゃん。 「camcontrol devlist」すると 「<Prolific (1394 ATAPI,Rev 2804> at scbus0 target 0 lun 0 (da0,pass0)」 と出る。
  • これでまた一歩、PC video化計画が進展した。
• 情報セキュリティ基本問題委員会。 第1次提言が出ていた。
• 欧州Lycosがスパムサイトを「DDos攻撃」するスクリーンセーバ配布。 (ITmedia 2004/11/27) あちこちでコメントされているけど、とりあえず。
• RC5-72 challenge0.166%突破。 昨日のペースだと全空間探索にあと871年。 3年4倍で解読速度が向上するとすると27年。

2004年11月28日

• IACR ePrint最近1カ月。 最近やっぱり多いのはEurpcrypt 2005と、FSE 2005なんだろうな。
• 帰宅時室温24度。 今日は終バス逃して坂を登ってきて暑かったので、窓を開けたら結構空気の通りがよいみたいで、15分ほどで22度まで下がった。 そろそろ窓閉めるか。

2004年11月27日

• diskの残りが1.5GBぐらいになっていて、録画ファイルが溢れるかどうか危険な状況になっていたので、9GBのファイルを消したら… 「fwohci0: IR DMA overrun (0x40008011)」 やっぱUDMA100でもダメか。 なんとか、うまい方法無いのかなぁ。

2004年11月25日

• P4EE遅いし、HDは毎日のように壊れるし、ゴミデータは混入するし… 忙しい時ほど余計な仕事が増えるMurphyの法則。:-(

2004年11月24日

• msieve。 (情報from M.Kamadaのきょうの日記11/24)
• 早速3名の方には査読を快諾して貰った。 感謝。 とりあえず今までの累積でも

  論文投稿数 × 査読者数 / 共著者数 + 査読依頼件数 < 査読数

  は満たしているとは思うけど。 やっぱり頼むのは気を使う。

2004年11月23日

• 査読が17〜18件ほど来るらしい。
• RC5-72 challenge0.164%突破。 昨日のペースだと全空間探索にあと738年。 3年4倍で解読速度が向上するとすると27年。

2004年11月22日

• んで↓について、とりあえず全部嘗めて読んでみたけど何故か不良セクタには引っかからなかった。 まぁ粗い読み方だからなぁ。 んでmountしてBADディレクトリのファイルを読んでみたりしたけど、エラーにならないし。 うーむ。 まぁいいか。 気持ち悪いけど。
• さて、このAthlon君に使っていた60GB HD Maxtor DiamondMax D540X-4D (4D060H3)の中身どうしようかなぁ。 最終的には不良セクタもあるしで、消えちゃってもそれほどダメージが無いものを入れたいとは思うんだが、今はいっているもので引き上げるべきものって何かあるかな。 とりあえずは不良セクタ箇所をもうちょっとチャンと調べて特定しておくか。 どうでもいいけど、この電源cableの抜き差し、もっと楽にする方法って無いのかなぁ。 毎回、かなり力がいって指がおかしくなる気がする。
• 裏番組の録画をしようとして、間違って両方ともGV-MVP/IDVの方を指定していた。 うーむ。 ただ、運良く、よりとりたい方がとれていたからよかった。 しかも録画しようと思っていた時間はほぼ同じで、長い方で拾えていたし。 なんか、もっと効率的に間違いが無いようにschedule fileでも作ってそれを解釈して録画予約するような仕組みにしないとダメだなぁ。 なんか、それぐらい誰か作っているような気がしないでもないけど。 あとで気が向いたら探してみよう。
• UltraATA 100になってから試してなかった。 IEEE1394 storageを使いながら「fwcontrol -R」しても「fwohci0: IR DMA overrun (0x40008011)」は起きないみたいだ。 素晴らしい。 しかもこのときnetworkもかなり苛めていてHDもそれなりに触っていた。 どの辺まで苛めるとoverrunするか興味あるけど、どうしようかな。 そういえば、IEEE1394もHD case内のことだけどATA33→ATA66と、cableが宜しくなっているので、速くなっているのかもしれない。 ん？ さすがに上記状態に加えてmvででかいファイル移動をdiskを超えて実行したらoverrunした。
• これでしばらくは録画しまくっても大丈夫か。 といってもそれなりの整理は必要だな。 どうやら読むのは25.3MB/sぐらいらしい。 ということで、全部なめるのは3時間弱って所か。

2004年11月21日

• 今日はアキバと有楽町に寄ってずいぶん散財してしまった。 順に成果を確認するか:
  • まずはBICカメラのアンテナケーブル。
    • 2SL1W-BCというのを924円で買ってきた。 早速ケーブル接続変更。
    • むむ。 bt878の方の画像、かなり悪いですか？ 丁度画像が悪い時間帯か？ いや、それにしてもここまで3chの画像が悪かったことはない気がするぞ。
    • もう一度接続をよく見直す。 どうやらvideoデッキの出力部分に刺しているケーブルがちょっと緩かったみたい。 しっかり刺したらチャンと見えた。
    • これまでも画像がイマイチだったのは、もしかしてこれが理由？ それにしても1ch〜3ch限定の映り悪さってのもなぁ。 もしかして、買ってきたケーブル無駄だった？ いや、それは無いか。 細いし、コネクタも小さくて邪魔にならないし。 いずれにしてもイマイチなアンテナケーブルがどんどん余っていく… といっても、これで終り、じゃないかも。^^; まだTV tuner boxもそのうち買い足そうとか目論んではいるからなぁ。 いずれにしても3本もアンテナケーブルが余ってしまった。
  • 次はヤマギワソフトで、IVE05 OUTFLOWを購入。
    • まぁこれは聞いたりMP3に落したりしながら次の作業か。
    • あんまり本題と関係ないけど、イマドキ、パソコンソフトというと、もうほぼアダルト限定なのか？ まぁ確かにファミコンに始まるゲーム専用機との関係を考えれば分かる気もするが。 I'veの曲が収録されている初回特典CDを入手したくて中古店とかまわったけど、認識を新たにした。
      ＃ゲームは要らないんだけど。MS-Windowsマシンもってないし。
      いやげんしけんを見ていてもしかしたらそうか、と思うふしもあったんだが。
  • いままで横目で見るだけで入ったことなかったアニメイト秋葉原店。
    • 一階分の面積はそれほどあるわけじゃないけど結構でかいな。
    • やっぱここもポイントカードがあるのね。 昔からあったかなぁ。 どうもアニメイトというと池袋のイメージが私の中では強いんだが。 って20年ぐらい前の話の気がするが。:-)
    • ということで漫画を数冊購入して退散。
    • んで、帰ってから袋を開けたらきゃらびぃとかいうのが入っていた。 こういうの見るとまた散財の危険が。^^; 表紙でRe-Sublimityというのが宣伝されていて、どっかで見たことあると思ったらちょっとビデオにとっていたな。 とりあえず、最初の2話だけ見て、今はとるだけになっている奴だ。 確かに今OPを見直し(聞き直し)たけどKOTOKOですな。 うーん。 買おうかどうかきわどい値段ですな。 とはいえ、次見かけたら買ってしまいそうだ。
  • んで最後はソフマップでまたIEEE1394 storageを購入。
    • なんかまた人柱してしまいそうな気がするんだが、K3500TEA/BKというのが5880円であんまり高くないので、つい手をだしてしまった。
    • ついでにbulk HDも買ってみた。 「容量単価が一番易い奴が欲しい」といったら250GBのを選んできたけど、あとから考えるとやっぱり160GBの方が安かった気がするぞ。 といっても、大差あるわけじゃないからまぁいいか。 250GB HDも1台くらいは練習であっても… ってよく考えると勤務先ではすでに使っている気がする。 そう、そういえば、512 byte/sectorとして実はセクタ数が32ビット限界って近付いている気がするけど、そもそも規格的には対応しているのかな？
    • 秋葉原電気まつりのカードも貰っていたらしい。 なんか、福引みたいなのを引きにいかないといけないのかと思っていたけど、ただのスクラッチカードか。 ということで、削ってみる。 4連敗。 まぁそんなものだろう。
    • んで、まずは、3.5"HDDはいーるKIT DUALが邪魔なので片付けるか。
    • んでK3500TEA/BKの箱を開けてみる。 マニュアルとかほとんど無いのね。 なんかあっさりしていてびっくり。
    • しまった。 NOVACの方のIEEE1394 cableを片付け忘れていた。
    • とりあえず接続完了。 さて、早速実験したいけどやっぱりXを落しておいた方が安全か？
    • 小心ものなので、やっぱりXを落して、「tail -f /var/log/messages&」な状態で実験。 んで電源を入れて安定させてからIEEE 1394 cable接続。
    • 果たして… panicはしなかったけど、da0の認識もなかった。 IEEE1394 cableの抜き差しとか、HD caseの電源off/onとか試したけどやっぱり認識しない。 「fwcontrol」では出てこないんだけど、「fwcontrol -t」では認識されているんだけどなぁ。
    • なんか、これ、買う時に「うまくいかなかったら返品とか出来ますよ」というのの適用かなぁとか悲しい考えが頭をめぐった。 やっぱり返品できるにしてもアキバまで行くのは面倒だし。 と、よく見るとATA cableがチャンと刺さってないじゃん。
    • ということで、しっかり刺し直して、もう一度実験。

      Nov 21 23:26:22 flu kernel: fwohci0: BUS reset
      Nov 21 23:26:22 flu kernel: fwohci0: node_id=0xc800ffc2, gen=11, CYCLEMASTER mode
      Nov 21 23:26:22 flu kernel: firewire0: 3 nodes, maxhop <= 2, cable IRM = 2 (me)
      Nov 21 23:26:22 flu kernel: firewire0: bus manager 2 (me)
      Nov 21 23:26:23 flu kernel: fwohci0: txd err=14 ack busy_X
      Nov 21 23:26:23 flu kernel: fw_asybusy
      Nov 21 23:26:24 flu kernel: fwohci0: txd err=14 ack busy_X
      Nov 21 23:26:24 flu kernel: fw_asybusy
      Nov 21 23:26:25 flu kernel: fwohci0: txd err=14 ack busy_X
      Nov 21 23:26:25 flu kernel: fw_asybusy
      Nov 21 23:26:26 flu kernel: fwohci0: txd err=14 ack busy_X
      Nov 21 23:26:26 flu kernel: fw_asybusy
      Nov 21 23:26:26 flu kernel: firewire0: max_asyretry exceeded
      Nov 21 23:26:26 flu kernel: firewire0: bus_explore node=0 addr=0x400 resp=16 retry=5
      Nov 21 23:26:26 flu kernel: firewire0: bus_explore failed for 1 nodes
      Nov 21 23:26:27 flu kernel: fwohci0: BUS reset
      Nov 21 23:26:27 flu kernel: fwohci0: node_id=0xc800ffc2, gen=12, CYCLEMASTER mode
      Nov 21 23:26:27 flu kernel: firewire0: 3 nodes, maxhop <= 2, cable IRM = 2 (me)
      Nov 21 23:26:27 flu kernel: firewire0: bus manager 2 (me)
      Nov 21 23:26:27 flu kernel: firewire0: New S400 device ID:0050770e00000447
      Nov 21 23:26:28 flu kernel: da0 at sbp0 bus 0 target 0 lun 0
      Nov 21 23:26:28 flu kernel: da0: <Prolific (1394 ATAPI,Rev 2804> Fixed Simplified Direct Access SCSI-4 device 
      Nov 21 23:26:28 flu kernel: da0: 50.000MB/s transfers
      Nov 21 23:26:28 flu kernel: da0: 58627MB (120069936 512 byte sectors: 255H 63S/T 7474C)
      

      やったね。
    • このあと、数回「fwcontrol -r」とか、IEEE1394 cable抜き差しとか、いくつかbus状態が変わることしかけど大丈夫。 しかし「fwcontrol -t」で、

      crc_len: 5 generation:19 node_count:3 sid_count:3
      id link gap_cnt speed delay cIRM power port0 port1 port2 ini more
      00    1      63  S400     0    1   -9W     -     P         1    0
      01    1       7  S400     0    1    0W     P     -         0    0
      02    1       7  S400     0    1   15W     C     -     C   0    0
      

      この「-9W」って気になるんだけど、そういうものなのか？
    • これで、しばらく様子見かな。
    • ちょっとまて。 250GB HDの初期不良確認をしていないぞ。 せっかくだから、このHD caseを使って実験するか。
    • この短いケーブル、なんか抜き差ししにくいんだよなぁ。 普通のATA66のcableにみえるからこっちに取り替えてみるか。
    • んで接続。 あ、しまった。 まだ、最初の実験に使った60GB HDのda0の情報が残っているままだった。 ということで、一旦IEEE1394 cableを外して「fwcontrol -r」を連打。
    • んで改めて接続。 あかん。 なかなか認識してくれないなぁ。 やっぱりこのcableじゃダメか？ それともHDのjumper SWを無くしたくなかったので、もともと設定されていた「cable select」という設定が問題か？ やっぱりmasterにする必要があるのかなぁ。
    • どうでもいいけど、HDすぐ止まるのかんべんして欲しいなぁ。 んで、HDがうまくまり始めたタイミングで「fwcontrol -r」したら 果たして

      da0: 238475MB (488397168 512 byte sectors: 255H 63S/T 30401C)

      で、ようやく認識した。 よかった。 この組み合わせでいいみたいだ。 電源ケーブルも汎用のものっぽいから、もっと長いのを買ってきて 抜き差ししやすいように工作したくなってきたけど、次の課題だな。
    • ということで、とりあえず最初から最後までdiskの中身全体をなめてみるテスト。

2004年11月20日

• ATA33→ATA66 cable変更作業:
  • 部屋の明かりでもいいといえばそうなんだけど、やっぱり外が明るい方が部屋も明るくて作業し易いので、明るいうちの作業を期待してPCをshutdownしてケーブル類を外す。
  • この前開けてから1カ月ぐらいしか経っていないはずだけど結構背面吸気孔に埃がびっしり。 掃除器をもってくる。
  • んで、ATA33の40芯ケーブルからATA66対応の80芯ケーブルに取り替える。 80線の方は以前からもっているのではなくて、抜く時に楽なようにコネクタに引っ張る部分がついているcableを使う。
  • また箱根細工を悩みながら開けてなんとかcableの取り替え終了。 やっぱりmicroATXはよくないなぁ。
  • んで、とりあえず筐体を閉めずに、本体と外のcableもdisplayとkeyboardと電源という最低限にして起動。 single user modeをboot loaderで指定する。
  • よしよし。 ちゃんとUDMA100と認識しているぞ。 あれ？「Mounting root from ufs:/dev/ad0s1a」を表示した後、ダンマリなんですけど。 このcable不良か？
  • もう一度、cableがチャンと刺さっているかチェック。 起動。 うーん。 やっぱ同じか。 何回かやっても同じだなぁ。
  • 前回うまくいった80線ケーブルで試すか。 いや、まてよ。 そういえば、5.3Rにしてからsingle user modeで立ち上げたのって version upの時の「mergemaster -p」するためだけの時だった気がしてきた。 ということで、80線cableを外して… あ。 コネクタについているビラビラのやつって紙なのね。 破けてしまった。 がーん。 と衝撃を受けつつ、40線cableに戻して、起動。
  • おや？ secondary認識してないぞ。 なんか嫌だなぁ。 とりあえずBIOSで確認するか。 やっぱり認識していない。 うーん。
  • cableとか押し込んでみてもう一度BIOSから確認。 やっぱダメですか… あんまり抜き差ししているうちにcable傷つけちゃったかなぁ。 よくないと分かりつつもついついATA cable抜くの大変なので、多少は線を引っ張って抜いていること多いからなぁ。
  • 電源を落して、もう一度cableとかチャンと確認。 ん？ masterの方のコネクタの刺さり方がイマイチかも。 これか？ ということで、チャンと押し込んでBIOS起動。 認識した。 よかった。 masterのコネクタの刺さり方でslaveの方に影響するとは知らなんだ。
  • んで、色々実験するけどやっぱりsingle user modeで立ち上がらず。 何故かmulti user modeでは問題無く起動するんだよなぁ。 それでも「shutdown -r」とかすると、「Shutting down ACPI」とか表示した後になんかゴミを表示して自動的には起動しないし… なんか変だ。 kernelを壊しちゃったか？
  • ということで、multi user modeで立ち上げてkernel再構築。 ついでに、おそらく使わないだろうfweをkernelから外す。
  • やっぱりsingle user modeで立ち上がらないという現象に変化なし。 これは、ATA33 cableの問題ではないだろうと考えることにして、80線cableに戻す。 なんかコネクタ外しのためのビラビラに代わるいいものないかな。 悩んだ末にとりあえずねじりっこを付けておいてみる。 無いよりましだろう。
  • 問題無く、当然というか、立ち上がる。 さて、single user modeで立ち上がらない現象どうするかな。 make.confをなるべく普通にして、GENERIC kernelで試すべきなんだろうけど、色々録画時間帯にはいってしまったので、作業はまた今度。 とりあえず、UDMA100でHDが認識するようになったということでよしとしよう。 ATA cableの抜き差しって結構力作業なので疲れてしまった。
  • と、作業が思ったより時間がかかってしまって、外は真っ暗。
• どうも、最近ntpdがうまく立ち上がらないのは、5.2.1Rから5.3Rで起動scriptがずいぶん変わってPPP接続が確立される前にntpdが立ち上がる確率が上がったからのような気がする。 さて、どう解決するかな。
• んでmaxtor diskでもやっぱりpanicした。

  da0: 958377091999MB (1073807168 935858176 byte sectors: 0H 0S/T 0C)

  が本当だったらすごいディスクで嬉しいんだけどな。 :-)
• ↓の実験の前にcvsupしたらdebug用にいじっていたcodeが

  Checkout src/sys/dev/ata/ata-all.c
  Checkout src/sys/dev/firewire/sbp.c

  と上書きされてしまった。 ちょっと悲しい。 多分ないと思うけど、もう一度同じことがあると悲しいので、backupとっておこう。
• 3.5"HDDはいーるKIT DUALだけど、どうもFreeBSD5Rでうまく使えない。 内蔵HDとの相性問題かも、ということで、現在、繋いで実験しているHitachi Global Storage Technologies HDS722516VLAT20からMaxtor DiamondMax D540X-4D (4D060H3)に交換して挑戦しようかと思ったけど、現在PCが作業中なので、やっぱりpanicになると悲しいから、もうしばらくしてからだな。

2004年11月19日

• 帰宅時室温19.5度。 とうとう20度を割ってしまった。 でも1時間PCに向かっていたら20.5度まで上がった。
• いつのまにやらGoogleのPageRankが+1されて4点になったみたい。 確かに、去年の同時期よりは体感でlog fileが3割増しぐらいになっている気がする。
• なんだかいつのまにやらY!JでSCIS2005を検索しても見つからなくなっているじゃん。 何だかなぁ。 ということで部屋はもう無くなりつつあるようだから注意。
• RSS提供して欲しいサイト。 うーん。 RSSというキーワードをここ1年ぐらい前から聞き始めて、どういう機能のものかという雰囲気は1カ月ぐらい前に知ったんだけど、そんなに便利なものなのか？ 提供するのも、楽にできるもんならしていいんだけど、そもそも自分で便利に思わないんだったら、そこまで人のためのことは考える気ないし。 ここの落書もあとでリンクを探したりとか、どうしたら解決したっけというのを自分のためだけにgrepして探したりしているののもとを書き留めているだけだからなぁ。 それなら公開しなくてもいいじゃん、という意見も当然あるけど、自分で外から見たいこともあるし、パスワードとか面倒だし、意見を貰ったりすることもあるしで。 そう簡単に手をつけるとは思わないけど、とりあえず作業リストにRSS配信というのも入れておきます。 まぁでも優先順位としては早くても
  1. IEEE1394 storage問題の解決。
  2. hot swap PCの購入&設定。
  3. FreeBSD5RのATA slave diskが遅い問題の解決。
  の次だな。 んで、はい、私はHTMLじか書きです。
• リンク集(翻訳・辞書)。
• あれ？ こんな時間帯なのに、低チャンネルの画像が滅茶苦茶乱れるぞ。 うーん。 やっぱり理由不明。
• 停電が思ったより早く終った。 10:05〜10:25というところか。 ということで、早速PCの起動、videoデッキの録画予約など設定。 あれ？ ついでにいろんな時計を正確に設定しようかとしたらntpdが立ち上がっていないので「/etc/rc.d/ntpd restatr」はいいんだけど、どうも最近、チャンと立ち上がらないことが増えた気がする。 今回はPPP connectionもチャンと自動で確立しているのに…

2004年11月18日

• FC'05 accepted papers。
• またまたIEEE1394 storage実験:
  • 問題切り分けのためのパッチを頂いたので当てて再起動。
  • 順調に(?)panicしたけど、立てた仮説の検証までは行かなかったような気がする。
• 明日の停電に備えて準備。
• RC5-72 challenge0.162%突破。 昨日のペースだと全空間探索にあと762年。 3年4倍で解読速度が向上するとすると27年。
• 運よくfirewire storageを接続してpanicしなかった時の実験で、書き込みをしながら「fwcontrol -R」したときUSB1.1接続の時ほどは「fwohci0: IR DMA overrun (0x40008011)」が起きなかったんだけど、ちょっとはやっぱり起きるみたいだ。
• 最近また1chとか低チャンネルの番組のnoiseが出るようになった気がするので、調べたらどうもvideoに使っている方の方にはほとんどノイズが出ていないことが判明した。 どうもビックカメラから買った2SS2W-BCとか2SL2W-BCの性能がかなりいいようだ。 その後にかったHP-7Aとか書いてあるのはうちの環境ではイマイチみたい。 将来的にはもう一本ビックカメラから買うことにして、 現状はとりあえず繋ぎかえてしのぐか。

  現在: アンテナコンセント ←2SL2W-BC→ ビデオ ←2SL2W-BC→ KW-TV878R-PRO III/M-P + アンテナコンセント ←HP-7A→ GV-MVP/IDV

  変更: アンテナコンセント ←2SL2W-BC→ ビデオ ←HP-7A→ KW-TV878R-PRO III/M-P + アンテナコンセント ←2SL2W-BC→ GV-MVP/IDV

2004年11月17日

• 3時間の番組を録画しようと思ったら、作業領域に40GBぐらいは準備しておかないと不安だ。 うーん。 どれを消して空けようか。 早く外部storageが何とかならないと近い将来に破綻するな。
• IEEE1394 storage、また実験:
  • 実験用にIEEE1394 cable (IE3C-661LG)を買ってきた。 もともとついていたcableはGV-MVP/IDVに不可欠になってしまったので。
  • とりあえず「panicしなくなるかも？」パッチを頂いたので、当ててkernel再構築。 どうも、タイミングによってはNOVAC HDが容量の嘘をついているらしい。
  • 残念ながら、容量の不整合を食らったらやっぱりpanicした。
• SITA2004アドバンスプログラム。
• gooから独自(?) robot gazzがやってきた。 Googleとの提携はどうなったのかな。
• 近所の公園からゴミ箱が撤去されていた。 時代の流れかな。

2004年11月16日

• mozillaからPDFが見えない問題。 Xwindow systemが終ったら、mozillaのmessageがconsoleに出ていることを発見。

  LoadPlugin: failed to initialize shared library /usr/local/Acrobat5/Browsers/intellinux/nppdf.so [Shared object "libc.so.6" not found, required by "nppdf.so"]

  • ということでnppdf.soをrenameしてみる。 変化無し。
  • mozillaを再起動する。 applicationがないとか騒ぐ。
  • 単にhelper applicationで、システムの初期設定を止めて、acroreadを呼ぶようにすれば問題は解決した。 なんか虚しい。

2004年11月15日

• なんか最近mozillaからpdfを見るとacroreadが固まって不便だったので、/etc/libmap.confを見るといつの間にやら以前comment outしたはずのacrobat reader関係の行が戻っている。 改めてcomment outしたら…単に起動しなくなったぞ。 まぁ固まるよりはいいか。
• crash dumpのファイルが毎回実メモリの大きさの1.5GBも出来るということで、昨今、diskが溢れるかと思ったけど、あんまりdiskを食ってない。 穴空きファイルなのかな。 実際にcrash dumpする時は、全部書いているみたいなので、savecoreが賢いということで。
• 起動時に「/etc/rc: WARNING: named chroot: /etc/namedb is a directory!」と怒られる問題。 とりあえず/etc/namedをrenameしたが、 まだ「named: extra command line arguments」と怒られる。 いつのまにやら-g optionがnamedから無くなっていたらしい。
• IEEE1394 storage実験また再開:
  • crash dumpが取れないのの直すパッチを教えて貰ってまずそれをあててみた。 んで、OS再起動。
  • んでpanicしたあとのbackground fsckを待つ時間をなるべく減らしたいので、OSを動かしておくのに関係ないad1を外しておいて実験。
  • 5〜6回、IEEE1394 storageの電源off/onなどを繰り返したけど、さっぱりpanicの兆候無し。 んで、もしかしてad1が関係するのかと思ってmountしようとしたらpromptが返ってこない。 やっぱり何かおかしい。 Ctrl-Cで中断して、 IEEE1394 diskをmountしようとしたらこっちはこっちで/devに必要なファイルが出来ていない。 うーむ。 という状態で、もう一度ad1のmountに挑戦すると、「device busy」。 そうでっか。
  • この手のことをいくつか試したけど回復の兆候無し。 諦めて「shutdown -r」。 れれれ？ syncが終った後、全然先にいかないんですけど… 2分ほど待って変化無しなので諦めてreset。
  • くー。 やっぱりfsck必要ですか。
  • んで、今度はad1がmountされている状態で実験した所、3度目ぐらいにチャン(?)とpanic。 crash dumpも取れた。 が、取り終った後「db>」のpromptが出たので何気なく復改を押してしまったらそのまま固まってしまったので、reset。
  • よしよし「dmesg -a」で見るとチャンとsavecoreしているぞ。 あれ？ なんかnamedが起動していないな。 これは後回し。 というか、PPPはチャンと立ち上がっているな。 昨日立ち上がらなかったのは何故なんだろう？ まぁこれも後回し。 というか、直ったと思うことにしよう。
  • おや？ ちょっとhttpd-access.log壊しちゃったか？ 例のナゲーSEARCH methodの後ろがCtrl-@で埋まっている…
  • uniprocessor kernel (UP kernel)に変更してreboot。
  • 3度目ぐらいのIEEE1394 storageの電源off/onで、やっぱりpanic。 SMP特有の問題ではないらしい。 とりあえずSMP kernelに戻すか。 もう一度、ad1実験をする？ うーん。 結構panicしてcrash dump取るのって手間かかるんだよなぁ。 とりあえず続きは明日ということにしよう。
• IEEE1394 storage実験再開:
  • customized kernelでpanicしたのはbuild中に中断して、makeしなおしたりしたのが問題かもしれないので、もう一度、普通の方法(最近はtraditionalとかいうらしいが)config→「make depend」→make→「make install」で実験。 今度はチャンと上がった。
  • 5.3Rでは起動のメッセージで「何か立ち上げた」はあんまりださないのね。 ありゃ？ IPv6捨てるとntpdってcore吐いて落ちるの？？？ とりあえずIPv6 addressをもっているserverをntp.confから外して「sh /etc/rc.d/ntpd start」。
  • よしよし。 今度は何もしなくてもチャンと音が鳴るぞ。 bktr deviceも大丈夫。 SMPもうまくいってhyperthreading出来ているみたいだ。
  • さぁ。 これでNOVACを繋ぐとどうか？ ドキドキ。 そっか、panicに備えてXは落しておくべきか。
  • 一回目実験:

    Nov 15 00:41:20 flu kernel: fwohci0: BUS reset
    Nov 15 00:41:20 flu kernel: fwohci0: node_id=0x8800ffc0, gen=3, non CYCLEMASTER mode
    Nov 15 00:41:20 flu kernel: firewire0: 2 nodes, maxhop <= 1, cable IRM = 1
    Nov 15 00:41:21 flu kernel: fwohci0: txd err=14 ack busy_X
    Nov 15 00:41:21 flu kernel: fw_asybusy
    Nov 15 00:41:22 flu kernel: fwohci0: txd err=14 ack busy_X
    Nov 15 00:41:22 flu kernel: fw_asybusy
    Nov 15 00:41:23 flu kernel: fwohci0: txd err=14 ack busy_X
    Nov 15 00:41:23 flu kernel: fw_asybusy
    Nov 15 00:41:24 flu kernel: fwohci0: txd err=14 ack busy_X
    Nov 15 00:41:24 flu kernel: fw_asybusy
    Nov 15 00:41:25 flu kernel: fwohci0: txd err=14 ack busy_X
    Nov 15 00:41:25 flu kernel: fw_asybusy
    Nov 15 00:41:26 flu kernel: fwohci0: txd err=14 ack busy_X
    Nov 15 00:41:26 flu kernel: fw_asybusy
    Nov 15 00:41:27 flu kernel: fwohci0: txd err=14 ack busy_X
    Nov 15 00:41:27 flu kernel: fw_asybusy
    Nov 15 00:41:27 flu kernel: firewire0: max_asyretry exceeded
    Nov 15 00:41:27 flu kernel: firewire0: bus manager election failed
    Nov 15 00:41:28 flu kernel: fwohci0: txd err=14 ack busy_X
    Nov 15 00:41:28 flu kernel: fw_asybusy
    Nov 15 00:41:28 flu kernel: firewire0: max_asyretry exceeded
    Nov 15 00:41:28 flu kernel: firewire0: bus_explore node=1 addr=0x400 resp=16 retry=5
    Nov 15 00:41:28 flu kernel: firewire0: bus_explore failed for 1 nodes
    Nov 15 00:41:30 flu kernel: fwohci0: BUS reset
    Nov 15 00:41:30 flu kernel: fwohci0: node_id=0xc800ffc1, gen=4, CYCLEMASTER mode
    Nov 15 00:41:30 flu kernel: firewire0: 2 nodes, maxhop <= 1, cable IRM = 1 (me)
    Nov 15 00:41:30 flu kernel: firewire0: bus manager 1 (me)
    Nov 15 00:41:30 flu kernel: firewire0: New S400 device ID:0030e00e8200a011
    Nov 15 00:41:32 flu kernel: da0 at sbp0 bus 0 target 0 lun 0
    Nov 15 00:41:32 flu kernel: da0: < 1394 to ATA 0102> Fixed Simplified Direct Access SCSI-4 device 
    Nov 15 00:41:32 flu kernel: da0: 50.000MB/s transfers
    Nov 15 00:41:32 flu kernel: da0: 157066MB (321672960 512 byte sectors: 255H 63S/T 20023C)
    

    なんか、グダグダ騒いでそれなりに時間がかかるけど うまくいったみたい。
  • mountとか書き込みとかそれなりに操作して順調。 んで、一度電源off/onすると…

    Nov 15 00:45:44 flu kernel: fwohci0: BUS reset
    Nov 15 00:45:44 flu kernel: fwohci0: node_id=0xc800ffc0, gen=5, CYCLEMASTER mode
    Nov 15 00:45:44 flu kernel: firewire0: 1 nodes, maxhop <= 0, cable IRM = 0 (me)
    Nov 15 00:45:44 flu kernel: firewire0: bus manager 0 (me)
    Nov 15 00:45:57 flu kernel: fwohci0: BUS reset
    Nov 15 00:45:57 flu kernel: fwohci0: node_id=0xc800ffc1, gen=6, CYCLEMASTER mode
    Nov 15 00:45:57 flu kernel: firewire0: 2 nodes, maxhop <= 1, cable IRM = 1 (me)
    Nov 15 00:45:57 flu kernel: firewire0: bus manager 1 (me)
    Nov 15 00:45:58 flu kernel: fwohci0: txd err=14 ack busy_X
    Nov 15 00:45:58 flu kernel: fw_asybusy
    Nov 15 00:45:59 flu kernel: fwohci0: txd err=14 ack busy_X
    Nov 15 00:45:59 flu kernel: fw_asybusy
    Nov 15 00:46:00 flu kernel: fwohci0: txd err=14 ack busy_X
    Nov 15 00:46:00 flu kernel: fw_asybusy
    Nov 15 00:46:01 flu kernel: fwohci0: txd err=14 ack busy_X
    Nov 15 00:46:01 flu kernel: fw_asybusy
    Nov 15 00:46:01 flu kernel: firewire0: max_asyretry exceeded
    Nov 15 00:46:01 flu kernel: firewire0: bus_explore node=0 addr=0x400 resp=16 retry=5
    Nov 15 00:46:01 flu kernel: firewire0: bus_explore failed for 1 nodes
    Nov 15 00:46:06 flu kernel: fwohci0: BUS reset
    Nov 15 00:46:06 flu kernel: fwohci0: node_id=0xc800ffc1, gen=7, CYCLEMASTER mode
    Nov 15 00:46:06 flu kernel: firewire0: 2 nodes, maxhop <= 1, cable IRM = 1 (me)
    Nov 15 00:46:06 flu kernel: firewire0: bus manager 1 (me)
    Nov 15 00:47:09 flu kernel: fwohci0: BUS reset
    

    うまくいくな。 mountとかしても問題無し。
  • 今度は電源offのあと、「fwcontrol -r」を何回か実行してda0を見えなくして電源を入れると…

    Nov 15 00:47:51 flu kernel: fwohci0: BUS reset
    Nov 15 00:47:51 flu kernel: fwohci0: node_id=0x8800ffc0, gen=12, non CYCLEMASTER mode
    Nov 15 00:47:51 flu kernel: firewire0: 2 nodes, maxhop <= 1, cable IRM = 1
    Nov 15 00:47:52 flu kernel: fwohci0: txd err=14 ack busy_X
    Nov 15 00:47:52 flu kernel: fw_asybusy
    Nov 15 00:47:53 flu kernel: fwohci0: txd err=14 ack busy_X
    Nov 15 00:47:53 flu kernel: fw_asybusy
    Nov 15 00:47:54 flu kernel: fwohci0: txd err=14 ack busy_X
    Nov 15 00:47:54 flu kernel: fw_asybusy
    Nov 15 00:47:55 flu kernel: fwohci0: txd err=14 ack busy_X
    Nov 15 00:47:55 flu kernel: fw_asybusy
    Nov 15 00:47:56 flu kernel: fwohci0: txd err=14 ack busy_X
    Nov 15 00:47:56 flu kernel: fw_asybusy
    Nov 15 00:47:57 flu kernel: fwohci0: txd err=14 ack busy_X
    Nov 15 00:47:57 flu kernel: fw_asybusy
    Nov 15 00:47:58 flu kernel: fwohci0: txd err=14 ack busy_X
    Nov 15 00:47:58 flu kernel: fw_asybusy
    Nov 15 00:47:58 flu kernel: firewire0: max_asyretry exceeded
    Nov 15 00:47:58 flu kernel: firewire0: bus manager election failed
    Nov 15 00:47:59 flu kernel: fwohci0: txd err=14 ack busy_X
    Nov 15 00:47:59 flu kernel: fw_asybusy
    Nov 15 00:47:59 flu kernel: firewire0: max_asyretry exceeded
    Nov 15 00:47:59 flu kernel: firewire0: bus_explore node=1 addr=0x400 resp=16 retry=5
    Nov 15 00:47:59 flu kernel: firewire0: bus_explore failed for 1 nodes
    Nov 15 00:48:01 flu kernel: fwohci0: BUS reset
    Nov 15 00:48:01 flu kernel: fwohci0: node_id=0xc800ffc1, gen=13, CYCLEMASTER mode
    Nov 15 00:48:01 flu kernel: firewire0: 2 nodes, maxhop <= 1, cable IRM = 1 (me)
    Nov 15 00:48:01 flu kernel: firewire0: bus manager 1 (me)
    Nov 15 00:48:01 flu kernel: firewire0: New S400 device ID:0030e00e8200a011
    

    ぐー。 「options DDB」がチャンと効いてkernel debuggerに落ちてしまった。 やっぱダメか。 ということで、traceしてpanicして… おや？ 全然diskに書き出してくれないんですけど…
  • 仕方なくそのままreset。 おいおい。 今度はPPP接続出来ませんか？ 何が起きているんだ？？？ かんべんしてよ… というのは、2分ぐらい待ってからpppを起動し直したら何とかなった。
  • さて、もう一度実験をしてcrash dumpをとりたい所だが、background fsckが終るのを待とう。 その待っている間、/etc/rc.confとかonline manualとか確認したけど、5.3Rでcrash dumpの作り方が変わったとは思えないんだよなぁ。 もう一度実験してみるか。
  • 今度は、panicするまで4回ほど電源off/onがいった。 のはいいけど、やっぱりcrash dump作ってくれないんですけど… んで、resetして、またpppが起動しないのは、/varのfsckを待っていたりするのかな？
  • 今日は夜もふけてきたので、この辺までにしよう。

2004年11月14日

• なんか今日、またNHKの画質悪いなぁ。 アンテナcable交換して以来だいぶましにはなったけど、やっぱり変な信号を送っている奴がいるんだろうな。 んで、mencoder -tv driver=bt848の方の録画、なんか滅茶苦茶。 設定周波数が変わったみたい。 「mplayer tv://1」とかで、チャンネル変更効かないし、また周波数を調べるの面倒だなぁ。 んで、調べたところ 「mplayer tv://16 -tv chanlist=japan-bcast」とかで大体あっているみたい。 ということで、正常になったのかも。 録画予約scriptのbt878 cardの方のを直しておかねば。
• とりあえずvideoとして使っている間、アニメダイエット。 んで、mplayerを使ったんだけど、 早送りとかの反応が速くなっていた、というか以前使い始めた頃の速度に戻っていた。 5.3Rいいかも。 あと、うっかり「fwcontrol -R」中に2GBほどファイルを消してしまったけど、syncでDMA overrunを食らわなかった。 たまたまなのか、これくらいなら大丈夫になったのかは分からないけど。
• GV-MVP/IDVの無反応問題が片付きIEEE1394 disk計画再開:
  • FreeBSD5.3RではIEEE1394のcodeも結構変わったということで、まずはOSのversion up。 某所での経験を生かしてkernel configファイルをあらかじめ5.3RのGENERICからcustomizeしたものを作っておく。 んで「make buildkernel KERNCONF=FLU」している途中「『options DDB』を有効にするには『options KDB』を入れろ」と怒られて、それをしてkernel作り直している途中に、何故か音関係のを入れ忘れたのを思い出せてやり直し。 今回のversion upは、結構違うところがあるみたいでsingle user modeのmergemasterが要るみたいだから結構時間かかりそう。
  • とりあえずいつものようにGENERIC kernelを/boot/kernel.oldにいれて、customized kernelで起動しようかと思って、「make installkernel」して、「make installkernel KERNCONF=FLU」としてreboot。
  • なんか「/」のmountをしたあと数分待っても進まないんですけど… 直前にIEEE1394の「New S400 deviceID:xxx」というのが出ているので、 また1394で調子悪いのかと思って、GV-MVP/IDVの電源offしても 通常のbus resetのmessageが出るだけで全然状況変わらず。 Ctrl-CとかCtrl-Zとかも効かないし。 んで、とりあえずGV-MVP/IDVが動いていない状態なら立ち上がるかと思ってその状態でreset。
  • 全々状況変わらず。 もう一度resetして、今度はやったこと無いんだけどsafe modeとかいうのを選んで起動を試みるもpanic。
  • 今度はACPI disabledで起動を試みるもpanic。
  • GENERIC kernelで立ち上げようかと思って、まずloader promptに落して、unloadして、「load boot/kernel.old/kernel」して「boot -s」に挑戦。 あれ？ 5.2.1Rなんだ。 まぁまだinstallworldしていなからどっちでもいいんだけど。 で、やっぱりpanic。 そろそろかなり焦りが… 元に戻せるかもどうかも自信無くなってきた。
  • よく起動時のmessageを見ているとacpi.koを新しいのを使っているのがいけないようだ。 ということで、loader promptで「unload」「load boot/kernel.old/kernel」「load boot/kernel.old/acpi.ko」して「boot -s」。 ようやく立ち上がった。 ひと息つける。
  • んで「mount -a」して、「make installkernel」で、5.3RのGENERIC kernelをいれる。 今度はacdの認識の後10秒ぐらい止まったので、ちょっと焦ったけどチャンとsingle user modeで立ち上がった。
  • 「mergemaster -p」「make installworld」と順調に進み、「mergemaster」。 なんかたくさん聞いてくるので、よく見ずちょっと手がすべって先へ進んでしまって「しまった」と思った所もあったけど、致命的でなく20分ほどかけて作業終了。
  • んで、reboot。 順調に立ち上がって、とりあえず安心。 しかし、まだkernelのreconfigとか残っているから完全回復ではない。 まぁまずは音楽でも聞きながら… 「mpg123 -v track1[56]*」するも「/dev/dsp: No such file or directory」。 あ、そうか。 GENERIC kernelだからないのね。 とりあえず「kldload sound」「kldload snd_ich」で聞けるようになった。
  • んで、まずはmergemasterでvi苦手だということで、ほっておいたファイルの整形。 できた。
  • 外からメールは届くか実験。 よし届くようだ。 HTTPはどんどんlogが成長するから見えているんだろう。
  • dmesgで何か不審なものが出ていないかどうかチェック。 ん。 NTPdがIPv6のaddressで通信しようとしているな。 まぁこれはcustomized kernelになれば解決するだろう。 そっか、SMP kernelがdefaultじゃないのでhyperthreadingも使えていないのか。 まぁこれもそのうち解決ということで。 んsioの認識でしくじっているな。 まぁ当分modemとかも使わないだろうし、解決は後回し。
  • なんか次の録画予約時間が近付いてきたぞ。 20分弱でkernel関係のを何とかする自信が無いので、続きは後回しだな。 本質的なIEEE1394 storageの実験までは始められなかった。 残念。
  • とりあえずGV-MVP/IDVが使えるかどうか確認。 おや？ fwcontrol出力形式が変わっているのね。 頭に0xつけて、そのままcut&pasteでは使えなくなってしまった。 チャンネル変更コマンドに対するlogも「Unknown service addr 0xffff:0xf0000d00 WREQB(1) src=0xffc0 data=d00」とか見ためが変わっている。 が、問題無くチャンネルも変えられたし「fwcontrol -R」も出来た。 よかった。
  • kernel.oldは念のためkernel.521 にrenameして、kernelもkernel.GENERICとして上書きしても大丈夫なように残しておこう。
  • とりあえずbt878の方をtemporaryに使えるようにしよう。 「kldload bktr」。 なんか、認識してくれたようだ。 fxtvすると… 全然ダメじゃん。 そっかsysctlすればいいのかな。 でも、もうそんな数字覚えとらんぞ… kernel config fileと/sys/dev/bktrをごそごそ探って… 「sysctl hw.bt848.card=2 hw.bt848.tuner=4」らしい。 よし。 fxtvでチャンと見えた。

2004年11月12日

• RC5-72 challenge0.160%突破。 昨日のペースだと全空間探索にあと780年。 3年4倍で解読速度が向上するとすると27年。

2004年11月9日

• GV-MVP/IDVの連続運転試験。 そろそろ丁度2週間の安定運用突破かな。 「勝利宣言」ということで。 4.5カ月に渡る長い戦いもようやく集結。 それはいいんだけど、USB1.1経由ででかいデータを移動している時に「fwcontrol -R」していたら「fwohci0: IR DMA overrun (0x40008011)」を大量に食らってしまった。 1MB/sしか出ないので、ATAの33MB/sに比べてゴミなので、影響ないかと思って放置して敗北。 最初はoverrun出す理由が全然分からなかった。

2004年11月8日

• しまった。 一度洗った空き缶をもう一度洗ってしまった。 明日のゴミだしまでに乾きそうにないなぁ。 ちょっと室内空き缶置場の工夫が必要だな。
• RC5-72 challenge0.158%突破。 昨日のペースだと全空間探索にあと819年。 3年4倍で解読速度が向上するとすると27年。

2004年11月7日

• OZ完全収録版。 宣伝によると、結構加筆部分があるそうなので、買おうかどうしようか悩んでいる。
• FreeBSD5.3R。
• 今日の最高気温は21度だったみたいだ。 今日の最高室温は27.5度。 27度まで下がってからだけど、窓を開けて1時間ぐらいしたら26度まで下がった。 最近は、近所に歩きタバコをする人がいなくなったので、安心して窓を開けていられるのが嬉しい。
• 「mencoder -ss」で頭の方を落すことも出来た。 前出来なかったと思ったのはなぜだろう。 それともversion upして出来るようになったんだろうか。
• なんかweb browserで向うが知らないはずの情報を知っているので不審に思ったらmozilla-jlpをportupgradeしたときにcookieの設定が緩んでいた。 うーむ。
• SASCの発表資料がずいぶん載っていた。 (情報from W氏)

2004年11月5日

• 舞HiME第6話。 なんか、またとれていないようだが、どうなっているのや？ GV-MVP/IDVはチャンと生きているみたいだから、録画予約scriptのbugなんだろうな。 「lastcomm -f /var/account/acct.0」によるとちゃんとcommandは起動していたみたいだから、間違って成果ファイルが消されたのかもしれない。
  • ちょっと短いデータで他はほぼ同じパラメータで実験。 うまくいくじゃん。
  • ということは… あ、DVの頭にゴミ(?)がついた場合mencoderが失敗するはずなんだけど、その確認をするコードが消滅していて、ファイルを消していたみたい。 実際mencoderが終ってすぐrmが起動されていたとaccounting fileには残っていた。 1-pass encodingの時はチャンと処理していたんだけどなぁ。
  頭のゴミを自動的に削るcodeを書くのも近い将来の課題だな。

2004年11月4日

• 録画予約script、ファイルの上書き防止機能と、fwcontrolが動いている時のデカいファイル消すの待ち機能をつけた。 とりあえずencodingスケジューリングを考えずにどんどんmencoderを実行させていってみたが、3つ並列に動いている時にも「fwohci0: IR DMA overrun (0x40008011)」を食らうことはなかった。 UltraATA33 cableのままでも大丈夫かもしれない。
• 久しぶりに魚の骨をはぐきに立ててしまったようだ。 痛い。 つみれということで、油断したのがいけなかったようだ。

2004年11月3日

• ようやく録画データの整理がついた。 TV録画予約scriptのversion upをするか。

2004年11月2日

• ようやくOSとかportsが最新の状態になった。 /etcとかbackupせねば。
• mozilla-jlpをportupgradeしたらなんかfontが大きくなった。
• NFSNETの5_304Pの篩が終ったようだけど、こんどはスムーズに次の分解にうつれるんだろうか。

2004年11月1日

• DMA2004プログラム (PDF)。 どんな感じなのかな。
• たまたま分かったのだが、どうも10/16のsystem downは4:40am頃に起きたらしい。 だからどうだというわけでもないけど。
• RSA labもMD5とかの衝突騒ぎに関するコメントを出していたのね。
• Workshop on Provable Securityのプログラム。
• いつものnotification schedule (11月まで):
  8/16 CT-RSA'05, 11/1 FC'05

今月の日記

日本語ホーム頁に戻る

本ページの主張等は著者の所属組織に全く関係なく、個人としてのものです。