ttt: 5月 2008

2008年5月31日土曜日

とさっ子みょうがちゃん (3)

20080530

みょうがちゃんと、・・・かわうそ？みたいです。

ところで、このシールの裏に、「みょうがちゃんのとっておきレシピ」というものが載っていることに、ようやく気がつきました。

■ 過去記事

とさっ子みょうがちゃん (2)

20080528

とさっ子みょうがちゃん

20080514

2008年5月30日金曜日

05月30日のココロ日記(BlogPet)

飼育当番で白い最終にえさをあげました。ココロにすりすりしてくれました。

*このエントリは、ブログペットのココロが書いてます♪

社長島耕作、いきなり言い間違い？！

200805291

今日発売の週刊モーニングから、とうとう「社長島耕作」へ、作品のタイトルも変わりました。

物語は、島耕作が、カメラの前で、全世界の社員に向けて演説をするところから始まるのですが・・・

200805292

この上のコマで言ってる

「ペレストロイカ体制」

って、もしかして、

「トロイカ体制」

の間違いじゃないですか？

HGホールディングス（の島社長）

初芝電産の松橋社長

五洋電機の勝浦社長

という「3名」によって会社を運営するってことを言っていますし、3人のリーダーがいるってのは、やっぱりトロイカ体制のことですよねぇ？？？

たしか、トロイカってのは、３頭立ての馬車とかのことですよね。

一方、ペレストロイカってのは、ゴルバチョフのときソ連で行われた「改革」って意味の活動のことですよね。

トロイカ体制という言葉は使いますけど、ペレストロイカ体制っていう言い方、あまり聞かないような気がします。

それとも、最近、そういう経済用語があるんでしょうか。

2008年5月29日木曜日

とさっ子みょうがちゃん (2)

20080528

別の絵柄の「みょうがちゃん」を見つけました。

・・・鍋焼きうどん？でしょうか。
最初、ラーメンかと思いました。

とろろ昆布、刻んだみょうが、しょうゆ少し。これにお湯かける。
早くて、うまいぞぉ

■ 過去記事

とさっ子みょうがちゃん

20080514

2008年5月28日水曜日

(FreeBSD) 最近のxorg、調子悪いとこありますよね（笑）

FreeBSDだけの話なのかどうかは知りませんが、最近のxorgって、調子悪いとこありますよね。まあ、Xサーバがやたらと落ちるとか、そこまでひどいってわけでもないですけど（笑）。

私自身で使っている範囲内では、どうもキーボードまわりが、なんか変だなぁ・・・、ってことが多いです。
$HOME/.xsessionとかで実行したxmodmapが効かない、っていう有名な症状もありますし。

☆

仕事場では、周囲はWindowsだらけの中、私は、仕事の内容の都合で、FreeBSDじゃなきゃ仕事にならないので、Windowsは使わず、すべてFreeBSD。
というわけで、OpenOffice.orgなぞを使っているんですけど、先日はじめて気がつきました。

20080527

ファイルを開くときのショートカットキーが、

Caps_Lock + O

えー？！　Caps Lock ???

Caps Lockと左Controlを入れ替えているんですが、おそらく、そのせいでしょうかね。

2008年5月27日火曜日

なんとなくレッサーパンダ

土曜日に、なんとなく、レッサーパンダを見てきました。

写真がものすごくピンボケだったり

200805261

謎の生物みたいに写ってたりするのは

200805262

私の写真の腕が悪いからです。

こいつ、ものすごく落ち着きがなくて、常に、ウロウロ歩き回っていて、しかも、外は曇り、建物の中にいて、その中も薄暗い、そんな悪条件がそろってしまっていて、きれいに写りませんでした。

200805263

☆

レッサーパンダは、英語だと、lesser pandaだそうです。
lesserといえば、ソフトウェアのライセンスの「LGPL」の最初のLですが、LGPLは、「劣等GPL」とか呼ばれたりもします。

えー？「劣っているパンダ」って意味なのですか！と思ったら、小さいパンダっていう意味なんだそうで、安心しました。

2008年5月26日月曜日

今日のコードギアス

今日の「コードギアス　反逆のルルーシュＲ2」を見て思いました。

ルルーシュは、一休さんなのだ、と。

20080525

そういえば、一休さんも、元々は高貴な家の出身で、今はいろいろあって寺で修行中、とんちで、将軍さまをやっつけたりする・・・

☆

コードギアス　反逆のルルーシュＲ2は、ネットで無料配信されているそうなので、今日の放映分も、今日の24時以降、視聴できるんだと思います。

http://anime.biglobe.ne.jp/geass/

2008年5月25日日曜日

帰ってきた「アルフォンソマンゴー水」

よくわかんないですけど、今、マンゴーが旬な時期なんでしょうか。マンゴーなものが増えていました。

あ

200805241

去年気に入ってた「アルフォンソマンゴー水」が、また売ってた！！

☆

ほかに・・・

200805242

ビッギーマンゴー

ビッギーという乳酸菌飲料があるんだそうで・・・。
メーカーは、日本ルナというところだそうで・・・。
知らなかったです。
ルナちゃん、微妙。
http://www.nipponluna.co.jp/lunachan/index.html

2008年5月24日土曜日

(FreeBSD) ports/japanese/grepのエラー～ acinclude.m4:463: error: m4_defn: undefined macro: _m4_divert_diversion / autom4te-2.62: /usr/local/bin/gm4 failed with exit status: 1 / aclocal-1.10: autom4te failed with exit status: 1

ふと、FreeBSDのportsで、japanese/grepがビルドできないことに気がつきました。

ビルドしようとするFreeBSDによって（どんなツール類がインストールされているかによって？）、エラーメッセージが微妙に異なるらしいのですが、あるところでは、こんな感じでした。

===> Building for ja-grep-2.4.2
cd . && aclocal
acinclude.m4:3: warning: underquoted definition of AC_DJGPP
acinclude.m4:3: run info '(automake)Extending aclocal'
acinclude.m4:3: or see http://sources.redhat.com/automake/automake.html#Extending-aclocal
acinclude.m4:50: the serial number must appear before any macro definition
acinclude.m4:427: the serial number must appear before any macro definition
acinclude.m4:461: the serial number must appear before any macro definition
acinclude.m4:468: the serial number must appear before any macro definition
acinclude.m4:485: the serial number must appear before any macro definition
acinclude.m4:622: the serial number must appear before any macro definition
acinclude.m4:660: the serial number must appear before any macro definition
acinclude.m4:701: the serial number must appear before any macro definition
acinclude.m4:463: error: m4_defn: undefined macro: _m4_divert_diversion
acinclude.m4:463: the top level
autom4te-2.62: /usr/local/bin/gm4 failed with exit status: 1
aclocal-1.10: autom4te failed with exit status: 1

どうやら、aclocalを実行してエラーになる、というのは共通らしいです。

それって、automake、autoconfのバージョンの違いのせいじゃない？っていう気がして、古いバージョンのautomake、autoconfが使われるようにしてみたら、それでいけました。

まずは

make clean

しておいてから、とりあえず、

make USE_AUTOTOOLS="autoconf:213 aclocal:15"

でOK。

portsの修正方法としては、Makefileに以下の1行を追加でしょうか？

USE_AUTOTOOLS= autoconf:213 aclocal:15

☆

それにしても、portsって、とってもフレキシブルですねぇ。とりあえず、makeに引数をつけくわえるだけ、っていう実行方法でも、なんとか対応できちゃうなんて。

でも、portsの中で何をやってるのかがわかんないときは、

あーもう、本当にもう何がなんだか・・・

てイライラなときもあります（笑）。

2008年5月23日金曜日

コーヒーメロンパン

20080522

ドラえも～ん、ブログに書くネタがないよぉ
しかたないなぁ　泣く子とのび太には勝てないよ

皮はサックリ　コクと香ばしさ
コーヒーメロンパン
(ヤマザキ)

あまり甘くなくて、おいしかったです。
これでカロリーが低ければ、文句はないのですが…

ところで、本物のメロンと、本物のコーヒーは、あまり相性がよくなさそうな気がします。

☆

コーヒーといえば、先週の「美味しんぼ」。

朝日新聞で、海原雄山と山岡士郎が和解した、なんていう記事が出てたもので、びっくりしました。その前に、島耕作が社長就任という記事が出たこともあったので、朝日は、わりとサブカル方面にも手を広げているんですね。

というわけで、その問題の、美味しんぼ。ぜひ確認しようと、コンビニで雑誌をチェック。
さぞかし、大々的な扱いに・・・なってないね。
雑誌のおしまいの方の位置に掲載。とくに特集も何もないような…

話の内容も、とくに劇的に盛り上がるとうなこともなく、あっさり、淡々と。
でも、これはこれでいいと思う。巨人の星の一徹と飛雄馬じゃないんですから。

あ、それで、コーヒーの話がちょこっと載ってたんです。おいしいコーヒーの淹れ方ってことで、水出しコーヒーの変形バージョン的ものが紹介されてました。
コーヒーに水をいれてガラガラかき混ぜて、一晩置いてから、濾して飲む、と。

やってみたら、けっこうよかったです。

ただ、普通にお湯でドリップするときと比べて、後片付けがめんどくさかったです。

水で入れた場合って、フィルターにコーヒーが詰まっちゃって、なかなか落ちていかないんですね。熱いお湯だと、フィルターの目が広がるんでしょうか？

☆

このブログにメロンパンについて初めて触れたのが、3年前の5月18日らしいです。「渚のメロンパン」について。もう3年ですかぁ。

■ 過去記事

沖縄黒糖メロンパン　　期間限定5/31まで

野菜とフルーツのメロンパンサンド

マンゴーメロンパン　　チーズホイップ

クマロンパ☆メロンパン

パンプキンメロンパン

夏らしい？　～　マンゴーメロンパン　／　チーズ＋9種の野菜カレー

黒糖メロン

みんな大好きメロンパン

2008年5月22日木曜日

20080521

今夜の月は、月齢約１６
あなたも月も、１６歳（笑）

HAPPY BIRTHDAY

2008年5月21日水曜日

05月21日のココロ日記(BlogPet)

今日は道で懐かしい利用とすれ違いました。

*このエントリは、ブログペットのココロが書いてます♪

FACOM 230-50

TOKYO MXのミラーマンを、たまに、なんとなく、ちらっと見てるんですが、昨日のは、いつもと少し雰囲気が違って、微妙にリアル。

