Last-modified: Wed, 01 Mar 2000 01:01:26 JST
[static,style:furuta,jconv:jcode,cache:on]
powered by tds-Tomsoft Diary System 1.01-beta0
*BSD ブラックホールではない A 社が B な雑誌を出す らしい。
dconf を作ってみる。メモ。
で、ここで中断。uch さんの 06/06 を参照して、boot 後に kldload registry で rescan、dynamic config できるはず。
旧 newioconf.c + ioconf.c = devconf.c で、 (このあたり基本的なところは 旧 dconf とほぼ同じもの) MODULE では devconf.c から registry.ko が構成される。 ふむ、なるほど…
他に話題はないのか?
sysnewconfig990619-kld990620test8.10.patch.gz メモ。
config(8) が devconf.c を生成。 SYSINIT() のパワー (;_;) によって、 dynamic だろうが static だろうが、 カーネルに load されると devconf.c 中の files_load() が呼ばれる。 unload される時には、同様に files_unload() だな。
struct files_info 構造体に各種ツリー情報他一式が入る。 これは files ファイルと CONFIG ファイルのコンパイルされたものと 考えられる。 files_load() は、devconf.c 中にコンパイルされた files_info データを config_load() に引き渡す仕事をする。 files_unload() は config_unload() になっただけで、同様。
config_load(), config_unload() は、dconf/kern_config.c にある。 files_info 構造体は、双方から files_devconf_setup() に渡される。 config_load() では、 そののち config_deferred_rescan() でツリーの再スキャンをする。
files_devconf_setup() は、files_info 構造体の devi で回るループ。
というのを、各ループでやる。
これで新マシンを組みます。
メモ。
flathill さんのところは、
$ telnet azuki.flathill.gr.jp 7777
散財先で m-kasahr くんに遭遇。
アドレスの集合に対して、そのアドレス全部に飛ぶのが multicast で、 そのアドレスのどれかに飛ぶのが anycast.
ABIT BP6を求めてアキバを放浪した。何しろ日曜の午後 3:00 頃からうろうろしても、 どこもかしこも sold outで、もう残ってない様子。くぅ。 …とあきらめかけた頃、見つけましたよ、 BLESSで。ラッキー。ここにはまだ数枚残ってました。
本。全部 LAOX コンピュータ館
小計￥20217(税￥1010)。
CD-ROM。全部ぷらっとほーむ。
小計￥6280(税￥314)。
コンピュータ。
小計￥86840(税￥4342)。
これだけ散財したのに、秋葉原電気まつりの抽選券をくれたのは LAOX と若松通商だけだ。他は 秋葉原電気街振興会に加入していないということか。
おやあ? 「 炸裂する物欲」ですか。あんまり奇遇ではないかもしれないが。
と、思ったら CPU ファンを買い忘れてやんの(馬鹿)。実動は明日だな。
0xdeadbeef というのは、0xcafebabe とか 0xbadface みたいなもんじゃろう。
池袋で SANYO のファンと FDD を買ってから出社。
FreeBSD の場合、 こういう他に仕事をさせたくない時だけ動かしておきたいものは、 idle priority で動かしておくのが吉。
# /usr/sbin/idprio 31 -プロセスID
PID を指定せずとも、idprio から起動するようにしてもいいんだけど、 そんなことは idprio(1) を読むがよろし。 (/usr/sbin にあるのに 1 章とはこれ如何に)
nice の値は CPU の pri の初期値に使われるだけなので、 同じ realtime/idletime priority にあるプロセスならば nice を上げても 少しは CPU が割当てられる。 双方 CPU bound なプロセスの場合、意外と nice の効果は低くなる。 しかし realtime/idletime priority が違えば、 その時点での pri に値に関係なく、 「上位」のプロセスの実行が優先される。 すなわち、「上位」のプロセスによって「下位」のプロセスの stavation が発生しうる。
言うまでもないけど、runtime priority の 31 が最上位で、 idle priority の 31 が最下位、 default は normal priority だす。
某ML に昔書いたやつ。
とあるマシンの xntpd の動作を見ていると 30 分に一回程度 300ms 程度の時刻の reset をやっているようなのですが、 クロックが正確な *周波数* からのずれがあまりに大きいと、 追従ができなくてこういう症状になるようです。
xntpd の採用しているアルゴリズムだと、100ppm (1ppm は 1 Mega cycle につき 1cyle のずれの単位) 程度までのずれにはなんとか追従できるのですが、 それ以上離れるとダメなようです。
放置しておけばそのうち直りますが、 xntpd をそのマシンで起動した初日とかにこういう症状が出る場合は、 こんなふうにすると直りが早いみたいです。
$ /usr/sbin/xntpdc -c loop offset: 0.055334 s frequency: 36.668 ppm <---- これ poll adjust: 30 watchdog timer: 549 s $
# echo 200.000 > /var/run/ntp.drift
# xntpd -p /var/run/ntp.pid
これを実行しておけば、(上位のサーバとのネットワーク状態にもよりますが) 半日程度でほぼ収束状態に達っするようです。以前に安定動作させていれば、 そのマシンの水晶の特性は xntpd によって 一定時間ごとに driftfile に書きこまれているので、 まああまり大きな誤差にはならないようですが、インストールしなおした時とか、 気をつけると良いかもしれません。
とりあえず、 *BSD Diary Links掲載依頼があったので、当然承認。や、もう載ってるよ。
タレコミは aki さんと takehiro さん。情報源は nyan さん。 記憶しておこう。:-p
NetBSD/i386 も ELF にするらしい。
Message-Id: <199907050942.LAA00110@mail.wins.uva.nl> Subject: NOTICE: i386 port switched to ELF binary format From: frank@wins.uva.nl (Frank van der Linden) To: current-users@netbsd.org, port-i386@netbsd.org Date: Mon, 5 Jul 1999 11:42:29 +0200 (MET DST)
かつて見た最も壮絶な core dump は、埼京線 池袋 - 板橋 間で、 吊り皮につかまったおじさんが、シート一面に発射したものです。 私は出入口付近で立っていたからことなきを得たのですが。
すでに買うつもり。散財は散財を呼ぶ。(^^; デモのシリアル番号は、DEMOAX-0693183650-66
ようやく組み立てて FreeBSD-3.2 で動作確認。 300A では何の支障もなく無事動作。 カーネル再コンパイルして SMP 動作も問題なし。
BP6 はジャンパーでなくて BIOS からクロック設定やら 電源設定ができるのが嬉しい。 さらに BIOS から 双方の CPU の温度(どこで計ってるんだろう?) や ファンの回転数がわかるようになっている。 見ていると楽しいのだが、これ BIOS からしか見れないのでは役に立たない。 原理的にはどんな環境からも見られるに違いないと思うのだが、 この辺詳しくないので、よくわからない。 SMI つかってゴシゴシやってやらないといけないのかしらん? それとも、すでに ACPI やら SMB やらで規格が決っているのだろうか? (うーむ、つっこみ期待したりして)
300A は一発で 450A とはいかなかった。 いろいろやってみると、VCORE 電圧を 2.0V -> 2.2V にすると わりかし安定動作してくれたが、外気温 25℃ の状態で 50℃ を越えてるからね。 リミット 80℃まではずいぶん余裕があるから、この状態でロードテストを やってみて問題ないならサーバをこちらに移行する作業に入ろうと思う。
ベースクロックは 90MHz から 100MHz の間で 1MHz 刻みで 設定できるようになっているみたいなのだが、 実際に使ってみると 100MHz 以外はうまく動いてくれない模様。 もう少しいろいろ試してみたいが、あまり時間が取れない。
motoyuki さんとこから、Neco さんのとこ。 爆笑。ダメ、これ奇し過ぎ。
ちなみに、私は game を遊んだこともなければ、 アニメやドラマを見たこともないです。
大学を卒業できなかった私が言うのもナンですが、 最終的に卒業さえできれば、そう問題じゃないです。 私のようにクセにさえならなければね。 勉強の意志がコード書きの意志に負けない内に 学部卒業だけはしておいた方がいいですが。 あと、スポンサーがいれば、 いつかちゃんと謝っておいた方がよいでしょう。
…なんか、自分の懺悔状態。それでも、こうやって日々生きていられる。
え、何かよいハウジングサービスでも ご存じなんでしょうか?
azukiMOO は moo.flathill.gr.jp
あら、こんな ところに。「記憶鮮明 東京編」までは読んでたんですけどねぇ…
Newsgroups: fj.news.group.comp
Subject: [CFD] fj.comp.dev.{cpu,motherboard}
Date: 08 Jul 1999 06:05:58 GMT
Message-ID: <YAS.99Jul8150558@is.tsukuba.ac.jp>
うむ、これはまぼろしに違いない。見なかったことにしよう…
………まともな議論ができない人だとは思ってましたが、 FreeBSD と BSD 一般の区別が付けられない人だとは思ってませんでした。
発熱との戦いを佐田さんから教えていただいた。 これで50℃越えてるわけですから、かなり余裕がない状態なわけですね。 とりあえず、BIOS で設定する限界温度を60℃あたりにしてみることにします。
お、期待通り takawata さんからつっこみ :-) だ。私なりに簡単にまとめると、
ということらしい。このあたりのキーワードをつきすすめば良さそう。
確かにオブジェクト指向なのだが、クラスという概念が存在しない、みたい。 chparent() というのが、何というか、ぶよぶよしているというか、#<数字> とか、 recycle() とか、とってもほげほげしている。 うむ、表現するのが難しいな。詳しくは LambdaMOO Programmer's Manualでも読んでください。
LambdaCore のソースというのは、世の中に存在しないで、 LambdaCore.db 自体がオリジナルである、という理解で正しいんだろうか? だとすると、なんだか私のセンスというか、 環境整備本能に著しく反するシステムだなぁ。 本家での更新とローカルな更新を簡単にマージできないではないか。