変わったデザインの建物

200805201

☆

昔の電子計算機の、本物のコンソール（操作卓）っぽいもの。

200805202

ちなみに、当時は、こういう感じで使ってたんでしょうか？なんか絶対違う！って気がするんけど。てゆーか、なんで白衣？

☆

本物の磁気テープ装置。いつもは、ニョロニョロでてくる紙テープくらいだけなのに。

200805203

☆

本物の1970年代テイストな女性。これはいつもそうですけど。

200805204

☆

FACOM 230-50っていうんですね。

200805205

（2008/05/22追記）てゆーか、そのオシロスコープが、場違いでしょう？！みたいにも思ったんですが・・・
大学のときの学生実験で「CPUを作る」ってのがあったんです。授業の時間だけでは、とうてい間に合わないので、持ち帰って作業を進めていたときのこと。ロジアナ（ロジックアナライザー）が手元にはなく、なぜかオシロスコープならあった。
そこで、プログラムカウンタが進まないように細工して、同じ命令を繰り返し実行するようにして、そのときの信号の波形をオシロスコープで観察しながら、回路のデバッグをしてました。

☆

いつもは、こういう、どうしょうもないショボいセットなのに・・・

200805207

今回は、どっかにロケに出かけていったんでしょうかね。

☆

ところで、ミラーマンによく出てくる、スクリーンのようなもの。

200805208

手書きの、わりとチャチぃものだったんですね。

そういえば、先日見たスタートレックでも、宇宙船内のモニタスクリーンみたいのが、しわが入ってたるんだして、実は絵が貼ってあるだけだった、とバレちゃってました。

☆

ウィキペディアによれば、「侵略者撃破計画　改造怪獣ギランダー登場」は、1972年10月29日が初回放映の第47話。
あ、もうすぐ最終回なんだ。

☆

というわけで、FACOM 230-50ってのを、ちょっと検索してみました。

写真
http://museum.ipsj.or.jp/computer/main/0005_win02.html

写真
http://homepage2.nifty.com/Miwa/Gallery1/fujitsu.html#F230-50

関係者による回顧記事
http://homepage2.nifty.com/Miwa/5_FONTAC/index.html#(4)
http://homepage2.nifty.com/Miwa/6_F230-60/6_2.html

計算処理の性能は、4MHzの、64kword、・・・うーん、そういうものなんですね。

FACOM230-50が完成したのは、1966年3月だそうです。
性能は、他とくらべて、ちょっとおとる、っていう感じで、ソフトウェアの互換性とかで、ちょっと問題ありだな、というところはあったものの、銀行オンラインシステムなどで、導入されていたそうです。

大学のときの授業では、チャネルっていう言葉が教科書に出てきても、MCA（マイクロチャネルアーキテクチャ）？（笑）なんて想像しかできなかったんですけど（せいぜいPC-9801のDMAみたいなイメージ）、こういう大型のコンピュータで、チャネル装置ってのがあったんですね。

☆

FACOMは微妙に違いますが、昔のコンピュータ、っていうか電子計算機？、名前が、「***AC」というように、最後が「AC」となるものが多いんだとか、誰かエラい人が語ってました。

ACは、Automatic Computerかな？とうろ覚えだったんですが、違いました。

すぐに思い浮かぶのはEDSACなんですが、

Electronic Delay Storage Automatic Calculator

あと、世界初のコンピュータと言われることがあるけど、どうもアーキテクチャが後のものとぜんぜん違うし、世界初じゃねーんじゃねーの？と言われることも多いENIAC。これは

Electronic Numerical Integrator and Computer

あぁ・・・なんかどうでもいい感じのACですね。

☆

私自身、こういう昔のコンピュータ、見たことさえないんですが、なんかロマンというか懐かしさというか、そういうものを感じてしまいます。経験したことがないのに、なぜか懐かしい。

ちょうど同じ日に、NHK BS2でやってたカウボーイビバップが、スペースシャトル　コロンビア号が登場しちゃうエピソードだったんですけど（それに先週は、ビデオのβの話だったし…）、あんな感じのノスタルジックなところ、好きだなぁ。

SEE YOU SPACE COWBOY

2008年5月20日火曜日

DDR2 2GB 2枚、買ってきた

メモリの値段が上がってきて、そろそろ買っておいたほうがいいかな？と思い、とりあえず、DDR2 2GB 2枚セットのを買ってきました。

チップにELIXIRって書いてあるやつで（でもCFD）、7780円。

20080519

以前、値上がりするかも？と思って、あわてて買ったら、そのあと、もっと安くなったりしたこともありましたが・・・。今度はどうなることやら。

メモリを買うたびに思い出すのが、はじめて稟議なるものを書いて買ったメモリ。ワークステーション用の4GBのメモリでして、値段は、150万円でした。

自分で買ったもので、一番高かったメモリは、16MBの72pin SIMM、1枚で、約7万円。

☆

いつもはノーブランドのばかり買ってたんで、ブランドとかまったくわかんないんですが、ELIXIRって何？と思ったら、Nanya関係らしい。ふ～ん・・・

DRAM、HDDを買うと、CFDっていう名前を、最近とてもよく目にするんで、何かと思ったら、メルコ（バッファロー）関係なんだそうですね。台湾、中国系かと思ってました。

以前HDDを買ったら、CFDでして、なぜか、AMDのスクリーンセーバーのCDが入ってて、意味がわかんなかったです。

☆

先日読んだ、へぇ～という話。

AKIBA PC Hotline
【 2008年5月2日号】
センチュリーマイクロがメモリ解説イベントを実施、刻印や検証手法の話題も
http://www.watch.impress.co.jp/akiba/hotline/20080502/etc_mem.html

メモリチップには製造メーカーの刻印があるものとモジュールメーカーの刻印があるものがあるが、同社によると「チップ製造メーカーの刻印は、メーカー自身が品質チェックを行ない、自ら性能を保証できるものだけに入れている」という。無刻印でモジュールメーカーに出荷されているものは、チップメーカーがチェックしていないものや、品質基準を満たさないと判断されたもので、チップメーカーの品質保証が無いものという。

そういうものですか。

・・・どうでもいいけど、今、はじめて知りました。

センチュリーマイクロと、センチュリーは、まったく別の会社だ、ってことを。

2008年5月19日月曜日

BS1 アナログ／ BS2 アナログ

今日、ひさびさにアキバに行って、駅の近くのあそこにいたのですが、テレビの画面を見て、

い、いっ、いつのまに！！！

と驚くことがありました。

うちに帰ってから、確認。やっぱりあります。

200805181

BS1
アナログ

200805184

チャンネルを変えてみます。

200805182

BS2
アナログ

200805185

最近、BSは、BSデジタルばっかりだったので、こんな「アナログ」なんて表示が追加されていたとは、知りませんでした。

こういうイヤガラセって、地上波アナログ放送でもやるんですよね。

BSで、先行してイヤガラセしてみよう、ってことなんですね。

アナログじゃなくて、アナロクに見えるんですが、2011年4月1日に、

BS
アナクロ

と変わってたら、そのときは笑ってあげます。

☆

自作パソコンなどでも地デジが見られるようになる、デジタルチューナーの発売がはじまりましたよね。アキバで、見ました。あちこちの店で、けっこう販売スペースを確保してるし、店頭デモもやってたり。

でも、展示や製品を見てチェックしてる人、皆無。みんな、無関心。

だってねぇ・・・あんなねぇ、制限ありまくりの、中途半端というか、もうほとんど欠陥品みたいなデジタルチューナー、誰も欲しくないですよ。

現状の製品のことをよく知ってる人は買わない

知らない人は、手出ししない

うちにあるパソコンでも、ビデオカードやディスプレイが対応していないので、買っても使えません。

200805183

2008年5月17日土曜日

(FreeBSD) PostgreSQLで、vacuumdb: vacuuming of database "..." failed: ERROR: out of memory DETAIL: Failed on request of size 573885600.みたいなエラー～解決編

前回の

(FreeBSD) PostgreSQLで、vacuumdb: vacuuming of database "..." failed: ERROR: out of memory DETAIL: Failed on request of size 573885600.みたいなエラー

についてコメントをいただきました。

maintenance_work_mem を減らせばよい

reindexすれば、インデックスのサイズが少なくなる

ありがとうございます。
それが大正解でした。

☆

教えてもらったことをベースに、試行錯誤した結果をメモっておきます。

もうすでにテーブルを複数に分割してしまったので、前回とまったく同じ環境で実行していることにならないのですが、実行結果を検討してみて、それほど大きな違いは出ないと思われたので、そのままで行きます。

■ インデックスを作成しなおす

まず、REINDEXでインデックスを作成しなおすことで、インデックスが小さくなる、という件。

やってみました。ただ、いきなり、勘違いしておかしなことをやったよ、という例。

データベース=> reindex index インデックス名;
ERROR: out of memory
DETAIL: Failed on request of size 268435456.

うーん・・・out of memoryですか。

じゃあインデックスを削除して、最初から作り直せばいい・

データベース=> drop index インデックス名;
DROP INDEX

データベース=> create index インデックス名 on テーブル名 using btree (列);
ERROR: out of memory
DETAIL: Failed on request of size 268435456.

・・・あんたバカ？

REINDEXって、今あるインデックスを残したまま、新規にインデックスを作成し、正常にインデックス作成完了したとき、従来のインデックスを新インデックスへ、つけかえるんですよね、きっと。だから、こうなるのは、当たり前。

先に、out of memory問題を解決しておきますか。

■ VACUUM ANALYZE、REINDEX、CREATE INDEXなどでのout of memoryエラーと、maintenance_work_memの関係について

maintenance_work_memは、VACUUM ANALYZE、REINDEX、CREATE INDEXなど、たまに実行したくなる、主にメンテナンス目的の処理のとき使うメモリの量を指定するものだそうです。

http://www.postgresql.jp/document/pg826doc/html/populate.html#POPULATE-WORK-MEM

http://www.postgresql.jp/document/pg826doc/html/runtime-config-resource.html#GUC-MAINTENANCE-WORK-MEM

すっかり勘違いしていたんですが、

そういったメンテナンス処理をするためのメモリが不足したからout of memoryになった

というわけではなくて、

maintenance_work_memに大きな値を指定してあった。

maintenance_work_memの値まではメモリが使えるものだ、とpostgresqlが考え、どんどんメモリを確保していった

あるところで、OSのリソース制限値に引っかかって、メモリ確保が失敗した

postgresqlは、なんだよ～、メモリが確保できないじゃないか。じゃあ、エラーにするよ

ということがおきているみたいです。

正解のやり方は、こうなのでした。

maintenance_work_memには、OSのリソース制限値未満の、そこそこの値を指定しておく。

maintenance_work_memの値まではメモリが使えるものだ、とpostgresqlが考える。これは同じ。

maintenance_work_memの値まで確保してしまったら、確保済みのメモリの範囲内で、なんとかやりくりして、処理を行う

メモリが少なくて、処理時間が増えるかもしれないけど、一応、最後まで終了する。

扱うテーブルサイズや、インデックスサイズがmaintenance_work_memより大きくたって、どうやら、ちゃんとやりくりして、処理してくれるようです。

できれば、OSのリソース制限に引っかかってエラーになった場合は、その時点までに確保済みのメモリだけで、なんとかやりくりして、処理を継続してくれればよかったのに、と思うのですが、そこまで気の利いたことは、今のPostgreSQLはやってくれないみたいです。

■ maintenance_work_memの値の変更方法

FreeBSDのportsで普通にインストールした場合ですが、initdbした後、/usr/local/pgsql/data/postgresql.confというファイルができるので、このファイルにmaintenance_work_memを指定します。

postgresql.confのコメントをじっくりと読めばちゃんと書いてありますが、postgresql.confは、postgresqlの起動時に読み込まれて、サーバが実行中のときにファイルpostgresql.confを書き換えても、反映はされません。
そして、pg_ctl reloadすれば、postgresql.confが読み込まれて、設定した値が反映される、と書いてあります。

FreeBSDの場合は、reloadしたいときは、

/usr/local/etc/rc.d/postgresql reload

でOKです。

ただし、postgresql.confで指定できるパラメータの中には、reloadでは反映されず、restartして反映されるものもあります。change requires restartというコメントがついてますね。

maintenance_work_memは、reloadするだけで反映されます。
念のため、確認済みです。

■ maintenance_work_memの値と、OSのリソース制限

FreeBSDって、デフォルトでは、OSのリソース制限として、メモリのdataサイズが512MBまでに制限されてたりします。

この場合、maintenace_work_memは512MBを指定していいのか、っていうとダメで、メンテナンス以外の処理にもメモリは使われているわけなので、１プロセスのトータルで512MBになるように、512MBからある程度差し引いた値を、maintenance_work_memに指定しなければなりません。

topやpsでみると、

# ps auxww | grep postgres | grep -v idle
pgsql 38355 40.3 11.1 417152 377344 ?? Rs 9:49PM 0:23.21 postgres: ユーザーデータベース [local] CREATE INDEX (postgres)
pgsql 57636 0.0 0.3 104744 8716 ?? Is 05PM 0:08.74 /usr/local/bin/postgres
pgsql 57638 0.0 2.6 104884 88808 ?? Ss 05PM 1:08.84 postgres: writer process (postgres)
pgsql 57639 0.0 0.2 10976 7336 ?? Ss 05PM 43:39.05 postgres: stats collector process (postgres)

普通に起動しているだけで、すでに100MB以上確保しているので、余裕をみて、256MBくらいまでなら、maintenance_work_memに指定しても大丈夫そうでした。

■ maintenance_work_memの値を、もっと大きくしたい

もっと大きくするには、OSのリソース制限を緩和してやればよいわけです。

csh系のシェルを使っているときは、limitで、現在の制限が見られます。

% limit
cputime    unlimited
filesize    unlimited
datasize    524288 kbytes
stacksize 65536 kbytes
coredumpsize unlimited
memoryuse unlimited
vmemoryuse unlimited
descriptors 7264
memorylocked unlimited
maxproc    3632
sbsize    unlimited

maintenance_work_memが制限されるのは、上記のうち、datasizeです。

なので、たとえばこれを800MBへ広げるために、「limit datasize 800m」とかやりたくなるんですが、これ、デフォルトでは不可能です。

「man setrlimit」を見ると、hard limitと、soft limit、２つの制限があるとか、あれこれ書いてあるんですが、

デフォルトのFreeBSDは、datasizeは512MBまで

と設定されちゃってます。OSが起動しちゃったら、もうこれを拡大することはできないようです。たとえroot権限でも。

じゃあどうやって広げるかっていうと、

/boot/loader.confに

kern.maxdsiz="2G"

とか書いておけば、2GBまで、datasizeを広げられるようになります。

参考

(FreeBSD) unlimit datasizeしても512MBまで？

% limit
cputime    unlimited
filesize    unlimited
datasize    2097152 kbytes
stacksize 65536 kbytes
coredumpsize unlimited
memoryuse unlimited
vmemoryuse unlimited
descriptors 11095
memorylocked unlimited
maxproc    5547
sbsize    unlimited

これでいいのかと思ったのですが、このようにkern.maxdsizに大きな値を指定しても、それでもまだ512MBまでしか増やせない、って場合があります。

それでもまだ512MBに制限されている原因はどこか？っていうと、/etc/login.confでした。

default:\
      :passwd_format=md5:\
      :copyright=/etc/COPYRIGHT:\
      :welcome=/etc/motd:\
      :setenv=MAIL=/var/mail/$,BLOCKSIZE=K,FTP_PASSIVE_MODE=YES:\
      :path=/sbin /bin /usr/sbin /usr/bin /usr/games /usr/local/sbin /usr/loca
l/bin ~/bin:\
      :nologin=/var/run/nologin:\
      :cputime=unlimited:\
      :datasize=unlimited:\
      :stacksize=unlimited:\
      :memorylocked=unlimited:\
      :memoryuse=unlimited:\
      :filesize=unlimited:\
      :coredumpsize=unlimited:\
      :openfiles=unlimited:\
      :maxproc=unlimited:\
      :sbsize=unlimited:\
      :vmemoryuse=unlimited:\
      :priority=0:\
      :ignoretime@:\
      :umask=022:

なんて感じに書かれているのが普通らしいのですが、なぜか、

:datasize=512m:\

とか書かれていたりすると、この値までに制限されるようになります。そこの値よりも大きくはできません。ただし、root権限なら、この値を超えた値に増やせます。もちろん、それでも、kern.maxdsize未満という制限はあります。

・・・で、なぜか、私がPostgreSQLを実行していたFreeBSD 6-STABLEなマシンでは、/etc/login.confで、datasize=512m と書いてありました。
cvsで確認しても、datasize=512mと書かれていた痕跡は、まったくありません。
自分で昔書き換えて、すっかり忘れていただけ？

maintenace_work_memを大きくしてみました。712MBほど、メモリを確保しています。

# ps auxww | grep postgres | grep -v idle
pgsql 63641 57.1 16.8 712308 571596 ?? Ds 11:35PM 0:08.83 postgres: ユーザーデータベース [local] CREATE INDEX (postgres)

☆

１つ余談。

man setrlimitにも書かれているんですが、setrlimitで設定されたリソース制限は、プロセスについて設定される情報だそうです。
そのため、shellのbuiltinコマンドであるlimitやulimitで値を設定しておいてから、シェルから起動されるプロセスに引き継がれるようになっている、という仕組み。

そのあとsu pgsqlすれば、512m以上のままです。

しかし、su - pgsqlすると、ログインしなおしたのと同等のことがおこるので、login.confが反映されて、もとの制限値に戻ってしまいます。

☆

もう１つ余談。

アカウントpgsql用に、/etc/login.confでlogin classを定義してやって、PostgreSQLを実行するときだけdatasizeを増やす、とかやると、なんかイイんじゃない？と思ってやってみました。

vipwで、パスワードファイルを編集。login classは、５番目のフィールドなので

pgsql:*:70:70::0:0:PostgreSQL Daemon:/usr/local/pgsql:/bin/sh

となっているのを

pgsql:*:70:70:pgsql:0:0:PostgreSQL Daemon:/usr/local/pgsql:/bin/sh

に変更。

/etc/login.confを編集して、末尾に

pgsql::datasize=2000m:

とか書き加える。

cap_mkdb /etc/login.conf を実行して、/etc/login.conf.db を作成。

これでいいかと思ったら、思わぬ落とし穴。
dailyで実行される/usr/local/etc/periodic/daily/502.pgsql がエラーを起こすようになりました。vacuumdb not foundみたいな・・・

あぁ、環境変数PATHに、/usr/local/binが入ってないじゃないですか。

/etc/login.confのdefaultにて、PATHに/usr/local/binが加えられていたんですね。
まあ、このあたりもちゃんと/etc/login.confのpgsqlクラスに加えてやればいいんじゃないかと思います。

2008年の「春のパンまつり」おしまい

20080516

今年のヤマザキの春のパンまつりも、もうおしまいですね。今年は、4個になりました。

シールがついているのは、昨日、5月15日（木）出荷分までということで、そろそろ、店頭にも、シールつきの商品はなくなっているころでしょう。

「白いおしゃれ小鉢」の引換期間は、5月25日（日）までとのこと。

■ 過去記事

白いおしゃれ小鉢　やっと１個

2008年の「春のパンまつり」　はじまる

2008年5月16日金曜日

(FreeBSD) PostgreSQLで、vacuumdb: vacuuming of database "..." failed: ERROR: out of memory DETAIL: Failed on request of size 573885600.みたいなエラー

FreeBSDでportsでインストールしたPostgreSQL。デフォルトで、毎日、dailyによってvacuumdbが実行されるようになるんです。

ところで、あのスクリプト/usr/local/etc/periodic/daily/502.pgsqlって、いまいちなんです。vacuumdbに必ず-aオプションつけてるところが。これだと、変数daily_pgsql_vacuum_argsで、データベース名を指定することができないじゃないですか。

まあそれはいいとして、dailyのログメールで、ある日気がついたのですが、vacuumdbを実行したときに、

vacuuming of database "データベース名" failed: ERROR: out of memory DETAIL: Failed on request of size 573885600.

というようなエラーが出て、vacuumdbが失敗するようになってました。

まずいじゃん！ってことで、

vacuumdb --dbname データベース --verbose --analyze --table テーブル名

のように、テーブル名を１つずつ指定していき、どのテーブルでエラーが出るのか、調べてみたら、特定のテーブルでのみ、エラーが出ることがわかりました。

ネット検索して、いろいろ試しても、問題解決できなかったので、ソースコードを確認してみることに。

ktraceつきでvacuumdbを実行してみたら、

vacuumdb CALL recvfrom(0x3,0x8063000,0x4000,0,0,0)
vacuumdb GIO fd 3 read 101 bytes
"E\0\0\0dSERROR\0C53200\0Mout of memory\0DFailed on request of size 536\
870910.\0Faset.c\0L527\0RAllocSetAlloc\0\0"

という感じで、バックエンド（postgresプロセス。昔はpostmasterという名前だったアレ）から返ってきている、生のエラーメッセージのようなものが見えました。ここに、ソースファイルの名前、行番号、関数名のようなものが含まれているじゃないですか。

aset.c

L527

AllocSetAlloc

aset.cというファイルは、./backend/utils/mmgrにありまして、

static void *
AllocSetAlloc(MemoryContext context, Size size)

という関数で、

chunk_size = MAXALIGN(size);
blksize = chunk_size + ALLOC_BLOCKHDRSZ + ALLOC_CHUNKHDRSZ;
block = (AllocBlock) malloc(blksize);
if (block == NULL)
{
MemoryContextStats(TopMemoryContext);
ereport(ERROR,
         (errcode(ERRCODE_OUT_OF_MEMORY),
         errmsg("out of memory"),
         errdetail("Failed on request of size %lu.",
                     (unsigned long) size)));

という感じでになっているので、ここでmallocが失敗しているんでしょう。

というわけで、vacuumdbが出しているエラーではなく、バックエンド側で出しているエラーですね。

また

512*1024*1024 = 536870912

なので、536870910ってのは、512MBくらい。

こうなると、すぐにピンとくるのは

(FreeBSD) unlimit datasizeしても512MBまで？

なんてもの。

もっとも、

(FreeBSD) Error occurred during initialization of VM / Could not reserve enough space for object heap / Could not create the Java virtual machine.

なんてことがあったので、やみくもにkern.maxdsiz="2G"とかやっちゃっても、別のメモリがらみのエラーがでることもありました。

あぁ、アドレス空間が4GBまでしかない32bit OSは限界だな、なんていう感じもしてきます。

でも、FreeBSD/i386は、ちょっと、限界が低すぎじゃない？って気もします。

☆

ところで、limitで広げるのは、postgresqlプロセスのほうであり、vacuumdbにたくさんメモリを与えても、ダメっすね。

ところで、maxdsizで広げても、root権限じゃないと512MBを超えられなかったような気がするんですが、気のせい？

postgresqlって、pgsqlというユーザーで走ってますよね。

気軽にpostgresqlを再起動できない事情がありまして、今はまだ、あれこれ試すことができません。

☆

postgresql.confで、maintenance_work_mem = 512MB とか書いてあったんですが、これを増やしても、なんかダメ。

だいたい、vacuumdbがなぜそんなメモリを消費するのか、と。

あれ、vacuumdb --fullなら実行できました。なるほど、VACUUM ANALYZEがメモリ食いのもよう。

ということは、と思ってpgadmin3で、テーブルのサイズなど見てたら、テーブルのサイズはどうやら4GBをとうに超えてましたが、それよりも驚いたことに、インデックスのサイズが600MBを超えてました。

近頃は、psqlでvacuumを実行すると

データベース=> vacuum テーブル名;
ERROR: out of memory
DETAIL: Failed on request of size 609512400.

なんてことになってて、600MBくらいの値。
ひょっとして、こっち、インデックスのサイズか？！

そんな巨大なインテックスって、なんか効率が悪そう。そもそも、テーブルの設計が悪いんじゃないか？

という気がしてきまして、テーブルをいくつかに分割しようかと思います。

それでも、寿命を少しのばす程度かもしれません。

それまでの間に、FreeBSD/amd64が、もっと使いやすくなっているといいんですけど。

■ つづく

(FreeBSD) PostgreSQLで、vacuumdb: vacuuming of database "..." failed: ERROR: out of memory DETAIL: Failed on request of size 573885600.みたいなエラー～解決編

2008年5月15日木曜日

とさっ子みょうがちゃん

20080514

「とさっ子みょうがちゃん」・・・？
あれ？　“みょうがちゃん”？
今度のは、先月見かけた「ミョーちゃん」じゃないんですね。

微妙な笑顔。みょうがのミョーちゃん

20080420

同じ高知でも、

「JA土佐くろしお」は「とさっ子みょうがちゃん」

「JA高知はた」は、「みょうがのミョーちゃん」

とキャラが違うんですか？

「であい博」ってのが開催中だそうです。ぜんぜん知りませんでした。

2008年3月1日から、2009年2月1日までだそうです・・・長いね。

会場は、高知県全域だそうです・・・広いね。

Webサイトは、２つもあります。内容は違います。

http://www.pref.kochi.jp/~deaihaku/

http://www.deaihaku.com/

(2008/5/15)
別の店では、みょがちゃん、ミョーちゃんが、混在して売られてました。

2008年5月14日水曜日

05月14日のココロ日記(BlogPet)

今度せつないカレーをつくります！ぜったいつくります！

*このエントリは、ブログペットのココロが書いてます♪

島耕作祭り in イブニング

現在発売中の雑誌「イブニング」ですが・・・

200805131

週刊モーニングでは島耕作が社長に就任した、ってことで、それを記念する企画として、あちこちの作品に、島耕作が登場してしまうという、たぶん、漫画家さんにとって、やっかいだけど、編集部の意向だから仕方ないよな、って感じの企画、「社長就任記念！　出張出演　島耕作」という、ホントあつかましいなぁ・・・な企画が開催されています。

200805132

もともと、こっちの雑誌イブニングには、島耕作の若いころを描いた「ヤング島耕作　主任編」という、普通では恥ずかしくて仕方ないタイトルだけど、あーもーどうでもいいや、と思わせてしまう、そんな作品が連載中。

島耕作が登場するのは、イブニングすべての作品ではなくて、６本くらい、なんか微妙な選択です。しかも登場する島耕作が、ことごとく、似ていない。
プロの漫画家さんだから、似せようと思えば、それなりに似せられるはずなのに。
言われても、誰だかわかんない、それくらいの似てなさって、いったい・・・

これは、あまり強く主張できない漫画家さんの、ささやかな抵抗なんでしょうか。
作品世界が壊されますから辞退させていただきます・・・とかやっぱり言いにくいんでしょうか。

島耕作が登場する作品は、パロディ作品的か、もしくは、出ても出なくてもどうでもいい、そんな感じになっちゃってます。
もしもそんなことないよっていうなら、「レッド」に出してみろ、って（笑）
そういえば、ヤング島耕作では、学生運動の話もでてました。

☆

今、平成２０年の現代社会で、大企業の社長がサラリーマンのゴールなのだ、ってことはないですよね。たぶん、そんなことは、作者も十分承知なんでしょうね。所詮、島耕作は、団塊の世代におくる、ファンタジー作品。あまり無粋なツッコミはせずに、ああなるほどね、くらいに楽しむのが、正しいと思います。

しばらく前にテレビで見たんですが、おそらく「課長島耕作」をリアルタイムに読んでいた世代の人へインタビューをしてたんですが、（もちろん番組のための編集がされていてのことでしょうが）みなさん、ことごとく、「えー？まだ連載してたんですか」と言ってたのが印象に残っています。

今の島耕作って、どういう人が愛読者なんでしょうかね。なんか、想像ができません。

社長っていっても、持ち株会社の社長だし、まだこれから、いろいろありそうな感じです。

植木等みたいなサラリーマンと、島耕作って、どっちの人生がいいかなぁ。

2008年5月13日火曜日

(FreeBSD) ports/print/ghostscript-gplのGPL Ghostscript 8.62では、日本語の縦書きフォントがおかしい

今日も昨日に引き続き、article9.psに関連すること。

日本国憲法　第九条

今現在、FreeBSDのportsでインストールできるghostscriptには、

ports/print/ghostscript-gnu

ports/print/ghostscript-gpl

の２つがあるみたいですが、私の場合、これまでは、ghostscript-gnuの方を使ってました。というか、そもそも、何も考えずに

ports/japanese/ghostscript-gnu-jpnfont/

をインストールすると、自動的に、ports/print/ghostscript-gnuがインストールされていた、というだけのことですが。

とくにghostscript-gnuの方で問題は無かったのですが、最近、portsの依存関係で、ghostscript-gplをインストールしなさい、といわれることがありました。

だいたい、gnuとgplってどう違うんだよ！、って言いたくなりますが（なんかの理由があるんでしょう、きっと・・・copyrightが違うし）、ghostscript-gnuは、バージョンが7.07、ghostscript-gpgが、バージョン8.62になるみたいです。

GNU Ghostscript 7.07 (2003-05-17)
Copyright (C) 2003 artofcode LLC, Benicia, CA. All rights reserved.
This software comes with NO WARRANTY: see the file PUBLIC for details.

GPL Ghostscript 8.62 (2008-02-29)
Copyright (C) 2008 Artifex Software, Inc. All rights reserved.
This software comes with NO WARRANTY: see the file PUBLIC for details.

☆

さて、ports/print/ghostscript-gplなんですが、これをインストールして、日本語が表示できなくなってしまうと嫌だな～と思ってたんですが、どうやら、ports/japanese/ipa-ttfonts/ もインストールしておけば、日本語も表示できるようでした。

し　か　し　！　article9.psを表示してみたところ

20080512

一見よさそうなんですが、カッコや、句読点の位置がおかしい。どうも、縦書きフォントの処理がよろしくないようです。横書きのフォントを、そのまま縦書きに使っているように見えます。

参考までに、昨日の、GNU Ghostscript 7.07 を使ったときの表示（ports/print/gvを使ってます）。

20080511

このような縦書きへ対応させるには、どうすればいいんでしょうかね？
１時間ほど、ktraceして、ghostscript 7.07と比較することで、なんとかならないか方法を探ってたのですが、結局よくわかりませんでした。

2008年5月12日月曜日

日本国憲法　第九条

さる5月3日は憲法記念日でしたが、おそろいの観覧車記念日だよね～。

ところで、その筋の情報によれば、年末に「ねじまきや」があるらしいです・・・本当？

で、そっちの話はおいといて、いつもながら変なタイトルをつけてしまいましたが、憲法についてブログで熱く語ろう、というわけではなく、

article9.ps

の話。Ghostscriptっていうと、あああれか、と思う人がいるかもしれません。
もっとも、最近のUnix系OSユーザーだと、何それ？っていう人が多いでしょうか。

PostScriptプリンタで使われているPostScriptというページ記述言語がありますが、PostScript互換のソフトウェアにGhostscriptというのがあります。昔、PostScriptはとっても高くて（というか、日本語フォントの値段が高かった）、貧乏な人たちは、ghostscriptというソフトウェアを使って、PostScriptファイルを表示したり、PostScriptじゃない安価なプリンタで印刷してました。

昔のGhostscriptは、それだけではアルファベットのフォントしか使えず、日本語を使えるようにするためのパッチがありました。そのパッチの中に、動作テスト用に、日本語を使ったPostScriptファイルのサンプルが入っていました。そのサンプルファイルの１つが、article9.psなのです。

このarticle9.psを表示してみると・・・

20080511

日本国憲法の第9条なんです。articleというのは、箇条、条項という意味があって、日本国憲法第9条は、Article 9 of the Japanese Constitutionだそうです。今辞書を引いたら、そう書いてありました（[E:happy01]）。

日本で作られたソフトウェア（パッチ）として、なにか日本らしいメッセージをこめたくて、これをサンプルとして入れておいたんでしょうかねぇ？

ぜんぜん関係ないですが、ときどき経済ニュースでChapter11、チャプター・イレブンっていう言葉を耳にしますが、あれは、連邦倒産法第11章っていうものだそうで、会社の経営が行き詰っちゃいました、もう倒産寸前です、借金をちょっとまけてくれませんか？っていうときのもの。日本の会社更生法みたいなものらしいです。

☆

昔から、日本語対応のGhostscriptをインストールすると、どこかのディレクトリに、article9.psというファイルもコピーされていました。ところが最近、ふと気がつけば、FreeBSDのportsでGhostscriptをインストールした場合、このarticle9.psが無くなってしまっているじゃないですか。
あれ？どこいっちゃったの？？？　まじめな話、このarticle9.psって、動作テストするときに、とても便利だったのに・・・

article9.psが使いたくて、あちこち、探し回ってしまいました。

gs261j.lzhというアーカイブファイルの中に入っているのを発見しました。私の記憶の中でも、これはけっこう古いものです。

% lha ~/gs261j.lzh
PERMSSN UID GID    SIZE RATIO    STAMP          NAME
---------- ----------- ------- ------ ------------ --------------------
[MS-DOS]                1999 40.1% Jun 23 1992 gs261j/kanji/allkanji.ps
[MS-DOS]                2411 45.6% Apr 20 1992 gs261j/kanji/article9.ps
（以下略）

タイムスタンプは1992年4月20日ですね。

☆

FreeBSDのportsはどうなっちゃったんでしょうか。cvswebで、昔のportsを眺めて、探してみました。

どうやら、vflib対応版ghostscriptをインストールしたときは、article9.psもコピーされていたようです。ports/japanese/vfghostscript55ですが、現在はもうこのportsは削除されてしまっています。

このpkg-plistファイルを見ると

http://www.jp.freebsd.org/cgi/cvsweb.cgi/ports/japanese/vfghostscript55/Attic/pkg-plist?rev=1.16&content-type=text/x-cvsweb-markup

この中に

share/ghostscript/5.50vflib/vflib/article9.ps

というのがあります。

article9.psは、どの配布ファイルに含まれているのか、それを探すのが一苦労でした。

Makefileを見ても、ぱっとみて、よくわからず。

http://www.jp.freebsd.org/cgi/cvsweb.cgi/ports/japanese/vfghostscript55/Attic/Makefile?rev=1.51&content-type=text/x-cvsweb-markup

gs5.50-vflib-1.0.tar.gzが怪しいんですが、展開しても、article9.psは入ってない。
ほかのアーカイブファイルの中を見ても、どうも見つからないので、おかしい。いったいどこにあるんだ？？？

やっぱりgs5.50-vflib-1.0.tar.gzでした。この中にあるパッチファイル、gs5.50-vflib-1.0.diffに、含まれてました。ははは・・・なんでそんなことになってるんだ、わかりにくい。でも、昔は、こんな風にパッチにまとめてしまう方法、よくやってたような気もします。WWWが普及する前は（90年代前半）、ソフトウェアは、ネットニュースのfj.sourcesで入手することが多かったですし、パッチファイル１つだと、見た目でもわかりやすかったのかも。FTPよりもネットニュース、っていう時代、ありましたよね…

diff -Naur gs5.50/vflib/article9.ps gs5.50v/vflib/article9.ps
--- gs5.50/vflib/article9.ps Thu Jan 1 00:00:00 1970
+++ gs5.50v/vflib/article9.ps Sun Sep 20 09:39:18 1998
@@ -0,0 +1,97 @@
+%!PS-Adobe-2.0
+%
+% Article 9 of the Constitution of Japan
+% written in vertical direction using ...
+%    Fonts:
+%             Ryumin-Light-V, GothicBBB-Medium-V
+%    Operators for characters:
+%             show, widthshow, ashow, stringwidth, charpath, cshow
+
以下略

2008年5月11日日曜日

FreeBSD 7.0-RELEASEでUSBキーボードを使ったら、キーを押すと変な記号がでたりで使い物にならなかった　～　キーボードのハードウェア依存な問題らしい

先日、自宅サーバをFreeBSD 7.0-RELEASEにアップグレードしたんですが、

自宅サーバをFreeBSD 7.0-RELEASEにアップグレードしてみた　～ 1年くらい前の6.2-STABLEから7.0-RELEASEへ…ちょっとめんどくさかった。

そのときにも、USBキーボードのキーを押すと、変な記号やら表示されて、USBキーボードが使い物にならない問題がありました。なんかUSBキーボードの挙動がおかしいな、と気がついてはいたのですが、そのときは、気のせいだろう、ってことにして、見なかったことにしてました。

というのも、FreeBSDのインストール作業は、PS2キーボードを使って行うのが、個人的に一番いいと思ってて、また、ディスプレイもキーボードもマウスも接続しないで使うサーバなので、通常は、USBキーボードが使えなくてもまったく問題ないですし。

今日、ちょっと使ってみたくて、別のパソコンを、FreeBSD 7.0-RELEASEにアップグレードしたのですが、またしても、同じ問題が発生。

たとえば、以下は、USBキーボードのキー、A、B、Cを押したときの画面。

20080510

記号が表示されてます（笑）。いろいろキーを押すと、たまに、^A、^B、^Cと表示されることもありました。
なんだか、でたらめなキースキャンコードが返ってきているような雰囲気です。
6.2-STABLEのときは問題なく使えていたので、何か納得がいきません。

それに、仕事先のパソコンで、FreeBSD 7-STABLEで使っているものがあるのですが、それでは何の問題もなく、USBキーボードが使えています。これはいったいどういうことなんでしょうか。

きっとまたkbdmuxのせいだろ、とか思って、kbdmuxを無効にしてみたんですが、やっぱりダメ。
BIOSメニューで、USB Legacy Supportを無効にしてもダメ。
どうやら、USBキーボードのドライバであるukbd自体に問題があるっぽいようです。

とりあえず、障害の調査対象をukbdに絞込み、6.3-RELASEと、7.0-RELEASEとの間の差分をながめてみました。

http://www.jp.freebsd.org/cgi/cvsweb.cgi/src/sys/dev/usb/ukbd.c.diff?r1=1.72.2.2&r2=1.52.2.8&f=h

まずは、ukbdをカーネルから抜いて、カーネルモジュールとしてロードするようにしました。そして、ukbd.cを少し書き換えては、コンパイル、モジュールをロード、動作テスト、ダメならモジュールをアンロード、・・・以上の繰り返し、という手順で、試行錯誤をしてみたところ、見つかりました！

関数init_keyboardの中でやっていたらしい（quirkとされている）、usbd_set_protocol(state->ks_iface, 0);というのが、7.0-RELEASEになるときに消えてなくなっているのですが、これを付け加えたら、正常にUSBキーボードが使えるようになりました。

このあたりのコードがけっこう書き換えられてしまって、きれいなパッチにはならなかったのですが、暫定的に、こうしてみました。

--- /usr/src/sys/dev/usb/ukbd.c.ORG    2007-11-13 01:09:45.000000000 +0900
+++ /usr/src/sys/dev/usb/ukbd.c 2008-05-10 20:26:24.000000000 +0900
@@ -1458,6 +1458,15 @@
            return EINVAL;
      }

+    {
+       usbd_status err = usbd_set_protocol(state->ks_iface, 0);
+       DPRINTF(("ukbd:init_keyboard: protocol set\n"));
+       if (err) {
+          printf("ukbd: set protocol failed\n");
+          /*return EIO; */
+       }
+    }
+
      /* Ignore if SETIDLE fails since it is not crucial. */
      usbd_set_idle(state->ks_iface, 0, 0);

上記の変更は、「私の使っているキーボードではこうすると動くようになる」ってだけで、誰の環境でも、必ずこうしなければいけない、というものではないはずです。注意してください。

上のコードは、ukbd.cがrevision 1.70になったときに、削除されたみたいです。

http://www.jp.freebsd.org/cgi/cvsweb.cgi/src/sys/dev/usb/ukbd.c.diff?r1=1.69&r2=1.70&f=h&f=u

以下のような、いくつかのファイルが関連していますが、

http://www.jp.freebsd.org/cgi/cvsweb.cgi/src/sys/dev/usb/ukbd.c?f=h
http://www.jp.freebsd.org/cgi/cvsweb.cgi/src/sys/dev/usb/usb_quirks.h?f=h
http://www.jp.freebsd.org/cgi/cvsweb.cgi/src/sys/dev/usb/usb_quirks.c?f=h

commitログをみていくと

o ukbd: Remove the NO_SET_PROTO quirk (fixes a PR 77940). NetBSD removed
their check and setting the proto a long time ago.

というのがあります。これのことです。

どうやら、キーボードの機種（ベンダー、モデル）によって、問題があるっぽいです。
このとき削除された処理が入っていると、動かなくなるキーボードがあったり、逆に、この処理を無くすと、私が使っているキーボードのように動かなくなることもある、ということでしょうか。

今回FreeBSD7でトラブルを起こした、私が自宅で使っているキーボードは、9年ほど前に、秋葉原で購入したもので、未使用の新品だけどジャンクとして売られていたキーボードです。もともとは、富士通製パソコンに付属のキーボードなのですが、なぜかキーボードだけでバラ売りされてました。値段はとても安かったです（[E:happy01]）

デバイスが認識されたとき、こんな風に表示されます。

ukbd0: <Fujitsu Fujitsu USB Comfort Keyboard, class 0/0, rev 1.00/1.00, addr 4> on uhub5

USBがWindowsでなんとか使えるようになったのは、たしかWindows 98SEくらいのころでしたが、これ、まさにそのころのキーボードです。つまり、初期のUSBキーボード、ってことでして、なんか微妙に変なところがある、ってことでしょうかねぇ・・・

☆

昔問題になった、FreeBSD 6.1-RELEASE、6.2-RELEASEなどで、USB日本語106/109キーボードを使っていると、フルキーの右下あたりにある、アンダースコア(_)・・・「ろ」と書いてあるキー、が入力できない、という問題は、7.0-RELEASEでは直ってました。

(FreeBSD) USB日本語106/109キーボードでアンダースコア(_)が入力できない

2008年5月10日土曜日

はじめ人間ギャートルズ

TOKYO MXで夕方放映中のアニメ「はじめ人間ギャートルズ」。
懐かしい！

今この年齢になって見てみると、内容にけっこう哲学的なところがあったりして、子供のころとは、まったく違った味わいが感じられました。

あと、今回見て、そうだったっけ、と思ったのが、ドテチンがたてかべさん、とうちゃんが肝付さんだった、ってこと。
古い作品では、この二人の演じるキャラの上下関係が、肝付さんの方が上にくるものが多いんですよね。ドテチンが下だ、って言い切るのも変ですが・・・
むしろ、ドラえもんだけが例外的なのかもしれませんが、あまりにもドラえもんのイメージが強く、たてかべさんの方が上、という感覚がしみついてしまっています。

☆

たまにある勘違い（？）だと思うのですが、こういう肉

200805092

を「ギャートルズの肉」と呼んでいるのを見たことがあるんですが、本当のギャートルズの肉は、こっち

200805091

で、まったくの別物ですよね。
骨付き肉の絵の方は、本当は、「マンガの肉」とか「あの肉」とかいうのが正式名称で（？）、たしか吉田戦車の作品で、これを熱く語っているものがあったような気がします。

ギャートルズの肉は、マンモスを輪切りにした肉で・・・これ生肉ですよね？
見た目はやわらかくておいしそうですけど、現実に存在するものでは、プレスハムの厚切りが、イメージとして近いような気がします。
ギャートルズの肉でトンポーローを作ったらおいしそう。

☆

数年前に、「はじめ人間ゴン」という作品がNHKで放映されてましたが、当時、あれはなんか違う、って気がしていました。今回、はじめ人間ギャートルズをもう一度見ることができて思ったんですが、OPとED曲が、強烈に記憶の中に刷り込まれてます。EDは子供のころから名曲だと思ってました。アニメのエンディング曲には名曲が多いといわれますが、思いつくところでは、元祖天才バカボンとかキューティーハニーとか好きでした。

☆

小学生のころマンガの本を１冊買って持ってたんですが、今どこにあるんだろう。
タイトルが「ギャートルズ」の方だったかな。

2008年5月9日金曜日

ラジオ　スクライド in ロストグラウンド第4回

未明の地震、ちょっとビックリしました。ロストグラウンドが出現したんではないかと。

寝てたのですが、テレビで、緊急地震速報ってのを初めてみました。

昔、地震でゆれる数分前にふと目が覚めて、なぜ目が覚めたんだろう？と不思議に思っていると、そのうち地震がやってくる、そんな経験を何度かしたんですが、最近は、すっかりそういった野生の勘が衰えました。

今回も緊急地震速報って、間に合わなかったらしいですね。私、いつテレビをつけたのかが、どうも寝ぼけてて、はっきりとしないのですが。

20080508

とうとう今週が第4回ということで、予定されていた４回が、すべて終わってしまいました。

http://dbeat.bandaivisual.co.jp/netradio/scryed.php

もう一度スクライドを見直してみたくなってしまって、この燃え上がる衝動を、どうしたらいいのか。
DVD BOX、買っちゃうかも？
ただ、買ってもいいんだけど、実際問題として、見る時間がない。

とりあえず第23話だけでも、明日早起きして見ようかな。

☆

手元にあったソフトの中で、とあるソフトで、録音して、別のソフトでWAVに変換してから、また別のソフトでMP3にして、そうやってiPodで聞いてました。

■ 過去記事

ラジオ　スクライド in ロストグラウンド第3回

2008年5月8日木曜日

身延線

駅に「身延線沿線マップ」というパンフレットが置いてありました。

200805071

小さな文字で「身延線へのアクセス」と書いてあるのですが、そこには…

200805072

東海道新幹線「静岡駅」下車

という文字が…

一番近い新幹線の駅、「新富士駅」の立場が、まるでなし。JR東海からも、おもいっきりダメだしされてるなんて。

この地図は、悪意でもあるのか、富士駅と新富士駅がけっこう離れているように描かれていますが、歩いてでも行けます。たぶん（笑）

東海道新幹線の新富士駅は、東海道線など在来線との接続がまるでなくて、そこで新幹線を降りたら、あとはバスかタクシーしか移動手段がありません。２０年前に開業した駅ですが、ずーっと、そんなわけで、使えない駅。

地元民の私でも、家の人に車で送り迎えしてもらえるときしか、新富士駅を使ったことがないです。たしか、駅ができてまもなくのころ、大学受験の帰りだったか、１回だけ、バスで富士駅まで出たことがありましたが、まあなんとも不便でした。それ以来、ふだんは、遠いけど三島駅で乗り換えてます。

ちなみに、なぜ新幹線の駅は、沼津じゃなくて三島にあるんだ？！っていう素朴な疑問もありますが、それはそれで、今では考えられないような事情があったらしいです。

かつては、身延線を新富士駅まで延伸するという夢のような計画もあったようですが、夢でしたね。

岳南鉄道で吉原駅に接続してくれてもいいですけど。せめてもっと東側に新富士駅を作ってくれていれば、その可能性もあっただろうに…

ほかにも、過去には、想定外の出来事で利用客数が減ってしまったとか、悲運な駅、新富士駅なわけです。

☆

さて、新富士駅まで延びることはなかった身延線なのですが、むかし、むかし、身延線は、今とは別のところを走っていたのだそうです。私、最近まで、そのことを知りませんでした。

この記事によると

■ 広報ふじ　昭和42年12月5日 22号
身延線西回り複線化起工　完成は四十五年
 http://www3.city.fuji.shizuoka.jp/kouhoufuji/s42/kiji/022-01-01.htm
写真入り記事（PDF形式）
http://www3.city.fuji.shizuoka.jp/kouhoufuji/s42/kouhoupdf/022-01.pdf

現在の身延線は、富士駅を西向きに出て行くのですが、昔は、東向きに出て行ったそうです。そして、竪堀駅の先で、今現在の場所と合流する、という経路。へー！？まったく知りませんでした。

そして、予定よりも工期が１年短縮されるという、なんかすごいじゃん、なことがあり、新たに、柚木駅ができて、竪堀駅（←懐かしい）の位置が少し動いて

■ 広報ふじ　昭和44年6月20日 45号
１０月１日には開通　身延線西回り複線化工事すすむ
 http://www3.city.fuji.shizuoka.jp/kouhoufuji/s44/kiji/045-02-01.htm
写真入り記事（PDF形式）
http://www3.city.fuji.shizuoka.jp/kouhoufuji/s44/kouhoupdf/045-02.pdf
ところで、このページ下側の写真に写ってる電気機関車は、EH10じゃないかな？

そうして、昭和44年9月28日に開通式が行われた、ということだそうです。

■ 広報ふじ　昭和44年10月5日 52号
身延線西回りが開通
 http://www3.city.fuji.shizuoka.jp/kouhoufuji/s44/kiji/052-03-01.htm
写真入り記事（PDF形式）
http://www3.city.fuji.shizuoka.jp/kouhoufuji/s44/kouhoupdf/052-03.pdf

なお、それまで通っていた身延線の跡は、現在、緑道になっているそうです。

富士緑道
 http://www.city.fuji.shizuoka.jp/cityhall/tosise-b/midori/kouen/9-1.htm

あー、そういえば、ありました、緑道。
ただ、富士緑道なんていう名前だったとは、知りませんでした。

☆

大学生のころ、青春18きっぷを使って、身延線で甲府に抜けて、松本のほうへ行って、さらには海ノ口まで行ったこともありました（あのアニメより前）。

各駅停車で身延線を踏破ってのは、普通の人には辛かったです。今は懐かしい、って思いますけど。

(2009/02/07 追記)

goo地図で見ると、なんとなく昔の線路の跡が見えます。

20090207f

http://map.goo.ne.jp/map.php?MAP=E138.39.20.644N35.9.5.928&ZM=9

2008年5月7日水曜日

05月07日のココロ日記(BlogPet)

にょほほさんと、なんとなく心が通じたかも……そんな気がしました。

*このエントリは、ブログペットのココロが書いてます♪

大型連休が終了

20080506

あれこれやろうと思ってたのに、結局できなかったことばかり。
毎年、同じことの繰り返し。

今年も、犬と遊んでた（ゴロゴロ寝てた？）だけ。

2008年5月6日火曜日

古いパソコン、FreeBSD 7.0Rにしたら、topのCPU states行が、全部「0.0%」～ (2) とりあえず解決

前回の話。

古いパソコン、FreeBSD 7.0Rにしたら、topのCPU states行が、全部「0.0%」

CPUがAMD Athlon 800MHzという古い自作パソコンにFreeBSD 7.0-RELEASEをインストールしたら、なぜか、topのCPU statesという行の値が、全部0.0%になっていて、vmstatのCPU使用率も0、というおかしなことが起きました。

まず、カーネルのバグを疑って、試行錯誤してみました。

4月のsnapshot版のカーネルを使っても、0.0%のまま。vmstat -iでみたとき、rtcのrateは0。

cvsup (csup)で、最新の7-STABLEのカーネルソースコードを取得して、カーネル再構築してみたけど、0.0%のまま。vmstat -iでみたとき、rtcのrateは0。

6-STABLEのカーネルで起動すると、正しそうな値が表示された。vmstat -iでみたとき、rtcのrateは127。

というわけで、6系と7系の間に入った変更で、0.0%になる原因が入っているはず。

rtcはソースコードでどのあたりかな？とラフにgrepしてみると、/sys/i386/isa/clock.cが主に該当しそう。

6-STABLEと7-STABLEとで、clock.cの差分を眺めていて、rtcin()とwritertc()が、なんとなくあやしいと思い、6-STABLE相当のコードに戻して、カーネル再構築。

/*
* RTC support routines
*/

int
rtcin(reg)
int reg;
{
#if 1
/*6-STABLE*/
u_char val;

      RTC_LOCK;
      outb(IO_RTC, reg);
      rtc_reg = reg; /* +++ */
      inb(0x84);
      val = inb(IO_RTC + 1);
      inb(0x84);
      RTC_UNLOCK;
      return (val);
#else
/*7-STABLE*/
      u_char val;

      RTC_LOCK;
      if (rtc_reg != reg) {
            inb(0x84);
            outb(IO_RTC, reg);
            rtc_reg = reg;
            inb(0x84);
      }
      val = inb(IO_RTC + 1);
      RTC_UNLOCK;
      return (val);
#endif
}

void
writertc(int reg, u_char val)
{
#if 1
      RTC_LOCK;
      inb(0x84);
      outb(IO_RTC, reg);
            rtc_reg = reg;
      inb(0x84);
      outb(IO_RTC + 1, val);
      inb(0x84);             /* XXX work around wrong order in rtcin() */
      RTC_UNLOCK;
#else
      RTC_LOCK;
      if (rtc_reg != reg) {
            inb(0x84);
            outb(IO_RTC, reg);
            rtc_reg = reg;
            inb(0x84);
      }
      outb(IO_RTC + 1, val);
      inb(0x84);
      RTC_UNLOCK;
#endif
}

これで起動してみると・・・直りました。

% vmstat -i
interrupt                         total    rate
irq0: clk                         79523       99
irq1: atkbd0                      218       0
irq6: fdc0                            2       0
irq7: ppbus0 ppc0                   1       0
irq8: rtc                      101780       127
irq9: fxp0 acpi0                   334       0
irq12: uhci0 uhci1                   2       0
irq14: ata0                      3598       4
Total                            185458       232

top -S -Hは、こんな感じ。

last pid: 834; load averages: 0.00, 0.02, 0.03 up 0+00:14:28 16:31:50
74 processes: 2 running, 57 sleeping, 15 waiting
CPU states: 1.5% user, 0.0% nice, 0.0% system, 0.0% interrupt, 100% idle
Mem: 10M Active, 11M Inact, 21M Wired, 44K Cache, 28M Buf, 137M Free
Swap: 512M Total, 512M Free

PID USERNAME PRI NICE SIZE RES STATE TIME WCPU COMMAND
11 root    171 ki31    0K    8K RUN    13:52 100.00% idle
12 root    -32 -    0K    8K WAIT    0:01 0.00% swi4: clock sio
4 root       -8 -    0K    8K -       0:00 0.00% g_down
564 root       96 0 3104K 1208K select 0:00 0.00% nfsd
783 root       5 0 4468K 2584K ttyin 0:00 0.00% csh
800 root       4 0 8384K 3776K sbwait 0:00 0.00% sshd
3 root       -8 -    0K    8K -       0:00 0.00% g_up

う～ん、どういうことなんでしょうね。
この症状がでるのって、うちのこのパソコンくらいなんでしょうか。

☆

P.S.

最初、writertc()の方を見落としていて、7-STABLEのときのままでやったら、vmstat -iでrtcが出てこなくなり、何が起きたんだ？と思ってソースコードを見直して、さもありなん、と納得。変数rtc_regのあたりですね。

writertc()を修正して、再起動したら、BIOSの初期化で、CMOSの内容がおかしいよ、と言われてしまう。

う～ん、そういうこともありそうな気がする、と再び納得しつつ、BIOSメニューでパラメータを再設定して再起動したら・・・起動しなくなりました。どこか、指定を間違えたみたいです（DRAM関係を間違えたらしい）。

しょうがないから、CMOSの内容をリセットしようと思って、マザーボード上のジャンパピンを探したら、見つからない。

マニュアルを見て、ジャンパピンの場所を調べてみたけど、やはり見つからない。

おかしいな、と思いつつ、ボード上に印刷している文字をじっくりと眺めていたら・・・、ジャンパピンがあるべき場所に、パターンだけがあって、ピンがはんだ付けされてませんでした。不良品じゃん・・・約８年目にして気がついた・・・

☆

P.S. 2

関係あるかどうかわかりませんが（関係ありそうですが）、portupgradeを実行中など、裏で重たいプロセスが走っているとき、キー入力などの反応がものすごく鈍くなる、っていうのも改善されました。

おかしかったときは、CPUの統計情報が取得できなくなってたので、プロセスのスケジューリングも、メロメロな状態になっていたのではないかと？

■ 過去記事

古いパソコン、FreeBSD 7.0Rにしたら、topのCPU states行が、全部「0.0%」

（VMware）FreeBSD 6.1Rのカーネル再構築

（VMware）FreeBSD 6.1Rのカーネル再構築（２）　不要なモジュールをビルドしないようにする

2008年5月5日月曜日

(FreeBSD) たまにportupgradeがおかしなことをする？～アップデートに失敗してアンインストールされてしまう

以前から薄々気がついていたこと。

portupgradeでportsのソフトウェアのアップデートをしたときに、アップデート作業が何かのエラーで途中で失敗してしまうと、どういうわけか、今までインストールされていたものがアンインストールされて、それでおしまい、という酷いことが、たまにおきてます。

これまで、「まあいいか、気のせい、気のせい」、で済ませていたのですが、先週、たまたま、実行する様子をながめていて、「おい、何やってんだよ！」と言いたくなる様子が見えました。

「portupgrade -Pa」で、バイナリパッケージ（事前に別マシンでportupgrade -pでビルドしておいたパッケージ）を使って、アップデートをしていました。

thunderbirdのアップデートが失敗したあげく、アンインストールされてしまいました。

---> Checking for the latest package of 'mail/thunderbird'
---> Fetching the package(s) for 'thunderbird-2.0.0.12_3' (mail/thunderbird)
---> Fetching thunderbird-2.0.0.12_3
★このとき、たまたま/usr/ports/packages以下に、thunderbirdのバイナリパッケージがなかったので、外にFTPでダウンロードしようとしている
fetch: ftp://ftp3.FreeBSD.org/pub/FreeBSD/ports/i386/packages-6-stable/All/thunderbird-2.0.0.12_3.tbz: Connection refused
** The command returned a non-zero exit status: 1
** Failed to fetch ftp://ftp3.FreeBSD.org/pub/FreeBSD/ports/i386/packages-6-stable/All/thunderbird-2.0.0.12_3.tbz
fetch: ftp://ftp3.FreeBSD.org/pub/FreeBSD/ports/i386/packages-6-stable/All/thunderbird-2.0.0.12_3.tgz: Connection refused
** The command returned a non-zero exit status: 1
** Failed to fetch ftp://ftp3.FreeBSD.org/pub/FreeBSD/ports/i386/packages-6-stable/All/thunderbird-2.0.0.12_3.tgz
★ただ、firewallの関係で、ダウンロードに失敗
** Failed to fetch thunderbird-2.0.0.12_3
** Listing the failed packages (-:ignored / *:skipped / !:failed)
! thunderbird-2.0.0.12_3 (fetch error)
** Could not find the latest version (2.0.0.12_3)
---> Using the port instead of a package
★バイナリパッケージはあきらめ、portsで、ソースから独自にビルドしようとしている
---> Upgrading 'thunderbird-2.0.0.12_1' to 'thunderbird-2.0.0.12_3' (mail/thunderbird)
---> Building '/usr/ports/mail/thunderbird'
===> Cleaning for thunderbird-2.0.0.12_3
★portauditによって、このバージョンのthunderbirdにはセキュリティホールがあることがわかっているので、ビルドが中止される
===> thunderbird-2.0.0.12_3 has known vulnerabilities:
=> firefox -- javascript garbage collector vulnerability.
Reference: <http://www.FreeBSD.org/ports/portaudit/67bd39ba-12b5-11dd-bab7-0016179b2dd5.html>
=> mozilla -- multiple vulnerabilities.
Reference: <http://www.FreeBSD.org/ports/portaudit/12b336c6-fe36-11dc-b09c-001c2514716c.html>
=> Please update your ports tree and try again.
*** Error code 1

Stop in /work/FreeBSD/ports/mail/thunderbird.
*** Error code 1

Stop in /work/FreeBSD/ports/mail/thunderbird.
★というわけで、エラー終了になると思いきや・・・何かやってる
---> Backing up the old version
★アンインストールしはじめた。何やってんだよ！
---> Uninstalling the old version
---> Deinstalling 'thunderbird-2.0.0.12_1'
Could not parse file '/usr/local/share/applications/gimp-2.2.desktop': No such file or directory
★とうとうアンインストールしてしまった
[Updating the pkgdb <format:bdb_btree> in /var/db/pkg ... - 1164 packages found (-1 +0) (...) done]
★ビルドに失敗してるのに、なぜかインストールしようとしてる
---> Installing the new version via the port
★セキュリティホールがあるから、インストールもできないんだってば
===> thunderbird-2.0.0.12_3 has known vulnerabilities:
=> firefox -- javascript garbage collector vulnerability.
Reference: <http://www.FreeBSD.org/ports/portaudit/67bd39ba-12b5-11dd-bab7-0016179b2dd5.html>
=> mozilla -- multiple vulnerabilities.
Reference: <http://www.FreeBSD.org/ports/portaudit/12b336c6-fe36-11dc-b09c-001c2514716c.html>
=> Please update your ports tree and try again.
*** Error code 1

Stop in /work/FreeBSD/ports/mail/thunderbird.
*** Error code 1

Stop in /work/FreeBSD/ports/mail/thunderbird.
===> Cleaning for thunderbird-2.0.0.12_3
---> Cleaning out obsolete shared libraries

で、結局、アンインストールされて、終わり。

☆

以下は、似たようなことを、別のFreeBSD7なマシンでやってみたときの様子。

---> Checking for the latest package of 'mail/thunderbird'
---> Fetching the package(s) for 'thunderbird-2.0.0.12_3' (mail/thunderbird)
---> Fetching thunderbird-2.0.0.12_3
** The command returned a non-zero exit status: 1
** Failed to fetch ftp://ftp3.FreeBSD.org/pub/FreeBSD/ports/i386/packages-7-stable/All/thunderbird-2.0.0.12_3.tbz
** The command returned a non-zero exit status: 1
** Failed to fetch ftp://ftp3.FreeBSD.org/pub/FreeBSD/ports/i386/packages-7-stable/All/thunderbird-2.0.0.12_3.tgz
** Failed to fetch thunderbird-2.0.0.12_3
** Listing the failed packages (-:ignored / *:skipped / !:failed)
! thunderbird-2.0.0.12_3 (fetch error)
** Could not find the latest version (2.0.0.12_3)
---> Using the port instead of a package
---> Upgrading 'thunderbird-2.0.0.12_1' to 'thunderbird-2.0.0.12_3' (mail/thunderbird)
---> Building '/usr/ports/mail/thunderbird'
===> Cleaning for thunderbird-2.0.0.12_3
===> thunderbird-2.0.0.12_3 has known vulnerabilities:
=> firefox -- javascript garbage collector vulnerability.
Reference: <http://www.FreeBSD.org/ports/portaudit/67bd39ba-12b5-11dd-bab7-0016179b2dd5.html>
=> mozilla -- multiple vulnerabilities.
Reference: <http://www.FreeBSD.org/ports/portaudit/12b336c6-fe36-11dc-b09c-001c2514716c.html>
=> Please update your ports tree and try again.
*** Error code 1

Stop in /a/sba/host/usr/ports/mail/thunderbird.
** Command failed [exit code 1]: /usr/bin/script -qa /tmp/portupgrade.41350.2 env UPGRADE_TOOL=portupgrade UPGRADE_PORT=thunderbird-2.0.0.12_1 UPGRADE_PORT_VER=2.0.0.12_1 make FETCH_BEFORE_ARGS=-q
** Fix the problem and try again.

こちらの場合は、portsでビルドしようとして、セキュリティホールがあるから中止、となるところまでは同じですが、そのとき「** Command failed」というのが出てて、そこでportupgradeも終了しているんです。何ですか、この違いは…

そろそろ、rubyの勉強をはじめた方がいいのでしょうかね。

2008年5月4日日曜日

古いパソコン、FreeBSD 7.0Rにしたら、topのCPU states行が、全部「0.0%」

古いパソコンは、実家に持っていって、第二の人生を歩んでもらってます。

そのうちの1台、CPUはAMD Athlon 800MHz（たぶんThunderbirdコア）というものなんですけど、お正月すぎに6.3-STABLEにアップグレードインストールして、とくに問題なく使えていました（やや動作がもっさりしてる、ってのはおいといて）。

最近、もうFreeBSD7.0でいいや、という気分になってきているので、今週、えいやとアップグレードしてみたところ、なんかおかしい。

portupgradeなど、重い処理を実行中のとき、別端末でキーボードのキー入力が数秒間遅れてくるとか、かなり動きがおかしい。ちょうど、リナックスで、裏で重い処理が走っていると、シェルなどのインタラクティブな処理が影響うけまくりで、やってられない、みたいな、あんな感じ。あれよりひどいかも。

何がおきてるんだ？と思ってtopを実行すると・・・

20080503

上から3行目、CPU statesという行の表示が、いつも、全部、値が0.0%なんです。

ただ、おかしいと感じるのは、このCPU statesくらいだけ。load averageはそんなもんかな、ってかんじで、各プロセスのCPU使用率もそんなもんだろう、という感じ。

これまで、５台くらい、FreeBSD7系を使ってきて、こんな症状ははじめて見ました。

☆

Errataをチェック

まずは、エラッタ（バグ情報）がでてないか、公式サイトで確認。

http://www.freebsd.org/releases/7.0R/errata.html
FreeBSD 7.0-RELEASE Errata

無いですね。

なんとなくスケジューラをSCHED_ULEにしてみた

反応が鈍くなる、といったプロセススケジューリングに関係していることなので、SCHED_BSDからSCHED_ULEに変更して、カーネル再構築してみました。

ほとんど変化なし。

topのバグかな？と思ってcvswebで確認

この辺でしょうか。

http://www.jp.freebsd.org/cgi/cvsweb.cgi/src/usr.bin/top/machine.c

commit logで、なんとなく関係しそうなところで変更が入ってますが、どうも「0.0%になってしまう不具合」とは違いそう。

ダメもとで、4月のsnapshot版のlive fsなISOファイルをダウンロードして、topだけ実行してみましたが、やっぱりダメでした。

いや待てよ、topだけの問題なのか？と思ってvmstat

vmstatの出力を比較してみました。

正常なFreeBSD7

% vmstat 5
procs    memory    page                   disks    faults    cpu
r b w    avm fre flt re pi po fr sr ad0 ad2 in sy cs us sy id
1 1 0 318540 22264 57 0 0 0 49 3 0 0 1133 216 417 1 1 98
0 1 0 318540 22264    1 0 0 0    0 0 0 0 1131 41 378 0 0 99
0 1 0 318540 22260    3 0 0 0    1 0 2 0 1136 200 380 0 1 99

おかしなFreeBSD7

% vmstat 5
procs    memory    page                disk faults    cpu
r b w    avm fre flt re pi po fr sr ad0 in sy cs us sy id
1 0 0 134200 52872 1340 1 0 0 1246 20 0 120 1485 348 1 1 98
0 0 0 134200 52872    1 0 0 0    0 0 0 101 30 250 0 0 0
0 0 0 134200 52872    0 0 0 0    0 0 0 101 28 249 0 0 0
0 0 0 134200 52872    0 0 0 0    0 0 0 101 28 249 0 0 0

最初の1発目は無視するとして、2発目以降に注目。
右端の３列、CPUが何をしているのかを、ユーザー、システム、アイドルで分類してるので、足したら大体100％になるはずです。
ところが、おかしなFreeBSD7では、全部ゼロのまま。なんじゃこりゃ。

「sysctl -a」を見比べてみた

CPUがIntel Celeron 900MHzという、似たようなスペックのFreeBSD 7.0Rは、とくに問題なく動いているので、これとsysctl -aの違いを比較

なんとなく気になったのはtimecounterの辺。

正常なFreeBSD7
kern.timecounter.choice: TSC(800) ACPI-fast(1000) i8254(0) dummy(-1000000)
kern.timecounter.hardware: ACPI-fast
kern.timecounter.nsetclock: 4
kern.timecounter.ngetmicrotime: 49577785

異常なFreeBSD7
kern.timecounter.choice: TSC(800) ACPI-safe(850) i8254(0) dummy(-1000000)
kern.timecounter.hardware: ACPI-safe
kern.timecounter.nsetclock: 3
kern.timecounter.ngetmicrotime: 2358257

ACPI-fastとACPI-safeという、よくわかんないけど微妙な違い。

なんとなく、kern.timecounter.hardwareをTSCに変更したけど、直らない。

ACPIのせいかと疑ってsefe modeにしてみたら…

ACPIを切ろうと思って、sefe modeにしてみたら、ブート途中、ディスクad0を見つけられなくなって、ルートファイルシステムをマウントできず。終了。
はぁ？

kern.hz="100"にしてみた

古いパソコンだから、kern.hz="100"にしてみてもいいんじゃない？との思いつきで変更してみたけど、とくに変化なし。

vmstat -iで割り込みのチェック

正常なFreeBSD7

% vmstat -i
interrupt                         total    rate
irq0: clk                   522482022    1000
irq8: rtc                      66870937       127
irq9: fxp0 uhci0+             1483983       2
irq14: ata0                   1128495       2
irq15: ata1                         307       0
Total                         591965744    1133

異常なFreeBSD7

% vmstat -i
interrupt                         total    rate
irq0: clk                      1249889       99
irq1: atkbd0                         6       0
irq6: fdc0                            2       0
irq7: ppbus0 ppc0                   1       0
irq8: rtc                         1093       0
irq9: fxp0 acpi0                44175       3
irq14: ata0                      185869       14
Total                         1481035       118

変な割り込みが大量発生、ということはない。
ただ、異常な方では、rtc（real time clockかな？）が、ほとんど発生していないのが、ちょっと変な気もします。

詳しくないので、よくわかんないです。

もう一度「sysctl -a」を見比べてみた。
kern.cp_timeが怪しい？

これ、CPUの働き具合を計測するカウンタらしいです。

% sysctl -d kern.cp_time
kern.cp_time: CPU time statistics

正常なFreeBSD7では、実行するたびに、カウントアップしていきます。

% sysctl kern.cp_time
kern.cp_time: 835065 1579 512065 137986 65329647
% sysctl kern.cp_time
kern.cp_time: 835066 1579 512066 137986 65330151
% sysctl kern.cp_time
kern.cp_time: 835066 1579 512068 137988 65331158

ところが、おかしいFreeBSD7では、ほとんど変化しません。

% sysctl kern.cp_time
kern.cp_time: 10 0 8 0 1074
% sysctl kern.cp_time
kern.cp_time: 10 0 8 0 1074
% sysctl kern.cp_time
kern.cp_time: 10 0 8 0 1074

これは怪しい！ということで、ソースコードをチェック。

cp_timeでgrepしたら、すぐに見つかりました。/sys/kern/kern_clock.c でしょうね。

http://www.jp.freebsd.org/cgi/cvsweb.cgi/src/sys/kern/kern_clock.c?rev=1.202&content-type=text/x-cvsweb-markup

この関数statclockで、カウントアップさせているように見えます。

/*
* Statistics clock. Updates rusage information and calls the scheduler
* to adjust priorities of the active thread.
*
* This should be called by all active processors.
*/
void
statclock(int usermode)

7.0-RELEASEがrevision 1.202ですが、それ以降でcp_timeに大きな変更が入ってますが、どっちかっていうと、新機能の追加という感じで、不具合の修正ではないです。

だいたい、こんな中心部のところでバグってたら、topでの表示が0.0%になるFreeBSD7が、ほかにゴロゴロしてそうなものです。

☆

というわけで、まだ問題解決できていません。

今、割り込みのrtcが怪しいかな？と思っているところです。

snapshot版をアップグレードインストールするか、または、あまりよくないけど、カーネルだけ7-STABLEにして、動作確認してみる、というのが、そんなに頭を使わず、手っ取りばやいかな…

カーネルのデバッグって、やったことないので、これをいい機会に勉強してみるというのも…

■ つづき