diff --git a/ja/FAQ/commercial.sgml b/ja/FAQ/commercial.sgml
index aaf0da01a2..c1da99e97e 100644
--- a/ja/FAQ/commercial.sgml
+++ b/ja/FAQ/commercial.sgml
@@ -1,103 +1,184 @@
-
+
-
+
商用アプリケーション
訳: &a.junkun;.10 November 1997.
をご覧ください.
FreeBSD 用の Motif はどうやったら手に入りますか
- FreeBSD 用の Motif 2.0 に関する情報は
+
FreeBSD 用の ELF 版 Motif 2.1 に関する情報は
+ [ から
+ 手に入れることができます.]
+
+ この製品は以下の物が含まれています:
+
+ - OSF/Motif manager, xmbind, panner, wsm.
+
+
- uil, mrm, xm, xmcxx, インクルードファイルや Imake
+ ファイルといった開発者向けキット
+
+
- FreeBSD 3.0 以降で利用できる ELF 版スタティックライブラリ,
+ およびダイナミックライブラリ
+
+
- デモンストレーションプログラム
+
+
+
+
注文する際には FreeBSD 用の Motif であることをきちんと
+ 確認してください. NetBSD や OpenBSD 用の Motif もまた, Apps2go
+ から販売されています. 現在, FTP によるダウンロードのみ利用可能です.
+
+
+
+
+ または
+ 電子メールアドレス.
+
+
+
+ 他の FreeBSD 用 Motif 2.1(ELF 版, a.out 版) に関する情報は
+ [ から手に入れることができます.
+
+ ]この製品は以下の物が含まれています:
+
+ - OSF/Motif manager, xmbind, panner, wsm.
+
+
- uil, mrm, xm, xmcxx, インクルードファイルや Imake
+ ファイルといった開発者向けキット
+
+
- スタティックライブラリ, およびダイナミックライブラリ.
+ (FreeBSD 3.0 以降で利用できる ELF 版か,
+ FreeBSD 2.2.8 以前で利用できる a.out 版を指定して下さい)
+
+
- デモンストレーションプログラム
+
+
- 整形済みのマニュアルページ
+
+
+
注文する際には FreeBSD 用の Motif であることをきちんと
+ 確認してください. Linux 用の Motif も Metri Link
+ から販売されています. 現在, CDROM および FTP
+ によるダウンロードが利用可能です.
+
+
FreeBSD 用の a.out 版 Motif 2.0 に関する情報は
[ から
手に入れることができます.
]この製品は以下の物が含まれています:
- OSF/Motif manager, xmbind, panner, wsm.
- uil, mrm, xm, xmcxx, インクルードファイルや Imake
ファイルといった開発者向けキット
-
- スタティックライブラリ, およびダイナミックライブラリ
+
- FreeBSD 2.2.8 以前のバージョンで利用できるスタティックライブラリ,
+ およびダイナミックライブラリ
- デモンストレーションプログラム
- 整形済みのマニュアルページ
注文する際には FreeBSD 用の Motif であることをきちんと
- 確認してください. BSDI や Linux 用の Motif も Xi Graphics
+ 確認してください. BSDI や Linux 用の Motif もまた, Xi Graphics
から販売されています. 現在フロッピーディスク 4枚組ですが,
将来的には CDE のように統合された CD に変わるでしょう.
FreeBSD 用の CDE はどうやったら手に入りますか
FreeBSD 用の CDE 1.0.10 に関する情報は
[ から
手に入れることができます. これは Motif 1.2.5 を含んでおり,
- Motif 2.0 と一緒に使用することができます.
+ a.out 版 Motif 2.0 と一緒に使用することができます.
- ]これは FreeBSD 用と Linux 用の統合された CD-ROM です.
+
これは FreeBSD と Linux の両方に対応した CD-ROM で配布されているものです.
- 高機能な商用 X サーバってあるんですか?
+ 高機能な商用 X サーバってあるんですか?
- はい,
+ はい, と
+
から, FreeBSD ほか Intel ベースのシステムで動作する
Accelerated-X という製品が販売されています.
+
+
+ Metro Link は, FreeBSD のパッケージ操作ツールを利用することで
+ 容易に設定が行なえるほか, 数多くのビデオボードをサポートした
+ 高機能な X サーバを提供しています. 配布はバイナリ形式のみで,
+ FTP が利用可能です. もちろん, とても安価($39)に手に入れることができます.
+
+
+ また, Metro Link は ELF 版, a.out 版の FreeBSD 用 Motif
+ も販売しています(前を参照).
+
+
+
+
+
+ または
+ 電子メールアドレス
+
+
- この高性能な X サーバは楽に設定をおこなえるほか, 数多くのビデオボード
+
Xi Graphics が提供している高性能な X サーバは楽に設定をおこなえるほか,
+ 数多くのビデオボード
をサポートしています. サーバはバイナリのみが含まれます.
FreeBSD 用と Linux 用の統合されたフロッピーディスクに入っています.
+ Xi Graphics は Laptop サポートに特化した高性能 X サーバも提供しています.
-
バージョン 3.1 の「互換デモ」が無料で入手できます.
+
バージョン 5.0 の「互換デモ」が無料で入手できます.
また Xi Graphics は FreeBSD 用の Motif と CDE も販売しています (前を参照).
または
FreeBSD 用のデータベースシステムはありますか?
もちろんあります! Conetic Software Systems が FreeBSD 2.0.5
以降のシステムで動作する C/base と C/books データベースシステムを
移植しています. さらに Sleepycat Software は DB database library
の商用サポートバージョンを販売しています.
.
diff --git a/ja/FAQ/hackers.sgml b/ja/FAQ/hackers.sgml
index d1ab62f0ab..a68e93ce20 100644
--- a/ja/FAQ/hackers.sgml
+++ b/ja/FAQ/hackers.sgml
@@ -1,505 +1,584 @@
-
+
-
+
まじめな FreeBSD ハッカーだけの話題
訳: &a.iwasaki;.8 November 1997.
SNAP とか RELEASE とかは何?
現在, FreeBSD の
には, 三つのアクティブ/準アクティブなブランチがあります.
現在,
自分用のカスタムリリースを構築するには?
リリースを構築するには三つのことが必要です:
まず, ドライバが組み込まれたカーネルを実行させている必要があります.
以下をカーネルコンフィグレーションファイルに追加し,
カーネルを作り直してください:
pseudo-device vn #Vnode driver (turns a file into a device)
次に, CVS リポジトリ全体を手元においておく必要があります.
これを入手するには
-
+
が使用できますが, supfile で release の名称を cvs にして
他のタグや date フィールドを削除する必要があります:
*default prefix=/home/ncvs
*default base=/a
*default host=cvsup.FreeBSD.org
*default release=cvs
*default delete compress use-rel-suffix
## Main Source Tree
src-all
src-eBones
src-secure
# Other stuff
ports-all
www
doc-all
そして 最後に, ビルド用にかなりの空き領域を用意する必要があります.
そのディレクトリを /some/big/filesystem として,
上の例で CVS リポジトリを /home/ncvs に置いたものとすると,
以下のようにしてリリースを構築します:
setenv CVSROOT /home/ncvs # or export CVSROOT=/home/ncvs
cd /usr/src/release
make release BUILDNAME=3.0-MY-SNAP CHROOTDIR=/some/big/filesystem/release
処理が終了すると, リリース全体が /some/big/filesystem/release
に構築され, 完全な FTP インストール用の配布物が
/some/big/filesystem/release/R/ftp に作成されます.
-current 以外の開発ブランチの SNAP を自分で構築したい場合は,
カスタムのインストールディスクを作るにはどうすればいいのですか?
/usr/src/release/Makefile のいろいろなターゲットとして
インストールディスク, ソース, バイナリアーカイブを作る完全な処理を
自動的におこなうようになっています. Makefile に十分な情報があります.
しかし, 実行には ``make world'' が必要で,
多くの時間とディスクの容量が必要です.
``make world'' をおこなうと既存のバイナリを上書きしてしまうのですが.
ええ, それが一般的な考え方です. 名前が示しているように
``make world'' はすべてのシステムのバイナリを一から作り直しますので,
結果としてクリーンで一貫性のある環境を得ることができます
(これがそれだけ長い時間がかかる理由です).
環境変数 ${DESTDIR} を root とみなした
ディレクトリツリーにインストールされます.
あるでたらめな共有ライブラリの変更やプログラムの再構築によって
``
システムブート時に ``(bus speed defaulted)'' とメッセージが出ます.
アダプテックの 1542 SCSI ホストアダプタはユーザがソフトウェア的に
バスアクセス速度の設定をおこなうことができます. 以前のバージョンの
1542 ドライバは使用可能な最大の速度を求めてアダプタを
その設定にしようとしました. これは特定のユーザのシステムでは
問題がある事がわかり, 現在ではカーネルコンフィグオプションに
``
- インターネットアクセスに制限があっても current を追いかけられますか?
+ インターネットアクセスに制限があっても current を追いかけられますか?
+
-
はい, を使って
+ はい, を
+ 使って
ソースツリー全体のダウンロードを
どのようにして配布ファイルを 240kバイトに分割しているのですか?
比較的新しい BSDベースのシステムでは split に任意のバイト境界で
分割する ``以下は /usr/src/Makefile からの例です.
bin-tarball:
(cd ${DISTDIR}; \
tar cf - . \
gzip --no-name -9 -c | \
split -b 240640 - \
${RELEASEDIR}/tarballs/bindist/bin_tgz.)
私はカーネルに拡張をおこないました. 誰に送ればいいですか?
を参照してください.
あなたのアイディアに感謝します!
PnP ISA カードの検出と初期化はどのようにおこなうのですか?
氏より:
要点は, ホストが認識されていないボードを探す時に, すべての
PnP ボードが応答することのできる少数の I/O ポートがあるという
ことです. それにより, PnP プローブルーチンが開始したとき, PnP
ボードが存在するなら, すべての PnP ボードは自分のモデル番号を
返します. そのポートを I/O read するとプローブルーチンは
問いに対するワイアード-OR された ``yes'' を得ます. この場合は
少なくとも 1ビットが ON になります. そして, プローブルーチンは
モデル ID (Microsoft/Intel によって割り当てられています)
が X より小さいボードを ``オフライン'' にすることができます.
この操作をおこない, 問い合わせに応答しているボードがまだ
残っているかどうかを調べます. もし ``ID は二つの 32-bit (つまり 64bit) フィールド + 8 bit
チェックサムからなります. 最初の 32 bits はベンダの識別子です.
これは公表されてはいませんが, 同一のベンダから供給されている
異なるタイプのボードでは異なる 32-bit ベンダ ID を持つことが
できるように考えられます. 製造元を特定するだけのために 32 bits
はいくらか過剰です.
下位の 32 bits はシリアル番号, イーサネットアドレスなどの
ボードを特定するものです. ベンダは上位 32 bits が異なっていない
のであれば下位 32 bits が同一である 2枚目のボードを製造することは
ありません. したがって, 同じタイプの複数のボードをマシンに
いれることができ, この場合でも 64 bits 全体ではユニークです.
32 bit のフィールドはすべてを 0 にすることはできません.
これは初期化のバイナリサーチの間ワイアード-OR によって 0 ではない
ビットを参照するからです.
システムがすべてのボードの与えられた ID を認識すると,
それぞれのボードに対応した処理を一つずつ (同一の I/O ポートを通して)
おこないます. そして, 利用できる割り込みの選択などのボードが必要
とするリソースを検出します. すべてのボードについてこの情報を集めます.
この情報はハードディスク上の ECU ファイルなどの情報とまとめられ,
マザーボードの BIOS にも結合されます. マザーボード上のハードウェア
への ECU と BIOS PnP のサポートは通常は統合されていますが,
周辺機器については真の PnPであるとはいえません.
しかし, BIOS の情報に ECU の情報を加えて調査することで,
プローブルーチンは PnP デバイスが再配置できなくなることを
避けることができます.
それから, 再度 PnP デバイスにアクセスし, I/O, DMA, IRQ,
メモリマップアドレスの設定をします. デバイスはこのアドレスに
見えるようになり, 次にリブートするまでこの位置を占めます. しかし,
あなたの望む時に移動させることが不可能であるといっている
わけではありません.
以上の話では大きく単純化をしてありますが, 基本的な考え方は得
られたでしょう.
マイクロソフトはボードのロジックが 対立するI/O サイクルでは
デコードしていない (訳注: おそらく read 時しかデコードされていず
write 時はポートが空いているという意味でしょう)
プライマリプリンタのステータスポートのいくつかを PnP のために
占有しました. 私は初期の PnP の提案レビュー時に IBM 純正の
プリンタボードでステータスポートの write のデコードがされている
ということに気がつきましたが, MS は ``tough (頑固, 不運,
無法な)'' と言っています. そしてプリンタのステータスポートへ
アドレスの設定のために write をおこなっています. また,
そのアドレス +
FreeBSD は, 他のアーキテクチャをサポートしないんですか?
いくつかのグループの人々が, FreeBSD の他のアーキテクチャへの
移植に関心を示しており, FreeBSD/AXP (ALPHA) はこれらの成果としては
とても成功したものの一つです. FreeBSD/AXP は 3.0 スナップショット
リリースが現在 から入手できます.
ALPHA への移植版が現在動く機種は増えつつあり, その中には AlphaStation,
AXPpci, PC164, Miata そして Multia といったモデルが含まれています.
この ALPHA への移植版はまだ完全なリリースとはみなされていません.
システムインストールツール一式や CDROM のインストールメディアの
配布が提供され, 適度な数の ports や packages が動くようになって
からになるでしょう.
現在のところ FreeBSD/AXP はベータクオリティのソフトウェアと
みなすべきです. 現状についての情報を得るには
<freebsd-alpha@FreeBSD.ORG> [ に参加してください.
その他に FreeBSD の SPARC アーキテクチャへの移植があります.
プロジェクトへの参加に興味がある方は
]<freebsd-sparc@FreeBSD.ORG> [ に参加してください.
新しいアーキテクチャに関する一般的な議論については
]<freebsd-platforms@FreeBSD.ORG> [ へ参加してください.
]
デバイスドライバを開発したので, メジャー番号が必要です.
これは, 開発したドライバを公開するかどうかに依存します.
公開するのであれば, ドライバのソースコード, files.i386 の変更,
コンフィグファイルのサンプル, デバイスが使うスペシャルファイルを作成する
のコードを私たちに送ってください. 公開するつもりがない場合, ライセンスの
問題により公開できない場合は, キャラクタメジャー番号 32 もしくは
ブロックメジャー番号 8 が, このような目的のために予約されています.
これらの番号を使用してください. どちらの場合であれ, ドライバに関する情報を
<freebsd-hackers@FreeBSD.ORG> に流して頂けると助かります.
代替のディレクトリ配置ポリシー
現在使われているディレクトリの配置ポリシーは, 私が 1983 年に書い
たものから全く変更されていません. 私は当初の配置ポリシーを, オリ
ジナルの fast filesystem のために書き, まったく改定していません.
このポリシーはシリンダグループを使い尽くすのを防ぐにはうまくいき
ましたが,お気づきの方もいる通り find の動作には不適切です. ほと
んどのファイルシステムの内容は, 深さ優先検索 (ftw とも呼ばれます)
によって作られたアーカイブからレストアして作成されます. この際,
ディレクトリは,シリンダグループにまたがって配置され, 以降の深さ
優先検索を行うには考え得る限り最悪の状態になります. もし作成する
ディレクトリの総数がわかっていれば, 解決方法はあります. (総数 /
シリンダグループ数)個のディレクトリをシリンダグループごとにまと
めて作成すれば良いのです. もちろん最適なディレクトリ配置になるよ
うに, 総数を予測する方法を考えなければなりません. しかし仮にシリ
ンダグループあたりのディレクトリ数を 10 くらいの小さな数に固定し
てしまったとしても, 大幅な改善が望めるでしょう. このポリシーを用
いるべきリストア作業を, 通常の作業(おそらく既存のポリシーを使用
したほうが良いでしょう)を区別するには, 10 秒間の間に作成されたディ
レクトリを最大 10 個までまとめて単一のシリンダグループに書き込む
という手順が使えるでしょう. とにかく私の結論は, そろそろ実験
を始めて見る時期だろうということです.
カーネルパニックを最大限に利用する
[この節は, freebsd-current [ に ]
が投稿したメールを, が校正し,括弧内のコ
メントを追加して引用したものです. ]
From: Bill Paul
Subject: Re: the fs fun never stops
To: ben@rosengart.com
Date: Sun, 20 Sep 1998 15:22:50 -0400 (EDT)
Cc: current@FreeBSD.ORG
[<ben@rosengart.com> が以下のパニックメッセージを
投稿しました.]
> Fatal trap 12: page fault while in kernel mode
> fault virtual address = 0x40
> fault code = supervisor read, page not present
> instruction pointer = 0x8:0xf014a7e5
^^^^^^^^^^
> stack pointer = 0x10:0xf4ed6f24
> frame pointer = 0x10:0xf4ed6f28
> code segment = base 0x0, limit 0xfffff, type 0x1b
> = DPL 0, pres 1, def32 1, gran 1
> processor eflags = interrupt enabled, resume, IOPL = 0
> current process = 80 (mount)
> interrupt mask =
> trap number = 12
> panic: page fault
このようなメッセージが表示された場合, 問題が起きる状況を確認し
て, 情報を送るだけでは十分ではありません. 下線をつけた命令ポインタ
値は重要な値ですが, 残念ながらこの値は構成に依存します. つまり, こ
の値は使っているカーネルのイメージに依存するのです. もしスナップショッ
トなどの GENERIC カーネルを使っているのであれば, 他の人間が問題の
ある関数について追試をすることができますが, カスタマイズされたカー
ネルの場合は, 使っている本人にしか問題の起こった場所は特定できない
のです.
何をすれば良いのでしょう？
- 命令ポインタ値をメモします.
システムがリブートしたら, 以下の操作を行います:
% nm /kernel.that.caused.the.panic | grep f0xxxxxx
ここで,
% nm /kernel.that.caused.the.panic | grep f0xxxxx
これでも一致しない場合は, 桁を減らしながら何らかの出力があるま
で繰り返してください. 何か出力されたら, それがカーネルパニック
を引き起こした可能性のある関数のリストです. これは, 問題点を見付ける
正確な方法ではありませんが, 何もないよりましです.
このようなパニックメッセージを投稿している人はよく見掛けますが,
このように, 命令ポインタ値を, カーネルシンボルテーブルの中の関数
とつき合わせて調べている人はまれです.
パニックの原因を突き止める最良の方法は, クラッシュダンプをとり,
どっちにしろ, 私は普通以下のようにします.
- カーネルコンフィグファイルを作ります. カーネルデバッガが
必要そうであれば options 'DDB' を加えても良いです(私は永久ルー
プが起こっていそうな場合に, ブレークポイントを設定するのに使って
います).
-
cd /sys/compile/KERNELCONFIG; make
- カーネルのコンパイルが終了するのを待ちます.
cp kernel /
- reboot
[注: 現在 FreeBSD 3.x kernel はデフォルトで ELF 形式となっており,
全てのデバッグシンボルを含んだカーネルを, 実際にブートする必要は
ありません. 確実にクラッシュダンプをとるには, /etc/rc.conf を編
集して /etc/rc.conf で設定されていれ ば, /var/crash に保存します.
注: FreeBSD のクラッシュダンプのサイズは, ふつう物理メモリサ
イズと同じです. つまり 64MB のメモリを積んでいれば, 64MB のクラッ
シュ ダンプが生成されることになります. /var/crash に十
分な空き 容量があることを確認してください. 手動で
クラッシュダンプを取り出せたら, 以下のように
% gdb -k /sys/compile/KERNELCONFIG/kernel.debug /var/crash/vmcore.0
(gdb) where
必要な情報が 1 画面に収まらないことも多いので, できれば
もしあなたがデバッグ狂で, 同時に別のコンピュータを利用できる
環境にあれば, [Bill による注: DDB を有効にしていてカーネルがデバッガに
落ちたら, ddb のプロンプトで 'panic' と入力すれば, 強制的にパニッ
クを 起こしクラッシュダンプさせることができます. パニックの途中
で, 再び デバッガに落ちるかもしれませんが, 'continue' と入力すれ
ば, クラッシュダンプを最後まで実行させられます.]
dlsym() が ELF 実行形式では動作しなくなります!
ELF のツール類は, デフォルトでは実行形式の中に定義されている
シンボルをダイナミックリンカから見えるようにはしません.
このため, dlopen(NULL, flags) を呼び出して得られた
ハンドルに対して dlsym() で探索を行っても, こういった
シンボルを見つけられません.
もし, あなたがプロセスの中心にあたる実行形式の中にある
シンボルを探索したければ,
に -export-dynamic オプションを
付けて実行形式をリンクする必要があります.
+
+
+
+ カーネルアドレス空間を大きくしたり、小さくするにはどうしたら良いのですか?
+
+
+ カーネルアドレス空間は, FreeBSD 3.x 上で
+ 256MB, FreeBSD 4.x 上で 1GB がデフォルトになっています.
+ 負荷の高いネットワークサーバ(例えば大きな FTP, HTTP サーバ)を運用する場合は,
+ 256MB では足りないことに気付くかも知れません.
+
+
+ では, アドレス空間を大きくするにはどうしたら良いのでしょうか?
+ それには, 二つの段階を踏みます. まず,
+ より大きいアドレス空間を割り当てることをカーネルに知らせる必要があります.
+ 次に, カーネルはアドレス空間の先頭にロードされるため,
+ アドレスの先頭が天井(訳注:カーネルアドレス空間の最下端アドレスのこと)と
+ ぶつかることのないように, ロードアドレスを今までより低位に設定する必要があります.
+
+
+ 最初の段階は, src/sys/i386/include/pmap.h にある
+
+#ifndef NKPDE
+#ifdef SMP
+#define NKPDE 254 /* addressable number of page tables/pde's */
+#else
+#define NKPDE 255 /* addressable number of page tables/pde's */
+#endif /* SMP */
+#endif
+
+
+
+ 正確な
+ 次の段階を行なうには, ロードアドレスを正確に計算することが必要です.
+ 単純に, アドレス空間の大きさ(バイト単位)を 0x100100000 から引き算して下さい.
+ 1GB アドレス空間の場合, その結果は 0xc0100000 になります.
+ そして, src/sys/i386/conf/Makefile.i386 にある src/sys/i386/conf/kernel.script のセクションの始めの方にある
+ ロケーションカウンタにも同じ値を入れて下さい.
+
+
+OUTPUT_FORMAT("elf32-i386", "elf32-i386", "elf32-i386")
+OUTPUT_ARCH(i386)
+ENTRY(btext)
+SEARCH_DIR(/usr/lib); SEARCH_DIR(/usr/obj/elf/home/src/tmp/usr/i386-unknown-freebsdelf/lib);
+SECTIONS
+{
+ /* Read-only sections, merged into text segment: */
+ . = 0xc0100000 + SIZEOF_HEADERS;
+ .interp : { *(.interp) }
+
+
+
+ それが完了したら, config し直してカーネルを再構築して下さい.
+ おそらく, /usr/include/vm/
+ にコピーした後に,
+ 注意: カーネルアドレス空間の大きさは, 4 メガバイトの倍数である必要があります.
+
+
+ [
+ による補足: カーネルアドレス空間は 2 の乗数である必要があると思いますが,
+ それが確かなことかどうかははっきりしていません.
+ 昔の起動コードには, 良く高位アドレスビットのトリックが使われていたため,
+ 少なくとも 256MB の粒度であることが想定されていたと思います.]
diff --git a/ja/FAQ/network.sgml b/ja/FAQ/network.sgml
index 980315bc71..a864bdeb06 100644
--- a/ja/FAQ/network.sgml
+++ b/ja/FAQ/network.sgml
@@ -1,1160 +1,1291 @@
-
+
-
+
ネットワーキング
訳: &a.arimura; &a.shou; &a.nishika;
&a.kiroh .
4 October 1998.
``diskless boot'' に関する情報はどこで得られますか?
``diskless boot'' というのは, FreeBSD がネットワーク上で起動し,
必要なファイルを自分のハードディスクではなくてサーバから読み込むものです.
詳細については
を読んでください.
FreeBSD をネットワークの router として使用することはできますか?
インターネット標準やこれまでのよい経験によって指摘されている通り,
FreeBSD は標準ではパケットを forward するように設定されていません.
しかし, の中で次の変数の値を
gateway_enable=YES # Set to YES if this host will be a gateway
このオプションによって の変数
ほとんどの場合, router についての情報を同じネットワーク
の他の計算機等に知らせるために, 経路制御のためのの process
を走らせる必要があるでしょう. FreeBSD には BSD の標準経路制御デーモン
である
が付属していますが, より複雑な状況に対処するためには
注意してほしいのは, FreeBSD をこのようにして使用している場合でも,
router に関するインターネット標準の必要条件を完全には満たしていない
ということです. しかし, 普通に使用する場合にはほとんど問題ありません.
Win95 の走っているマシンを, FreeBSD 経由でインターネットに接続できますか?
通常, この質問が出てくる状況は自宅に二台の PC があり, 一台では
FreeBSD が, もう一台では Win95 が走っているような場合です.
ここでやろうとしていう事はFreeBSDの走っている計算機をインターネット
に接続し, Win95 の走っているマシンからは FreeBSD の走っているマシンを
経由して接続をおこなう事です. これは二つ前の質問の特別な場合に相当します.
FreeBSDをとして設定する方法については,
役に立つ文書があります.
や
のような また, [ に関する節も参照してください.
]
ISC からリリースされている BIND の最新版は compile できないんでしょうか?
BIND の配布物と FreeBSD とでは ``compat/include/sys/cdefs.h を削除してください.
FreeBSD で SLIP と PPP は使えますか?
使えます. FreeBSD を用いて他のサイトに接続する場合には,
,
,
そして
のマニュアルページを見てください.
は SLIP のサーバ専用で,
は SLIP のクライアント専用です.
これらのプログラムの解説が,
の以下のセクションにあります.
-
「シェルアカウント」を通じてのみインターネットへアクセス可能な場合,
package みたいなものが欲しくなるかもしれませんね.
これを使えば, ローカルマシンから直接 ftp や http のようなサービスに
(限定的ではありますが) アクセスすることができます.
FreeBSD は NAT か IP マスカレードをサポートしていますか?
ローカルなサブネット (一台以上のローカルマシン) を持っているが,
インターネットプロバイダから 1 つしか IP アドレスの割り当てを
受けていない場合 (または IP アドレスを動的に割り当てられている場合でも),
プログラムを使いたくなるかもしれませんね.
も, 同様の機能を持っており,
が使われます.
まず のマニュアルと, のマニュアルと, を読んでみましょう. 次に,
set log Phase Chat Connect Carrier lcp ipcp ccp command
という命令を /etc/ppp/ppp.conf
に加えて
(default セクションの先頭に加えるのが一番良いでしょう)
ログを有効にしてみてください. その際, に
!ppp
*.* /var/log/ppp.log
と書かれた行が含まれているか, また, /var/log/ppp.log
が存在しているかどうか確かめておいてください. さて, これで
何が起きているのか突き止めるために, ログファイルからたくさんの
情報を得られるようになりました. ログに訳の分らない部分があっても
心配ご無用. あなたが助けを求めた誰かにとっては, その部分が
意味をなす場合があるのです.
訳注: ログの取得に syslog を使用するようになったのは
2.2.5 以降からです.
使用中の ppp のバージョンで "set log" 命令を解釈しない場合は,
をダウンロードすべきです. FreeBSD の 2.1.5 以降でビルドできます.
ppp を実行するとハングします
ホスト名の解決がうまくいっていないのでしょう. まず,
リゾルバが /etc/hosts を参照するように,
/etc/host.conf の最初の行に host と書き込んでください.
つぎに, /etc/hosts に使用しているマシンのエントリを
書き加えます. ローカルでネットワークを使用していない場合は,
localhost の行を以下のように変更してください:
127.0.0.1 foo.bar.com foo localhost
使用しているホストのエントリを追加してもかまいません.
詳細は関連するマンページを参照してください.
ppp が -auto モードでダイアルしてくれない
まず最初に, デフォルトルートが確立しているかどうかチェックして
ください. を実行すると, 以下のような情報が表示されるはずです.
Destination Gateway Flags Refs Use Netif Expire
default 10.0.0.2 UGSc 0 0 tun0
10.0.0.2 10.0.0.1 UH 0 0 tun0
これはあなたがハンドブックやマニュアル, ppp.conf.sample の中で
出てくるアドレスを使用していると仮定した場合の例です.
デフォルトルートが確立していない場合, ppp.conf の中の が走っている可能性があります. FreeBSD 2.2.5 より前の
バージョンに付属していた
add 0 0 HISADDR
と書かれた行を以下のように修正してください.
add 0 0 10.0.0.2
netstat -rn でデフォルトルートの情報が表示されない場合, もう一つ,
(2.2.2 より前のリリースでは
/etc/sysconfig と呼ばれていました) の中でデフォルトの
ルータを誤って設定し, ppp.conf から
delete ALL
の行をうっかり消してしまった可能性があります.
この場合は, ハンドブックの
- の項を読み直してください.
"No route to host" とはどういう意味ですか?
このエラーは通常, /etc/ppp/ppp.linkup に以下のような
セクションが無い場合に起こります.
MYADDR:
delete ALL
add 0 0 HISADDR
これは動的 IP アドレスを使用している場合, またはゲートウェイの
アドレスを知らない場合にのみ必要な設定です. インタラクティブモード
を使用している場合,
delete ALL
add 0 0 HISADDR
詳しい情報については, ハンドブックの
- の項を参照してください.
3 分ほど経つと接続が切れてしまう
ppp のタイムアウトは デフォルトでは 3 分です. これは
set timeout NNN
という命令によって調整することができます. ppp.conf
に入れることも, インタラクティブモードでプロンプトから入力することも
できます. ソケットを用いる
か
を使用し, 訳注 pppctl は 2.2.5R からです.
詳しい情報は
のマニュアルを参照してください.
負荷が高いと接続が切れてしまう
Link Quality Reporting (LQR) の設定を行っている場合,
マシンと接続先の間で非常にたくさんの LQR パケットが失われている
可能性があります. 結果として ppp は回線の具合いが悪いと考え,
回線を切断するのです. 2.2.5 より前のバージョンの FreeBSD では
LQR はデフォルトで有効になっています. 現在ではデフォルトの状態で
無効です. LQR は以下の命令で無効にすることができます.
disable lqr
接続がランダムに切れてしまう
時々, ノイズの多い回線, あるいは待ち機能付きの回線では,
モデムが (誤って) キャリアを失ったと思い込み, ハングアップしてしまう
ことがあります.
大多数のモデムでは, 一時的なキャリアの喪失にどれだけ我慢するか
設定で決めることができます. 例えば USR Sportster では, S10 レジスタ
の値を 10 倍した秒数がその値になります. この場合, モデムをもっと
のんびり屋さんにするには, dial 行に次のような文字列を加えると
良いでしょう.
set dial "...... ATS10=10 OK ......"
詳しくはお使いのモデムのマニュアルをご覧ください.
+
+ 接続が不規則にハングアップしてしまう
+
+ たくさんの人が, 原因不明のハングアップを経験しています.
+ 検証のために必要なのは, まずどちら側のリンクでそれが起こっているか,
+ ということです.
+
+
外部接続型モデムを利用しているなら, 単に 問題が回線のどちら側かにあることが分かったら,
+ つぎの二つの可能性が考えられるでしょう.
+
+
+ 回線の向こう側での反応がない
+
+ これに対処できることはほとんどありません. 大部分の ISP
+ は, Microsoft 社製 OS 以外の利用者に対してのサポートを拒否するでしょう.
+ まず最初に, こちら側の圧縮機能を全て無効にしてみて下さい.
+ それには, 設定ファイルをつぎのようにします.
+
+
+ disable pred1 deflate deflate24 protocomp acfcomp shortseq vj
+ deny pred1 deflate deflate24 protocomp acfcomp shortseq vj
+
+
+
そして再接続し, 変更前と同じように通信できることを確認します.
+ もしこれによって状況が改善されるか, 完全に解決したら,
+ (上の設定のうち)どの設定で状況が変化したのかを,
+ 色々な組合せで試してみて下さい. これは, ISP
+ に問い合わせを行なうときの有効な情報となります(ただし,
+ あなたが Microsoft 社製品以外のものを利用していることも
+ 明らかにしてしまいますが).
+
+
ISP に問い合わせを行なう前に, こちら側の非同期ログを有効にして,
+ 接続がハングアップするまで待って下さい. この作業は,
+ 非常に多くのディスク空間を消費するかも知れません.
+ 興味の対象となっているのは, 通信ポートから最後に読み込まれたデータです.
+ それは通常 ASCII データで, 問題点の詳細(``Memory fault, core dump''など)が
+ 記載されている可能性があります.
+
+
回線の向こう側で通信ログを監視することは可能なはずですので,
+ ハングアップが発生した時, ISP の対応が好意的ならば
+ どうして ISP 側で問題が発生したのかこちらに伝えてくれるかも知れません.
+
+ まで詳細を送って頂くか, ISP に直接私に連絡するように伝えて下さっても構いません.
+
+
+ ppp がハングアップする
+
+ ベストな方法は, スタックトレースの結果は, まで送って下さい.
+
Login OK! のメッセージが出た後, 何も起こらない
2.2.5 より前のリリースの FreeBSD では,
はリンクが確立した後, 接続先が Line Control Protocol (LCP)
- を発信するのを待ちます. しかし, 多くの ISP ではネゴジェーションを
+ を発信するのを待ちます. しかし, 多くの ISP ではネゴシエーションを
自分からは起こさず, クライアントが起こすのを待っています.
set openmode active
でもまだ "magic is the same" というエラーが出る
時折, 接続直後のログに "magic is the same" というメッセージが
あらわれることがあります. このメッセージがあらわれても何も起きない
場合もありますし, どちらかの側が接続を切ってしまう場合もあります.
ppp の実装の多くはこの問題に対応できておらず, その場合にはちゃんと
link が上がっている状態であっても, ppp が最終的にあきらめてしまい
接続を切るまで, 設定のリクエストが繰り返し送られ, 設定が行われた
という通知が log ファイルに残ると思います.
これは通常, ディスクアクセスの遅いサーバマシンのシリアルポートで
getty が生きていて, ppp がログインスクリプトか, ログイン直後に
起動されたプログラムから実行されている場合に起こります. slirp を使用
している場合に同様の症状が見られたという報告もあります. 原因は
getty の終了されるまでと, ppp が実行され, クライアント側の ppp が
Line Control Protocol (LCP) を送り始めるまでのタイミングにあります.
サーバ側のシリアルポートで ECHO が有効なままになっているので,
クライアント側の ppp にパケットが「反射」してしまうのです.
LCP ネゴジェーションの一部として, リンクの両サイドで magic number
を定めて, 「反射」が起きていないかどうか確かめる作業があります.
規約では, 接続相手がこちらと同じ magic number を提示してきたら,
NAK を送って新しい magic number を選択しなければならないと
定めています. この作業の間, サーバのシリアルポートの ECHO がずっと
有効になったままなので, クライアント側の ppp は LCP パケットを送り,
パケットが反射して全く同じ magic number が送られてくるのを見つけ,
それに対して NAK を送るのです. 一方 NAK 自体も (これは ppp が magic
number を変更しなければいけないことを意味しています) 反射して
くるので, 結果として magic number が数えきれないほど変更され,
その全てがサーバの tty バッファの中に積み重なることになるのです.
サーバでスタートした ppp はとすぐ magic number であふれかえってしまい,
LCP のネゴジェーションを十分に行ったものと判断して, さっさと接続を
切ってしまいます. 一方, クライアント側は反射が帰ってこなくなったので
満足しますが, それもサーバが接続を切ったことを知るまでです.
この事態は, 以下の行を ppp.conf の中に書いて, 相手がネゴシェー
ションを開始できるようにする事によって回避できます.
set openmode passive
これで ppp はサーバが LCP ネゴジェーションを起こすのを待つように
なります. しかし, 自分からは決してネゴジェーションを起こさないサーバ
もあるかもしれません. もしこの状況に遭遇した場合には, 次のようにして
ください.
set openmode active 3
これによって ppp は 3 秒間 passive モードを続けた後で LCP リク
エストを送り始めます. この間に相手がリクエストを送り始めた場合には
3 秒間待たずにこのリクエストに即座に応答します.
接続が切れるまでLCPのnegotiationが続く.
これが, 片方のこれを回避する最も良い方法は, 片方を
set openmode passive
というコマンドでできます. このオプションは気を付けて使わないといけ
ません. さらに
set stopped N
というコマンドを追加して,
set openmode active N
というコマンド(ここで,
ppp が接続直後に固まってしまう
2.2.5 より前のバージョンの FreeBSD では,
disable pred1
ppp の内部でシェルを起動しようとすると固まってしまう
このような場合は, 代わりに
ヌルモデムケーブルを使用しているとき, ppp が終了しない
ヌルモデムケーブルを使用して直接接続している場合,
enable lqr
- こうすると, 接続先がネゴジェーションを行う場合, デフォルトで
+
こうすると, 接続先がネゴシエーションを行う場合, デフォルトで
LQR の使用を受け入れるようになります.
ppp を -auto モードで動かすと, 勝手にダイアルすることがある
原因を突き止めるためには, 以下の命令を使用してください.
set log +tcp/ip
これで接続を通過する全てのトラヒックをログに残すことができるように
なりました. 次に突然回線がつながったときのログのタイムスタンプを
たどれば, 原因を突き止めることができるはずです.
原因がわかったら, 次に, このような状況ではダイヤルが起こらないように
しましょう. 通常, この手の問題は, DNS で名前の解決をしようとしたために
起こります. DNS による名前の解決によって, 接続が行われるのを防止する
には, 次のような手段を用います (これは
set dfilter 1 deny udp src eq 53
set dfilter 2 deny udp dst eq 53
set dfilter 3 permit 0/0 0/0
これはデマンドダイヤル機能に問題を生じさせるため,
常に適切であるとはかぎりません. ほとんどのプログラムは
他のネットワーク関連の処理をおこなう前に DNS への問い合わせ
が必要になります.
DNS の場合は, 何が実際にホスト名を検索しようとしているのかを
突き止めるべきでしょう. 大抵の場合は,
が犯人です. 設定ファイルで sendmail が
DNS に問い合わせないようになっているか確認すべきです.
自分用の設定ファイルを作成するための詳しい方法は
[ の節をご覧ください.
または, ]
define(`confDELIVERY_MODE', `d')dnl
この行を追加すると, sendmailはメールキューを処理する
(通常sendmailは30分ごとにキューを処理するよう, ``-bd -q30m''
というオプションを付けて起動されます)
までか, または
(多分ppp.linkupというファイルの中で)
``sendmail -q''というコマンドが実行されるまで, 全てのメールを
キューに溜めるようになります．
訳注 ``sendmail -q'' はその時点のメールキューの内容を処理して
終了します．
CCP エラーとはどういう意味ですか
ログファイル中の以下のエラーは,
CCP: CcpSendConfigReq
CCP: Received Terminate Ack (1) state = Req-Sent (6)
ネゴジェーションにおいて ppp は Predictor1 圧縮を用いるべく主張したが,
接続先は圧縮を使用しないことを主張した場合に起こります. このメッセージ
には何の害もありませんが, 出るのが嫌なら, 以下の命令を用いて
こちら側でも Predictor1 圧縮を無効にすることで対応できます.
disable pred1
ファイル転送の途中で, ppp が IO エラーを出して固まってしまう
FreeBSD 2.2.2 以前のバージョンの tun ドライバには, tun インタフェース
の MTU のサイズより大きなパケットを受け取ることができないというバグが
ありました. MTU のサイズより大きなパケットを受け付けると IO エラーが
起こり, syslogd 経由で記録されるのです.
ppp の仕様では, LCP のネゴジェーションを行う場合を含む
どのような場合でも 最低 1500 オクテットの
Maximum Receive Unit (MRU) を受け入れる必要があります.
ですから, MTU を 1500 以下に設定した場合でも, ISP はそれに関係なく
1500 の大きさのパケットを送ってくるでしょう. そしてこのイケてない
機能にぶちあたって, リンクが固まるのを目にすることになるのです.
FreeBSD 2.2.2 以前のバージョンでは, MTU を決して 1500 より小さく
しないことで, この問題を回避することができます.
どうして ppp は接続速度をログに残さないんでしょう?
モデムとの「やり取り」全ての行をログに残すには,
以下のようにして接続速度のログの有効化を行ってください:
set log +connect
これは
に最後にくることが要求されている "expect" という文字列がくるま
でのすべてのものをログに記録させます.
接続速度はログにとりたいけれど, PAP や CHAP を使っている
(その結果, dial スクリプト中の CONNECT 以降に全く「やりとり」
を行わない - "set login" スクリプトには何も書かない) のであれ
ば, ppp に "expect" を含んだ CONNECT 行全てがくるまで待たせる
ようにしないといけません, 以下のようになります:
set dial "ABORT BUSY ABORT NO\\sCARRIER TIMEOUT 4 \"\" ATZ OK-ATZ-OK ATDT\\T TIMEOUT 60 CONNECT \\c \\n"
ここで, CONNECT を受信してから, 何も送らず, linefeed を
待っています,
私のchatスクリプトでは`\'という文字をPPPが解釈して
くれません
PPPは設定ファイルを読み込むときに, chatの各引数が解釈されるときには, ``\P''や``\T''のような
特別なescape sequence (man pageを見てください)を見付けるために
もう1回parseを行います. このようにparseは2回繰り返されま
すので, 正しい回数だけescapeを行わないといけません.
モデムにたとえば``\''のような文字を送りたい場合には, 次のように
する必要があります:
set dial "\"\" ATZ OK-ATZ-OK AT\\\\X OK"
実際にモデムに送られる文字列は次のようになります:
ATZ
OK
AT\X
OK
他の例ですと
set phone 1234567
set dial "\"\" ATZ OK ATDT\\T"
は次のようになります:
ATZ
OK
ATDT1234567
ppp が segmentation fault になるのですが,
ppp (や他のプログラム) はけして core を吐いてはいけません.
ppp は 実効 uid が 0 で動いていますので, オペレーティングシステム
は ppp を終了させる前にディスクに core イメージを書き込みません.
しかし ppp は実際にはセグメンテーション違反や他の core を吐く原因
となるようなシグナルによって
$ tar xfz ppp-*.src.tar.gz
$ cd ppp*/ppp
$ echo STRIP= >>Makefile
$ echo CFLAGS+=-g >>Makefile
$ make clean all
$ su
# make install
# chmod 555 /usr/sbin/ppp
これで debug 可能なバージョンの ppp がインストールされます.
root で ppp を実行し, 全ての特権が無効になっているようにする必要
があるでしょう. ppp を実行する時には, current directory が make
した directory であるようにしてください.
これで, ppp がセグメンテーション例外を受け取ったときには
ppp.core という名前の core ファイルを吐くようになります. core が
吐かれたら次のようにしてください:
$ su
# gdb /usr/sbin/ppp ppp.core
(gdb) bt
.....
(gdb) f 0
.....
(gdb) i args
.....
(gdb) l
.....
質問する際には, これら全ての情報を提供して, 問題点の分析ができ
るようにしてください.
gdb の使い方に慣れている場合には, 実際に dump の原因となった
理由やそのアドレス, 関連した変数の値なども調べる事ができるでしょう.
-
- auto modeでdialをするようなprocessがconnectしてくれない
-
-
- これはauto mode でダイアルをするようなプロセスが接続されない
+
+ これは を呼び出した時, tun intergaceのIP numberが
- socketのendpointに割り当てられます. kernelは最初に外へ出ていく
- packetを作り, それをtunデバイスへ書きます. 次に を呼び出した時, tun インターフェイスの IP
+ アドレスが, ソケットの終端に割り当てられてしまうという問題です.
+ カーネルは, 外へ出ていく最初のパケットを作り, それを tun デバイスへ書き込みます.
+ そして この問題に対処する理論的な方法がいくつかあります. もし可能なら,
- 相手が同じIP numberを割り当てなおす事ができるのが最も良いです我々の側から対処できる最も簡単な方法は, tun interfaceのIP
- numberを固定する事ですが, かわりに外に出ていくpacketを変更して
- source IP numberをinterfaceのIPからnegotiateされたIPに書きかえる
- 事によっても対処できます. これが,
- (およびpppのもう1つの(最も確かな)方法は, 全てのbindされているsocketの
- IPを変更するようにsystem callを実装する事です. 3つ目の方法は, interfaceをIP number無しで立ち上げる事を許す
- ことです. 外に出ていくpacketは最初のSIOCAIFADDR ioctlが終わるまで
- は255.255.255.255というIP numberを与えられます. これによって
- socketを完全にbindすることができます. 現在のところ, これらの方法のどれもまだ実装されていません.
+ 相手が再度, 同じ IP アドレスを割り当ててくれることが一番です 我々の側から対処できる最も簡単な方法は, tun インターフェイスの
+ IP アドレスを固定する事です. またそのかわりに,
+ 外に出ていくパケットを変更して, 発信元 IP アドレスをインターフェイスの IP
+ アドレスから, 交渉によって得られた IP アドレスに,
+ 適宜書きかえる事によっても対処できます. こ
+ これは, 基本的に および, ppp の もう 1 つの(おそらく最も信頼できる)方法は, bind された
+ 全てのソケットの IP アドレスを,
+ 異なるものに変更できるシステムコールを実装することです.
+ 3 つ目の方法は, IP
+ アドレスを指定しないでインターフェイスを利用できるようにすることです.
+ 外に出ていくパケットは, 最初の SIOCAIFADDR ioctl の完了まで,
+ 255.255.255.255 という IP アドレス が与えられます.
+ これによって. ソケットは常に bind することができます.
+
何故ほとんどのゲームが -alias スイッチ付きだと動かないんですか?
訳注:この問題は佐藤 淳一さん作の NAT パッチを使っても解決できます.
をご覧ください.
libalias を使っている時にゲームなどの類のものが動作しない理由は,
外側にあるマシンが接続しようとしているか, 内側にあるマシンに (余計な)
UDP パケットを送信しようとしているからです.
内側のマシンにこれらのパケットを送るべきかについて,
packet alias ソフトウェアは関知しません.
うまく動かすためには, 実行中のものが問題の発生している
ソフトウェアだけであるかを確認し, ゲートウェイの tun インタフェースに対して
tcpdump を実行するか, ゲートウェイ上で ppp tcp/ip logging を有効化
(``set log +tcp/ip'') してください.
行儀の悪いソフトウェアを起動する際に, ゲートウェイマシンを
通過するパケットを監視すべきです. 外側から何かパケットが戻ってきた時に,
そのパケットは破棄されるでしょう (それが問題なのです).
これらのパケットの port 番号に注意して, その行儀の悪いソフトウェアを
停止してください.
これを数回繰り返して port 番号が常に同じであるかを確認してみてください.
同じであった場合は, /etc/ppp/ppp.conf の適切なセクションに次の行を入れると,
そのソフトウェアは動作するようになるでしょう.
alias port proto internalmachine:port port
ここで ``proto'' は ``tcp'' か ``udp'' であり,
``internalmachine'' はパケットを送りたいマシン, そして
``port'' はパケットのディストネーションの port 番号です.
上記のコマンドを変更せずに他のマシン上でそのソフトウェアを
使用できるようにはしたくないかもしれません. そして
同時に二つの内部のマシン上でそのソフトウェアを実行することは
この質問の範囲を超えています. 結局, 外側の世界からは
内部ネットワーク全体がただ一つのマシンとして見えるのです.
port 番号が常に同じとは限らない場合, さらに三つのオプションがあります.
1) libalias でサポートするようにし, 結果を送り付ける.
特定の場合の例は /usr/src/lib/libalias/alias_*.c にあります
(alias_ftp.c は良いプロトタイプです). これには通常, 外向きの特定のパケットを読み,
内部の計算機のある特定のポートへの接続を開始するような命令が
外部の計算機対して送られていることを見分け, 後続のパケットがどこに行けば
いいのかが分かるように, エイリアステーブル中の ``route'' の部分を設定する,
という作業が含まれます.
これは最も難しい方法ですが, 最も良い方法でもありますし, ソフトウェアが
複数の計算機で動くようにできます.
2) プロクシを使う. アプリケーションが, 例えば socks5
をサポートしているか, (cvsup のように) ``passive'' オプションを持っていると
この方法が使えます. ``passive'' とは相手側のほうから接続を求めてくることを
避けるためにあるオプションです.
3) ''alias addr''を使ってなんでもかんでも内部の計算機に向けて
流してしまう. これはちょっと無理矢理な解決法です.
FCS エラーって何?
FCS とは show hdlc
コマンドを使って表示できます.
リンクの品質が悪かったり, シリアルドライバがパケットを取り
こぼしていたりすると, FCS エラーがたびたび発生します. FCS エラー
は, 圧縮プロトコルの速度低下の原因にはなりますが, 特に心配する
必要はありません. 外付けモデムを使っている場合は, ケーブルが
ちゃんとシールドされているかを確認してください. そうでない場合,
FCS エラーの原因となる場合があります.
接続直後からリンクがフリーズし, 大量の FCS エラーが発生する
場合は, リンクが 8 ビットクリーンでない可能性があります. ソフト
ウェアフロー制御 (XON/XOFF) が使われていないことを確認してくだ
さい. どうしてもソフトウェアフロー制御を使わなければならない場
合は, set accmap 0x000a0000 コマンドを使用して, ppp
に ^Q と ^S をエスケープさせてください
リモートホストが ログファイルにリンクを終了した原因となるような記録がない場合は,
リモートホスト(プロバイダ?)の管理者に, セッションを終了された
理由を尋ねてください.
どれにも当てはまらない! どうしたらいいの?
これまでの全ての質問に当てはまらない場合, 設定ファイル, コマンドの出力 (接続前と接続後) を含む,
あなたの持っている全ての情報を
メーリングリストや
ニュースグループへ
送ってください. 誰かがあなたを正しい方向へ導いてくれるでしょう.
/dev/ed0 デバイスを作成することができません.
Berkeley UNIX におけるネットワークの構成においては, ネットワーク
のインタフェースは kernel のコードからのみ直接あつかうことが
できます. より詳しく知りたい場合は, /etc/rc.network
というファイルや, このファイルの中に書いてあるさまざまなプログラム
についてのマニュアルページを見てください. それでもまだ分からない場合には,
他の BSD 系の OS のネットワーク管理についての本を読むべきでしょう.
ごく少しの例外をのぞいては, FreeBSD のネットワーク管理は SunOS 4.0
や Ultrix と基本的に同じです.
Ethernet アドレスのエイリアスはどのようにして設定できますか?
のコマンドラインに ``
ifconfig ed0 alias 204.141.95.2 netmask 0xffffffff
3C503 で他のネットワークの port を使用するにはどのようにすればよいですか?
他の port を使用したい場合には, のコマンドラインにパラメータを
追加しなければなりません. default は ``.
の using the ifconfig_* の変数を使って指定されるはずです.
FreeBSD との間で NFS がうまくできません.
PC 用のネットワークカードによっては NFS のようなネットワークを
酷使するアプリケーションにおいて問題を起こすものがあります.
この点に関しては
を見てください.
何故 Linux のディスクを NFS マウントできないのでしょうか?
Linux の NFS のコードによっては許可されたportからの
リクエストからしか受けつけないものがあります.
以下を試してみてください.
mount -o -P linuxbox:/blah /mnt
何故 Sun のディスクを NFS マウントできないのでしょうか?
SunOS 4.X が走っている Sun Workstation は許可された port からの
mount のリクエストしか受けつけません.
以下を試してみてください.
mount -o -P sunbox:/blah /mnt
PPP で NeXTStep に接続する際に問題があるのですが.
の中で次の変数を NO にして,
TCP extension を無効にしてみてください.
tcp_extensions=NO
Xylogic の Annex も同様の問題がありますので, Annex 経由で PPP をおこなう
場合にもこの変更を行ってください.
IP multicast を有効にするには?
2.0 かそれ以降の FreeBSD は, 標準の状態で完全に multicast に対応しています.
現在使用している計算機を multicast の router として使用するには,
/etc/rc.conf でフラグ MBONE用のツールは ports 内の専用のカテゴリー mbone にあります.
詳しい情報は
にあります.
DEC の PCI チップセットを用いている network カードにはどのような物がありますか?
による一覧に, よりmodernな物を追加したものを
以下に示します.
Vendor Model
----------------------------------------------
ASUS PCI-L101-TB
Accton ENI1203
Cogent EM960PCI
Compex ENET32-PCI
D-Link DE-530
Dayna DP1203, DP2100
DEC DE435
Danpex EN-9400P3
JCIS Condor JC1260
Linksys EtherPCI
Mylex LNP101
SMC EtherPower 10/100 (Model 9332)
SMC EtherPower (Model 8432)
TopWare TE-3500P
Zynx ZX342
何故自分のサイトのホストに対して FQDN を使用する必要があるのですか?
実際にはそのホストは別のドメインにあるのではないですか. たとえば,
foo.bar.edu というドメインの中から, bar.edu ドメインにある
``mumble'' というホストを指定したい場合には, ``mumble'' だけでは
駄目で, ``mumble.bar.edu'' という fully-qualified domain name で
指定しなければなりません.
伝統的に, BSD の BIND の resolver ではこのような事は可能でしたが,
FreeBSD に入っている
の現在のバージョンでは, 自分以外のドメインに対して FQDN
でない別名を自動的につけてくれるような事はありません.
したがって mumble というホスト名は mumble.foo.bar.edu
という名前か, もしくは root ドメイン内にある場合にしか適用されません.
これは, mumble.bar.edu と mumble.edu
ということなったドメイン名に対してホスト名のサーチがおこなわれていた
以前の振る舞いとは異なったものです. このような事が悪い例もしくは
セキュリティホールとみなされる理由については RFC 1535 を見てください.
の中で
domain foo.bar.edu
と書いてある行を
search foo.bar.edu bar.edu
のように書きかえることで, 上のような事ができます. しかし,
RFC 1535 にあるように, search order が ``ローカルな管理と
パブリックな管理の境界'' をまたがないようにしてください.
すべてのネットワークの操作に対して ``Permission denied'' というメッセージが表示されるのですが.
- もしfirewallの設定を間違えた場合にネットワークの操作が再びできる
- ようにするには, root で login して次のコマンドを実行してください.
+
もしファイアウォールの設定を間違えた場合にネットワークの操作が再びできる
+ ようにするには, root でログインして次のコマンドを実行してください.
ipfw add 65534 allow all from any to any
-
/etc/rc.conf に"firewall_type='open'"を追加してもよい
+
/etc/rc.conf に "firewall_type='open'" を追加してもよい
でしょう.
-
FreeBSD の firewall の設定についての情報は
+
FreeBSD のファイアウォールの設定についての情報は
にあります.
- IPFWのオーバーヘッドはどのくらいでしょうか?
+ IPFW のオーバーヘッドはどのくらいでしょうか?
- この答えはあなたのrule setとprocessorのスピードによって
- ほとんど決まります. Ethernetに対して少しのrule setだけを使っ
+
この答えはあなたのルールセットとプロセッサのスピードによって
+ ほとんど決まります. イーサネットに対して少しのルールセットだけを使っ
ているほどんどの場合には, その影響は無視できる程度です. 実
際の測定値を見ないと満足できない方々のために, 実際の測定結
果をお見せしましょう.
-
次の測定は486-66上で2.2.5-STABLEを使用しておこなわれました.
- IPFWは変更が加えられて, 次の測定は 486-66(訳注: Intel 社製 CPU i486, 66MHz のこと)上で
+ 2.2.5-STABLE を使用しておこなわれました.
+ IPFW は変更が加えられて, それぞれ1000ずつのruleが入っている2つのrule setでテストが
- おこなわれました. ひとつ目のsetは最悪のケースを見るために
+
それぞれ 1000 ずつのルールが入っている 2 つのルールセットでテストが
+ おこなわれました. ひとつ目のルールセットは最悪のケースを見るために
ipfw add deny tcp from any to any 55555
- というruleを繰り返したものです.
+ というルールを繰り返したものです.
-
このsetを用いますと, (port番号によって) packetが全てのruleにマッチ
- しない事が最終的に決まるまでに, IPFWのpacketをチェックするルーチン
- のほとんど全てが実行されますので, 最悪のケースとなります. この
- ruleを999個繰り返した後にallow ip from any to any が
+
パケットが(ポート番号のせいで)このルールにマッチしないことがわかるまでに,
+ 何度も実行される IPFW のパケットチェックルーチンによって,
+ これは最悪のケースを示します.
+ このルールを 999 個繰り返し並べた後に allow ip from any to any が
書かれています.
-
2つ目のsetは, なるべく早くチェックが終了するように書かれたものです:
-
+
2つ目のルールセットは, なるべく早くチェックが終了するように書かれたものです:
+
ipfw add deny ip from 1.2.3.4 to 1.2.3.4
-
このruleではsource側のIPアドレスがマッチしないのでチェックは
- すぐに終了します. 上のsetとおなじように, 1000個目のruleは
+
このルールでは, 発信元の IP アドレスがマッチしないのでチェックは
+ すぐに終了します. 上のルールセットとおなじように, 1000 個目のruleは
allow ip from any to any です.
-
1つ目のsetでは, packetあたりのoverheadはだいたい2.703ms/packet,
- 言いかえると1つのruleあたり2.7マイクロ秒です. したがってこのruleに
- おけるpacketを処理する時間の理論的な限界は1秒あたり約370 packetです.
- 10MbpsのEthernetで1500 byte以下のpacketサイズを仮定すると, 55.5%の
- バンド幅までしか使えない事になります.
-
-
2つ目のsetでは, それぞれのpacketはだいたい1.172msで処理されて
- いますので1つのruleあたり1.2マイクロ秒となります. packetの
- 処理時間の理論的な限界はだいたい1秒あたり853 packetとなりますので
+
1 つ目のルールセットでは, パケットあたりのオーバヘッドはおよそ
+ 2.703ms/packet, これはだいたい 1 つのルールあたり 2.7 マイクロ秒
+ かかっていることになります.
+ したがって, このルールにおけるパケット処理時間の理論的な限界は,
+ 毎秒約 370 パケットです.
+ 10Mbps のイーサネットで 1500 バイト以下のパケットサイズを仮定すると,
+ バンド幅の利用効率は 55.5% が限界となることになります.
+
+
2 つ目のルールセットでは, それぞれのパケットがおよそ
+ 1.172msで処理されていますので, だいたい 1 つのルールあたり 1.2 マイクロ秒
+ かかっていることになります.
+ パケット処理時間の理論的な限界は, 毎秒約 853 パケットとなりますので,
10Mbps Ethernetのバンド幅を使い切ることができます.
-
このテストでのruleの数は多過ぎますので, 実際に使用している際の
+
このテストでのルール数は多過ぎるため, 実際に使用する際の
結果を反映している訳ではありません. これらは上に示した数値を出す
- ためだけに用いられたものです. 実際に効率の良いrule setを作るために
- は, 次のような事を考えておけばよいでしょう.
+ ためだけに用いられたものです. 効率の良いルールセットを作るためには,
+ 次のような事を考えておけばよいでしょう.
- - `確定している' ruleは, TCPのtrafficの多数を処理するために
- 前の方に持ってきてください. そしてこのruleの前には
allow tcp
- という記述をしないでください.
+ - `確定している' ルールは先頭の方に持ってきてください.
+ これは, 多数の TCP のトラフィックがこのルールで処理されるためです.
+ そしてこのルールの前には
allow tcp という記述を置かないでください.
- - 良く使われるruleを, あまり良く使われないruleよりも
- 前の方に(もちろん
firewallの許可の設定を変えない範囲で )
+ - 良く使われるルールを, あまり良く使われないルールよりも
+ 前の方に(もちろん
ファイアウォールの許可設定を変えない範囲で )
持ってきてください.
- ipfw -a l のようにしてpacket数の統計を取ることによって
- どのruleが最もよく使われているかが分かります.
+ ipfw -a l のようしてパケット数の統計を取ることで,
+ どのルールが最もよく使われているかを調べることができます.
サービス要求を他のマシンにリダイレクトするには?
FTP などのサービスのリクエストは, 'socket' パッケージを利用
してリダイレクトできます. 'socket' パッケージは ports の
'sysutils' カテゴリに含まれています. リダイレクトしたいサービ
- ス(/etc/inet.conf のコマンド行を socket を呼ぶように変
+ ス(/etc/inet.conf のコマンド行をソケットを呼ぶように変
更してください. 変更例:
ftp stream tcp nowait nobody /usr/local/bin/socket socket ftp.foo.com ftp
ここで 'ftp.foo.com' はリダイレクト先のホスト名, 行の最後の'ftp'
はポートです.
+
+ バンド幅の管理を行なえるツールはどこで手に入れられますか?
+
+ FreeBSD 用のバンド幅管理ツールには, 無料で手に入れられる
+ と,
+
+ から入手できる Bandwidth Manager という市販のものの 2 種類があります.
+
+
+ なぜ ``/dev/bpf0: device not configured" が出るのでしょうか?
+
+ バークレーパケットフィルタ
+ ドライバは, それを利用するプログラムを実行する前に有効にしておく必要があります.
+ カーネルコンフィグファイルに, 次のように追加してカーネルの再構築をして下さい.
+
+
+ pseudo-device bpfilter # Berkeley Packet Filter
+
+
+ そして再起動してから, 次にデバイスノードを作成する必要があります.
+ これは, 次のように入力し, /dev を変更することで行ないます.
+
+
+ # sh MAKEDEV bpf0
+
デバイスノードの作成の詳細は, を参照して下さい.
+
diff --git a/ja/FAQ/troubleshoot.sgml b/ja/FAQ/troubleshoot.sgml
index 2688b4f28b..ea152fd6e3 100644
--- a/ja/FAQ/troubleshoot.sgml
+++ b/ja/FAQ/troubleshoot.sgml
@@ -1,454 +1,545 @@
-
+
-
+
トラブルシューティング
訳: &a.yoshiaki;.10 November 1997.
ハードディスクに不良ブロックがあります!
SCSI ディスクの場合は自動的に再マップする機能があるはずです.
しかし, 理解し難い理由から多くのドライブがこの機能が無効化
されて出荷されています...
これを有効化するには, 最初のデバイスのモードページを変更する
必要があります. これは次のコマンドを実行することで, FreeBSD
上でおこなうことができます (root 権限でおこないます).
scsi -f /dev/rsd0c -m 1 -e -P 3
そして, AWRE と ARRE の値を 0 から 1 へ変更します:-
AWRE (Auto Write Reallocation Enbld): 1
ARRE (Auto Read Reallocation Enbld): 1
-
他の種類のディスクでは, オペレーティングシステムからサポート
- されているかによります. 残念ながら, この目的のために FreeBSD
- が提供する ``bad144'' コマンドはかなり手を入れる必要があります...
-
-
IDE ディスクは, おそらく不良ブロックの再マップを内蔵していると
- 思います; ディスクの説明書がある場合は, この機能が無効になって
- いるかを確認するとよいでしょう. しかし, ESDI, RLL, ST-506
- ディスクは, 通常これをおこないません.
-
-
再マップが可能になっていて不良ブロックを見つけたのであれば,
- ドライブを交換することを考えましょう. 不良ブロックの状態は時間と
- ともに悪い方向にしか行きません.
+
以下は,
+ から寄せられたものです.
+
+ IDE ドライブの場合は通常, 不良ブロックは潜在的な障害の兆候です.
+ 最近の IDE ドライブは, 内部の不良ブロック再マッピング機能を有効にした状態で
+ 出荷されています. また, 今日の IDE ハードディスクメーカは,
+ 出荷以降に不良ブロックが発生することに関して保証を提供していて,
+ 不良ブロックのあるディスクドライブを交換するサービスを行なっています.
+
+
もし, 不良ブロックのある IDE ディスクドライブを復旧しようと思うなら,
+ IDE ドライブメーカが提供する IDE 診断プログラムをダウンロードして,
+ そのドライブに使ってみてください. この種のプログラムは大抵,
+ ドライブの制御部分に対して不良ブロックを再走査し,
+ 不良ブロックを使用不能にするようにセットすることができます.
+
+
ESDI, RLL および MFM ドライブの場合, 不良ブロックはドライブの
+ 正常な部分であり, 一般的に言って障害を表すものではありません.
+ PC では, ディスクドライブコントローラカードと BIOS が不良ブロックの
+ 使用不能化の作業を行ないます. DOS など, ディスクアクセスに BIOS
+ を経由する OS にとっては有効に働きますが, FreeBSD
+ のディスクドライバは BIOS を利用しません. そのため,
+ 代替として bad144 という機構が存在します.
+ bad144 は, wd ドライバにだけ作用し, SCSI ドライバに利用することは
+ *できません*. bad144 は, 検出された不良セクタをスペシャルファイルに
+ 記録するという働きを持っています.
+
+
bad144 を利用する上で, 注意しなければならない点が一つあります.
+ それは, 不良ブロックスペシャルファイルは, ディスクの最終トラックに
+ 置かれるということです. このファイルには, ディスクの先頭の付近,
+ /kernel ファイルが位置しているであろう部分で発生した不良セクタが
+ 記録されています. したがって, このファイルは BIOS コールを使って
+ カーネルファイルを読み込む起動プログラムがアクセス可能でなければなりません.
+ これはつまり, bad144 を利用するディスクは, 1024 シリンダ,
+ 16 ヘッド, 63 セクタを超えてはならないということを意味し,
+ bad144 を利用したディスクが実質 500MB を超えられないことになります.
+
+
bad144 を使うには, FreeBSD のインストール時に表示される fdisk 画面で,
+ "Bad Block" 走査を ON に設定するだけです. これは, FreeBSD 2.2.7 以降で
+ 機能します. ディスクは, 1024 シリンダ以内でなければなりません.
+ ディスクドライブは事前に少なくとも 4 時間, ディスクが温度によって膨張し,
+ トラックに曲がりが出るまで回転させることをお薦めします(訳注: 温度変化に
+ 対する膨張によって, ディスクが微小変形することにより発生する不良セクタを
+ 確実に検出するためです).
+
+
大容量の ESDI ドライブのように, 1024 シリンダを超えるディスクの場合,
+ DOS 上でそのディスクが利用できるように, ESDI コントローラは特殊な変換モードを
+ 利用します. fdisk の "set geometry" コマンドを使って
+ "変換された(translated)" ジオメトリに切替えると, wd ドライバは
+ この変換モードを解釈できます.
+ その際, FreeBSD パーティションを作成するのに "dangerously dedicated" モードを
+ 利用してはいけません. このモードは, そのようなジオメトリを無視するからです.
+ たとえ fdisk がオーバーライドされたジオメトリ情報を使ったとしても,
+ 已然としてディスクの真の大きさを保持しているため, 大きすぎる FreeBSD
+ パーティションを作成しようとしてしまうでしょう.
+ ディスクジオメトリ情報が変換されたジオメトリ情報にかわっている場合は,
+ 手動でブロック数を入力し, パーティションを作成する必要があります.
+
+
大容量の ESDI ディスクを ESDI コントローラでセットアップするには,
+ ちょっとしたトリックを使います. まず, DOS のディスクで起動して
+ そのディスクを DOS パーティションとしてフォーマットします.
+ そして FreeBSD を起動し, インストーラの fdisk 画面で
+ DOS パーティションのブロックサイズとブロック数を読みとり, メモしておきます.
+ ジオメトリ情報を DOS が利用しているものと同一に再設定し,
+ DOS パーティションを削除して "cooperative" FreeBSD パーティションを
+ 先程記録したブロックサイズを使って作成して下さい.
+ そのパーティションを起動可能パーティションに設定し, 不良ブロック走査を
+ 有効にして下さい. 実際のインストールでは, ファイルシステムが作成される前に
+ bad144 が最初に実行されます(Alt-F2 を押すことで状況を確認できます).
+ 不良セクタファイルを作成中に何らかの障害が発生したなら,
+ システムを再起動して, もう一度最初からやり直しになります.
+ おそらくディスクジオメトリ情報の設定を大きくしすぎているのでしょう.
+ (やり直しは, DOS によるフォーマットとパーティション確保を含みます)
+
+
もし, 不良ブロックの再マッピングを有効にしていて不良ブロックが見付かったら,
+ ドライブの交換を考えて下さい. 不良ブロックは, 時間とともに悪化するからです.
Bustek 742a EISA SCSI が認識されません.
この情報は 742a のためのものですが, 他の Buslogic カードについても
同様のことが言えます. (Bustek = Buslogic)
742a カードには大きくわけて 2つのバージョンが存在します.
ハードウェアリビジョンの A-G と H 以降です. リビジョンの
文字はカードの隅にあるアセンブリ番号の後ろにあります.
742a は二つの ROM チップを持っており, 一つは BIOS チップで
もう一つはファームウェアチップです. FreeBSD はあなたの
持っているものがどの BIOS バージョンかは問題ありませんが,
ファームウェアバージョンについては問題となります.
Buslogic の技術サポート部門に連絡すれば, アップグレード版の
ROM を送ってくれることでしょう. BIOS チップと
ファームウェアチップはペアで出荷されます.
アダプタカードのハードウェアリビジョンにあわせた
最も新しいファームウェア ROM を使用しなければなりません.
リビジョン A-G のカードには, 2.41/2.21 までの
BIOS/ファームウェアのセットを使用することができます.
リビジョン H 以降のカードには, 最新のものである
4.70/3.37 の BIOS/ファームウェアのセットを
使用することができます. これらのファームウェアの違いは,
ファームウェア 3.37 が 「ラウンドロビン方式」
をサポートしているところからきています.
Buslogic のカードには, 製造番号も刻印されています. 古い
ハードウェアリビジョンのカードを持っている場合は, Buslogic の RMA
部門に問い合わせて製造番号を伝えると, 新しいハードウェアリビジョンの
カードに交換することもできます. もしカードが十分新しければ, 彼らは
交換に応じてくれるでしょう.
FreeBSD 2.1 は ファームウェアリビジョン 2.21
以降のものをサポートしています.
これよりも古いファームウェアリビジョンのものは,
Buslogic カードとして正常に認識されません.
しかし, Adaptec 1540 として認識されるかもしれません.
初期の Buslogic のファームウェアは AHA1540 互換モードを
持っています. しかし, EISA カードにとってこれは
よいことではありません.
古いハードウェアリビジョンのカードを持っていてファームウェア
2.21 を入手するのであれば, ジャンパ W1 の位置をデフォルトの
A-B から B-C に合わせる必要があるでしょう.
742a EISA カードには, [の節で説明している
「16 MB を越える」ことによる問題はありません.
これは Vesa-Local Buslogic SCSI カードで発生する問題です.
]
HP Netserver 上のオンボード SCSI コントローラが認識されません.
基本的にこれは既知の問題です. HP Netserver マシンの
EISA オンボード SCSI コントローラは EISA のスロット番号 11
を占有しますが, 「本当の」EISA スロットはすべてそれよりも
前のアドレスに配置されているのです. 残念ながら,
10 番以上の EISA スロットは PCI に割り当てられたアドレス空間
と衝突し, FreeBSD
の自動コンフィグレーションは, 現状ではうまくこの状況を
処理できていないのです.
ですから現時点での最良の方法は, カーネルオプションの
に記述されているようにしてカーネルをコンパイルし,
構築してください.
もちろん, これはこのようなマシンにインストールする際に
卵が先か鶏が先か」といった問題を生み出すことになります.
この問題を回避するために, ユーザコンフィグ
(UserConfig) の中には特別な仕組みが組み込まれています.
このとき ``visual'' インタフェースは使用せず,
コマンドラインインタフェースを使用してください. 単純に
eisa 12
quit
とプロンプト上から打ち込み,
後は普通にインストールをおこなってください.
とにかくカスタムカーネルのコンパイルとインストールをおこなうことを
おすすめしますが,
も現時点ではこの値の変更を認識するようになっています.
うまくいけば, 将来のバージョンではこの問題が解決していることでしょう.
をご覧ください.
この CMD640 IDE コントローラはどこかおかしいようです.
それは壊れているのです. 両方のチャンネルを同時に制御できないのです.
現在ではこのチップを使っているシステムでは自動的に検出して
うまく動かすためのしくみが使えるようになっています. くわしくは
マニュアルページのディスクドライバ (man 4 wd) を参照してください.
CMD640 IDE コントローラを使っているシステムで FreeBSD 2.2.1
あるいは 2.2.2 を使っている場合でセカンダリのチャネルを
使いたいのであれば
``
たぶん IRQ の衝突が原因でしょう (二つのボードが同じ IRQ
を使用しているなど). FreeBSD 2.0.5R 以前では, これに関しては
寛大で IRQ の衝突があってもネットワークドライバは機能して
いました. しかし 2.0.5R 以降は IRQ の衝突はもはや寛大では
ありません. -c オプションをつけてブートして ed0/de0/... の
エントリをボードの設定に合わせてください.
ネットワークカードの BNC コネクタ (訳注: 10BASE-2 タイプ
のインターフェース) を使っている場合, デバイスのタイムアウト
はターミネーションの不良によっても起きます.
これをチェックするにはケーブルを外してターミネータを直接 NIC
に接続します. そしてエラーメッセージが消えるかどうか
確認します.
NE2000 コンパチブルカードのなかには UTP ポートのリンクが
なかったりケーブルが接続されていない場合にこのエラーを出す
ものがあります.
CDROM をマウントしようとすると ``Incorrect super block'' と言われます.
にマウントしたいデバイスのタイプを指定する必要
があります. デフォルトでは
はファイルシステムを
`` オプションをつけて明示する必要があります.
これはもちろん
CDROM が ISO 9660 ファイルシステムである場合です. ほとんどの
CDROM はこの形式です. 1.1R の FreeBSD では (訳注: 現行の 2.1.5R,
2.2R でも同様です) 自動的に Rock Ridge 拡張
(長いファイル名への対応) をうまく解釈します.
CDROM のデバイス ``/dev/cd0c '' を
/mnt にマウントしたい場合の例では, 次のようにします:
mount -t cd9660 /dev/cd0c /mnt
デバイスの名前はインタフェースによっては別の名前になっている
かもしれないので注意してください (``/dev/cd0c '' は
この場合の例です).
オプション ``
mount_cd9660 /dev/cd0c /mnt
CDROM をマウントしようとすると ``Device not configured'' と言われます.
これは 一般的に CDROM ドライブの中に CDROM が入っていないか,
ドライブがバス上に見えないことを意味します. ドライブに CDROM
を入れるか, IDE (ATAPI) であれば master/slave の状態をチェック
してください. CDROM ドライブに CDROM を入れてから認識するまで
数秒かかりますので少し待ってみてください.
SCSI CDROM ではバスリセットへの応答時間が遅いために失敗する
ことがあるかもしれません. SCSI CDROM を持っている場合は
カーネルコンフィグレーションファイルに以下の行を加えて
再コンパイルして試してみてください.
options "SCSI_DELAY=15"
(訳注: 現在の GENERIC カーネルでは上の設定はデフォルトに
なっています. 問題のある場合は SCSI_DELAY の数値を増やして
みてください.)
私のプリンタはとてつもなく遅いのです. どうしたらよいのでしょう?
パラレルインタフェースで, 問題はとんでもなく遅いだけであるなら,
プリンタボートを ``polled'' モードに設定してみてください:
lptcontrol -p
HP の新しいプリンタのいくつかは割り込みモードでは
使えないようです. (完全にわかったわけではありませんが)
タイミングの問題のように思われます.
私のプログラムは時々 ``Signal 11'' のエラーで止まってしまいます.
これはハードウェア (メモリ, マザーボードなど) の不具合いが
原因です. PC でメモリテストプログラムを動かしてみてください.
ただしメモリが正常に動作していると報告されたとしても, ぎりぎりで
メモリテストにパスしたメモリは, 処理の内容 (例えば
kernel のコンパイルや特にシステムの負荷が高いような場合には,
Adaptec 1542 などの SCSI コントローラのバスマスタ DMA など)
によっては問題が起きる可能性は大いにあります.
SIG11 FAQ (後で URLを示します) では遅いメモリが一般的に問題
を起こしがちであることを指摘しています. BIOS セットアップで
ウエイトステート数を増やすかメモリを速いものに交換してください.
私の場合はキャッシュ RAM やオンボードキャッシュコントローラ
の問題でした. このような問題ではないか確認するために BIOS
セットアップでオンボード (セカンダリ) キャッシュを無効にして
みてください.
以下のところには広い範囲の FAQ があります.
ブートの時に画面が真っ暗になって同期も取れません.
これは ATI Mach 64 ビデオカードの既知の問題です.
この問題はカードがアドレス
ドライバのバグ
(仕様?) のため4番目のシリアルポートがなくても, 通常この
アドレスを使う sio3 (4 番目のポートにあたります) を無効にしても,
ドライバはこのアドレスをさわります.
バグが修正されるまでは, 次のようにして対処してください.
- ブートプロンプトが出たら
問題はありません.
- exit とタイプしてブートを続行します.
もしシリアルポートを有効にしたいのであれば以下の変更をおこなって
新しいカーネルを作る必要があります.
/usr/src/sys/i386/isa/sio.c の中で1ヵ所ある
この対処をおこなった後でもまだ X ウィンドウシステムはうまく
動かないかもしれません. いくつかの新しい ATI Mach 64 ビデオカード
(特に ATI Mach Xpression) は現在のバージョンの
を見てベータリリースへのリンクを追ってください.
以下のファイルを持ってきましょう.
AccelCards, BetaReport, Cards, Devices, FILES, README.ati,
README.FreeBSD, README.Mach64, RELNOTES, VGADriver.Doc,
X312BMa64.tgz
古いファイルをこの新しいバージョンのファイルに置き換え,
をもう一度実行します.
128MB の RAM があるのですが, 64MB しか認識しません.
FreeBSD がメモリのサイズを BIOS から取得する方法の制限により,
KB 単位で 16 ビット分までしか検出できません
(すなわち最大 65535Kb=64MB です)(これより少ない場合もあります. ある BIOS
の場合はメモリサイズが 16MB に制限されます).
64MB 以上のメモリを積んでいる場合, FreeBSD はそれを検出しようとし
ます. しかしその試みは失敗するかもしれません.
この問題を回避するには, 以下に示すカーネルオプションを
使用する必要があります. 完全なメモリ情報を BIOS から取得する
方法もありますが, ブートブロックに空きが無いため実装できません.
ブートブロックの問題が解決されれば, いつか拡張 BIOS
機能を使用して完全なメモリ情報を取得できるようになるでしょう.
とりあえず現在は, カーネルオプションを使ってください.
options "MAXMEM=<n>"
FreeBSD 2.0 が ``kmem_map too small!'' と言ってパニックします.
このパニックは, ネットワークバッファ (特に mbuf クラスタ)
の仮想メモリが無くなったことを示します. 以下のオプションを
カーネルコンフィグファイルに追加して mbuf クラスタに使用できる
仮想メモリの量を増やしてください.
options "NMBCLUSTERS=<n>"
<n> には, 同時に使用したい TCP コネクションの数に応じて
512 から 4096 までの数値を指定できます. とりあえず 2048 を
試してみるのを勧めます. これでパニックは完全の予防できるはずです.
mbuf クラスタの割り当て／使用状況については,
で知ることができます.
name="netstat -m"> で知ることができます. NMBCLUSTERS の
デフォルト値は
新しいカーネルでリブートすると ``CMAP busy panic'' となってパニックを起こしてしまいます.
ファイル /var/db/kvm_*.db において範囲外のデータを
検出するためのロジックは失敗することがあり, こうした矛盾のある
ファイルを使用することでパニックを引き起こすことがあります.
これが起こったなら, シングルユーザでリブートした後に,
以下のコマンドを実行してください.
rm /var/db/kvm_*.db
ahc0: brkadrint, Illegal Host Access at seqaddr 0x0 というエラーが出ます
これは Ultrastor SCSI Host Adapter と衝突しています.
ブート時に kernel configuration メニューに入り, 問題を起こしている
を disable にしましょう.
sendmailが ``mail loops back to myself'' というメッセージを出すのですが.
この事は, sendmail FAQ に次のように書いてあります.
* "Local configuration error" というメッセージが出ます. 例えば:
553 relay.domain.net config error: mail loops back to myself
554 ... Local configuration error
のような物ですが, どのようにしたらこの問題を解決できますか?
これは, 例えば domain.net のようなドメイン宛てのメールを
MX record で特定のホスト (ここでは relay.domain.net) に送ろう
としたのに, そのホストでは domain.net 宛てのメールを受け取れる
ような設定になっていない場合です. 設定の際に
FEATURE(use_cw_file) を指定してある場合には/etc/sendmail.cw
の中に domain.net を追加してください. もしくは, /etc/sendmail.cf
の中に "Cw domain.net" を追加してください.
もはや現在の は sendmail release とは一緒には保守されて
いません. しかし次のネットニュースに定期的に投稿されてます.
,
,
,
,
.
また, メール経由でコピーを入手する場合は
宛まで本文に "send
usenet/news.answers/mail/sendmail-faq" と書いて送ります.
リモートマシン上のフルスクリーンアプリケーションがうまく動かない
リモートマシンのターミナルタイプが FreeBSD のコンソールで
つかわれている cons25 以外のものです.
この問題を解決する方法はいろいろあります:
- リモートマシンに login した後, shell 変数の TERM に
ansi か sco のいずれかを設定します.
- ローカル側で
のような VT100 エミュレータを使用します.
screen は一つのターミナルの中で複数のセッションを
並列動作させることができますし, 本来の機能も優れています.
- リモートマシンのターミナルデータベースに
cons25
のエントリをインストールします.
- Xを起動してリモートマシンに
xterm から login
します. (訳注: 日本語が必要な場合は kterm 等を
利用します)
+
+
+ 私のマシンで "calcru: negative time..." と表示されるのですが
+
+ これは, 割り込みに関連するさまざまな不具合によって発生します.
+ あるいは, あるデバイスが元々持っているバグが表面化したのかも知れません.
+ この症状を再現させる一つの方法として, パラレルポート上で,
+ TCP/IP を 大きな MTU で走らせるというものがあります.
+ グラフィックアクセラレータがこの症状を起こすことがありますが,
+ その場合はまず, カードの割り込み設定を確認して下さい.
+
+
この問題の副作用として, プロセスが "SIGXCPU exceeded cpu time limit"
+ というメッセージとともに終了してしまう, というものがあります.
+
+
1998 年 11 月 29 日に公開された FreeBSD 3.0 以降で
+ この問題が解決しないなら, 次の sysctl 変数をセットしてください.
+
+
+ sysctl -w kern.timecounter.method=1
+
+
+
これは, パフォーマンスへ強い影響を与えますが, 問題の発生に比べれば
+ おそらく気にならない程度でしょう. もし, これでもまだ問題が残るようなら,
+ カーネルオプションの "NTIMECOUNTER" を大きな値に増やして下さい.
+ "NTIMECOUNTER=20" にまで増やしても解決しない場合は,
+ 計時処理の信頼性が保てない程の割り込みが, そのマシン上で起こっていることを
+ 意味します.
+
diff --git a/ja_JP.eucJP/FAQ/commercial.sgml b/ja_JP.eucJP/FAQ/commercial.sgml
index aaf0da01a2..c1da99e97e 100644
--- a/ja_JP.eucJP/FAQ/commercial.sgml
+++ b/ja_JP.eucJP/FAQ/commercial.sgml
@@ -1,103 +1,184 @@
-
+
-
+
商用アプリケーション
訳: &a.junkun;.10 November 1997.
をご覧ください.
FreeBSD 用の Motif はどうやったら手に入りますか
- FreeBSD 用の Motif 2.0 に関する情報は
+
FreeBSD 用の ELF 版 Motif 2.1 に関する情報は
+ [ から
+ 手に入れることができます.]
+
+ この製品は以下の物が含まれています:
+
+ - OSF/Motif manager, xmbind, panner, wsm.
+
+
- uil, mrm, xm, xmcxx, インクルードファイルや Imake
+ ファイルといった開発者向けキット
+
+
- FreeBSD 3.0 以降で利用できる ELF 版スタティックライブラリ,
+ およびダイナミックライブラリ
+
+
- デモンストレーションプログラム
+
+
+
+
注文する際には FreeBSD 用の Motif であることをきちんと
+ 確認してください. NetBSD や OpenBSD 用の Motif もまた, Apps2go
+ から販売されています. 現在, FTP によるダウンロードのみ利用可能です.
+
+
+
+
+ または
+ 電子メールアドレス.
+
+
+
+ 他の FreeBSD 用 Motif 2.1(ELF 版, a.out 版) に関する情報は
+ [ から手に入れることができます.
+
+ ]この製品は以下の物が含まれています:
+
+ - OSF/Motif manager, xmbind, panner, wsm.
+
+
- uil, mrm, xm, xmcxx, インクルードファイルや Imake
+ ファイルといった開発者向けキット
+
+
- スタティックライブラリ, およびダイナミックライブラリ.
+ (FreeBSD 3.0 以降で利用できる ELF 版か,
+ FreeBSD 2.2.8 以前で利用できる a.out 版を指定して下さい)
+
+
- デモンストレーションプログラム
+
+
- 整形済みのマニュアルページ
+
+
+
注文する際には FreeBSD 用の Motif であることをきちんと
+ 確認してください. Linux 用の Motif も Metri Link
+ から販売されています. 現在, CDROM および FTP
+ によるダウンロードが利用可能です.
+
+
FreeBSD 用の a.out 版 Motif 2.0 に関する情報は
[ から
手に入れることができます.
]この製品は以下の物が含まれています:
- OSF/Motif manager, xmbind, panner, wsm.
- uil, mrm, xm, xmcxx, インクルードファイルや Imake
ファイルといった開発者向けキット
-
- スタティックライブラリ, およびダイナミックライブラリ
+
- FreeBSD 2.2.8 以前のバージョンで利用できるスタティックライブラリ,
+ およびダイナミックライブラリ
- デモンストレーションプログラム
- 整形済みのマニュアルページ
注文する際には FreeBSD 用の Motif であることをきちんと
- 確認してください. BSDI や Linux 用の Motif も Xi Graphics
+ 確認してください. BSDI や Linux 用の Motif もまた, Xi Graphics
から販売されています. 現在フロッピーディスク 4枚組ですが,
将来的には CDE のように統合された CD に変わるでしょう.
FreeBSD 用の CDE はどうやったら手に入りますか
FreeBSD 用の CDE 1.0.10 に関する情報は
[ から
手に入れることができます. これは Motif 1.2.5 を含んでおり,
- Motif 2.0 と一緒に使用することができます.
+ a.out 版 Motif 2.0 と一緒に使用することができます.
- ]これは FreeBSD 用と Linux 用の統合された CD-ROM です.
+
これは FreeBSD と Linux の両方に対応した CD-ROM で配布されているものです.
- 高機能な商用 X サーバってあるんですか?
+ 高機能な商用 X サーバってあるんですか?
- はい,
+ はい, と
+
から, FreeBSD ほか Intel ベースのシステムで動作する
Accelerated-X という製品が販売されています.
+
+
+ Metro Link は, FreeBSD のパッケージ操作ツールを利用することで
+ 容易に設定が行なえるほか, 数多くのビデオボードをサポートした
+ 高機能な X サーバを提供しています. 配布はバイナリ形式のみで,
+ FTP が利用可能です. もちろん, とても安価($39)に手に入れることができます.
+
+
+ また, Metro Link は ELF 版, a.out 版の FreeBSD 用 Motif
+ も販売しています(前を参照).
+
+
+
+
+
+ または
+ 電子メールアドレス
+
+
- この高性能な X サーバは楽に設定をおこなえるほか, 数多くのビデオボード
+
Xi Graphics が提供している高性能な X サーバは楽に設定をおこなえるほか,
+ 数多くのビデオボード
をサポートしています. サーバはバイナリのみが含まれます.
FreeBSD 用と Linux 用の統合されたフロッピーディスクに入っています.
+ Xi Graphics は Laptop サポートに特化した高性能 X サーバも提供しています.
-
バージョン 3.1 の「互換デモ」が無料で入手できます.
+
バージョン 5.0 の「互換デモ」が無料で入手できます.
また Xi Graphics は FreeBSD 用の Motif と CDE も販売しています (前を参照).
または
FreeBSD 用のデータベースシステムはありますか?
もちろんあります! Conetic Software Systems が FreeBSD 2.0.5
以降のシステムで動作する C/base と C/books データベースシステムを
移植しています. さらに Sleepycat Software は DB database library
の商用サポートバージョンを販売しています.
.
diff --git a/ja_JP.eucJP/FAQ/hackers.sgml b/ja_JP.eucJP/FAQ/hackers.sgml
index d1ab62f0ab..a68e93ce20 100644
--- a/ja_JP.eucJP/FAQ/hackers.sgml
+++ b/ja_JP.eucJP/FAQ/hackers.sgml
@@ -1,505 +1,584 @@
-
+
-
+
まじめな FreeBSD ハッカーだけの話題
訳: &a.iwasaki;.8 November 1997.
SNAP とか RELEASE とかは何?
現在, FreeBSD の
には, 三つのアクティブ/準アクティブなブランチがあります.
現在,
自分用のカスタムリリースを構築するには?
リリースを構築するには三つのことが必要です:
まず, ドライバが組み込まれたカーネルを実行させている必要があります.
以下をカーネルコンフィグレーションファイルに追加し,
カーネルを作り直してください:
pseudo-device vn #Vnode driver (turns a file into a device)
次に, CVS リポジトリ全体を手元においておく必要があります.
これを入手するには
-
+
が使用できますが, supfile で release の名称を cvs にして
他のタグや date フィールドを削除する必要があります:
*default prefix=/home/ncvs
*default base=/a
*default host=cvsup.FreeBSD.org
*default release=cvs
*default delete compress use-rel-suffix
## Main Source Tree
src-all
src-eBones
src-secure
# Other stuff
ports-all
www
doc-all
そして 最後に, ビルド用にかなりの空き領域を用意する必要があります.
そのディレクトリを /some/big/filesystem として,
上の例で CVS リポジトリを /home/ncvs に置いたものとすると,
以下のようにしてリリースを構築します:
setenv CVSROOT /home/ncvs # or export CVSROOT=/home/ncvs
cd /usr/src/release
make release BUILDNAME=3.0-MY-SNAP CHROOTDIR=/some/big/filesystem/release
処理が終了すると, リリース全体が /some/big/filesystem/release
に構築され, 完全な FTP インストール用の配布物が
/some/big/filesystem/release/R/ftp に作成されます.
-current 以外の開発ブランチの SNAP を自分で構築したい場合は,
カスタムのインストールディスクを作るにはどうすればいいのですか?
/usr/src/release/Makefile のいろいろなターゲットとして
インストールディスク, ソース, バイナリアーカイブを作る完全な処理を
自動的におこなうようになっています. Makefile に十分な情報があります.
しかし, 実行には ``make world'' が必要で,
多くの時間とディスクの容量が必要です.
``make world'' をおこなうと既存のバイナリを上書きしてしまうのですが.
ええ, それが一般的な考え方です. 名前が示しているように
``make world'' はすべてのシステムのバイナリを一から作り直しますので,
結果としてクリーンで一貫性のある環境を得ることができます
(これがそれだけ長い時間がかかる理由です).
環境変数 ${DESTDIR} を root とみなした
ディレクトリツリーにインストールされます.
あるでたらめな共有ライブラリの変更やプログラムの再構築によって
``
システムブート時に ``(bus speed defaulted)'' とメッセージが出ます.
アダプテックの 1542 SCSI ホストアダプタはユーザがソフトウェア的に
バスアクセス速度の設定をおこなうことができます. 以前のバージョンの
1542 ドライバは使用可能な最大の速度を求めてアダプタを
その設定にしようとしました. これは特定のユーザのシステムでは
問題がある事がわかり, 現在ではカーネルコンフィグオプションに
``
- インターネットアクセスに制限があっても current を追いかけられますか?
+ インターネットアクセスに制限があっても current を追いかけられますか?
+
-
はい, を使って
+ はい, を
+ 使って
ソースツリー全体のダウンロードを
どのようにして配布ファイルを 240kバイトに分割しているのですか?
比較的新しい BSDベースのシステムでは split に任意のバイト境界で
分割する ``以下は /usr/src/Makefile からの例です.
bin-tarball:
(cd ${DISTDIR}; \
tar cf - . \
gzip --no-name -9 -c | \
split -b 240640 - \
${RELEASEDIR}/tarballs/bindist/bin_tgz.)
私はカーネルに拡張をおこないました. 誰に送ればいいですか?
を参照してください.
あなたのアイディアに感謝します!
PnP ISA カードの検出と初期化はどのようにおこなうのですか?
氏より:
要点は, ホストが認識されていないボードを探す時に, すべての
PnP ボードが応答することのできる少数の I/O ポートがあるという
ことです. それにより, PnP プローブルーチンが開始したとき, PnP
ボードが存在するなら, すべての PnP ボードは自分のモデル番号を
返します. そのポートを I/O read するとプローブルーチンは
問いに対するワイアード-OR された ``yes'' を得ます. この場合は
少なくとも 1ビットが ON になります. そして, プローブルーチンは
モデル ID (Microsoft/Intel によって割り当てられています)
が X より小さいボードを ``オフライン'' にすることができます.
この操作をおこない, 問い合わせに応答しているボードがまだ
残っているかどうかを調べます. もし ``ID は二つの 32-bit (つまり 64bit) フィールド + 8 bit
チェックサムからなります. 最初の 32 bits はベンダの識別子です.
これは公表されてはいませんが, 同一のベンダから供給されている
異なるタイプのボードでは異なる 32-bit ベンダ ID を持つことが
できるように考えられます. 製造元を特定するだけのために 32 bits
はいくらか過剰です.
下位の 32 bits はシリアル番号, イーサネットアドレスなどの
ボードを特定するものです. ベンダは上位 32 bits が異なっていない
のであれば下位 32 bits が同一である 2枚目のボードを製造することは
ありません. したがって, 同じタイプの複数のボードをマシンに
いれることができ, この場合でも 64 bits 全体ではユニークです.
32 bit のフィールドはすべてを 0 にすることはできません.
これは初期化のバイナリサーチの間ワイアード-OR によって 0 ではない
ビットを参照するからです.
システムがすべてのボードの与えられた ID を認識すると,
それぞれのボードに対応した処理を一つずつ (同一の I/O ポートを通して)
おこないます. そして, 利用できる割り込みの選択などのボードが必要
とするリソースを検出します. すべてのボードについてこの情報を集めます.
この情報はハードディスク上の ECU ファイルなどの情報とまとめられ,
マザーボードの BIOS にも結合されます. マザーボード上のハードウェア
への ECU と BIOS PnP のサポートは通常は統合されていますが,
周辺機器については真の PnPであるとはいえません.
しかし, BIOS の情報に ECU の情報を加えて調査することで,
プローブルーチンは PnP デバイスが再配置できなくなることを
避けることができます.
それから, 再度 PnP デバイスにアクセスし, I/O, DMA, IRQ,
メモリマップアドレスの設定をします. デバイスはこのアドレスに
見えるようになり, 次にリブートするまでこの位置を占めます. しかし,
あなたの望む時に移動させることが不可能であるといっている
わけではありません.
以上の話では大きく単純化をしてありますが, 基本的な考え方は得
られたでしょう.
マイクロソフトはボードのロジックが 対立するI/O サイクルでは
デコードしていない (訳注: おそらく read 時しかデコードされていず
write 時はポートが空いているという意味でしょう)
プライマリプリンタのステータスポートのいくつかを PnP のために
占有しました. 私は初期の PnP の提案レビュー時に IBM 純正の
プリンタボードでステータスポートの write のデコードがされている
ということに気がつきましたが, MS は ``tough (頑固, 不運,
無法な)'' と言っています. そしてプリンタのステータスポートへ
アドレスの設定のために write をおこなっています. また,
そのアドレス +
FreeBSD は, 他のアーキテクチャをサポートしないんですか?
いくつかのグループの人々が, FreeBSD の他のアーキテクチャへの
移植に関心を示しており, FreeBSD/AXP (ALPHA) はこれらの成果としては
とても成功したものの一つです. FreeBSD/AXP は 3.0 スナップショット
リリースが現在 から入手できます.
ALPHA への移植版が現在動く機種は増えつつあり, その中には AlphaStation,
AXPpci, PC164, Miata そして Multia といったモデルが含まれています.
この ALPHA への移植版はまだ完全なリリースとはみなされていません.
システムインストールツール一式や CDROM のインストールメディアの
配布が提供され, 適度な数の ports や packages が動くようになって
からになるでしょう.
現在のところ FreeBSD/AXP はベータクオリティのソフトウェアと
みなすべきです. 現状についての情報を得るには
<freebsd-alpha@FreeBSD.ORG> [ に参加してください.
その他に FreeBSD の SPARC アーキテクチャへの移植があります.
プロジェクトへの参加に興味がある方は
]<freebsd-sparc@FreeBSD.ORG> [ に参加してください.
新しいアーキテクチャに関する一般的な議論については
]<freebsd-platforms@FreeBSD.ORG> [ へ参加してください.
]
デバイスドライバを開発したので, メジャー番号が必要です.
これは, 開発したドライバを公開するかどうかに依存します.
公開するのであれば, ドライバのソースコード, files.i386 の変更,
コンフィグファイルのサンプル, デバイスが使うスペシャルファイルを作成する
のコードを私たちに送ってください. 公開するつもりがない場合, ライセンスの
問題により公開できない場合は, キャラクタメジャー番号 32 もしくは
ブロックメジャー番号 8 が, このような目的のために予約されています.
これらの番号を使用してください. どちらの場合であれ, ドライバに関する情報を
<freebsd-hackers@FreeBSD.ORG> に流して頂けると助かります.
代替のディレクトリ配置ポリシー
現在使われているディレクトリの配置ポリシーは, 私が 1983 年に書い
たものから全く変更されていません. 私は当初の配置ポリシーを, オリ
ジナルの fast filesystem のために書き, まったく改定していません.
このポリシーはシリンダグループを使い尽くすのを防ぐにはうまくいき
ましたが,お気づきの方もいる通り find の動作には不適切です. ほと
んどのファイルシステムの内容は, 深さ優先検索 (ftw とも呼ばれます)
によって作られたアーカイブからレストアして作成されます. この際,
ディレクトリは,シリンダグループにまたがって配置され, 以降の深さ
優先検索を行うには考え得る限り最悪の状態になります. もし作成する
ディレクトリの総数がわかっていれば, 解決方法はあります. (総数 /
シリンダグループ数)個のディレクトリをシリンダグループごとにまと
めて作成すれば良いのです. もちろん最適なディレクトリ配置になるよ
うに, 総数を予測する方法を考えなければなりません. しかし仮にシリ
ンダグループあたりのディレクトリ数を 10 くらいの小さな数に固定し
てしまったとしても, 大幅な改善が望めるでしょう. このポリシーを用
いるべきリストア作業を, 通常の作業(おそらく既存のポリシーを使用
したほうが良いでしょう)を区別するには, 10 秒間の間に作成されたディ
レクトリを最大 10 個までまとめて単一のシリンダグループに書き込む
という手順が使えるでしょう. とにかく私の結論は, そろそろ実験
を始めて見る時期だろうということです.
カーネルパニックを最大限に利用する
[この節は, freebsd-current [ に ]
が投稿したメールを, が校正し,括弧内のコ
メントを追加して引用したものです. ]
From: Bill Paul
Subject: Re: the fs fun never stops
To: ben@rosengart.com
Date: Sun, 20 Sep 1998 15:22:50 -0400 (EDT)
Cc: current@FreeBSD.ORG
[<ben@rosengart.com> が以下のパニックメッセージを
投稿しました.]
> Fatal trap 12: page fault while in kernel mode
> fault virtual address = 0x40
> fault code = supervisor read, page not present
> instruction pointer = 0x8:0xf014a7e5
^^^^^^^^^^
> stack pointer = 0x10:0xf4ed6f24
> frame pointer = 0x10:0xf4ed6f28
> code segment = base 0x0, limit 0xfffff, type 0x1b
> = DPL 0, pres 1, def32 1, gran 1
> processor eflags = interrupt enabled, resume, IOPL = 0
> current process = 80 (mount)
> interrupt mask =
> trap number = 12
> panic: page fault
このようなメッセージが表示された場合, 問題が起きる状況を確認し
て, 情報を送るだけでは十分ではありません. 下線をつけた命令ポインタ
値は重要な値ですが, 残念ながらこの値は構成に依存します. つまり, こ
の値は使っているカーネルのイメージに依存するのです. もしスナップショッ
トなどの GENERIC カーネルを使っているのであれば, 他の人間が問題の
ある関数について追試をすることができますが, カスタマイズされたカー
ネルの場合は, 使っている本人にしか問題の起こった場所は特定できない
のです.
何をすれば良いのでしょう？
- 命令ポインタ値をメモします.
システムがリブートしたら, 以下の操作を行います:
% nm /kernel.that.caused.the.panic | grep f0xxxxxx
ここで,
% nm /kernel.that.caused.the.panic | grep f0xxxxx
これでも一致しない場合は, 桁を減らしながら何らかの出力があるま
で繰り返してください. 何か出力されたら, それがカーネルパニック
を引き起こした可能性のある関数のリストです. これは, 問題点を見付ける
正確な方法ではありませんが, 何もないよりましです.
このようなパニックメッセージを投稿している人はよく見掛けますが,
このように, 命令ポインタ値を, カーネルシンボルテーブルの中の関数
とつき合わせて調べている人はまれです.
パニックの原因を突き止める最良の方法は, クラッシュダンプをとり,
どっちにしろ, 私は普通以下のようにします.
- カーネルコンフィグファイルを作ります. カーネルデバッガが
必要そうであれば options 'DDB' を加えても良いです(私は永久ルー
プが起こっていそうな場合に, ブレークポイントを設定するのに使って
います).
-
cd /sys/compile/KERNELCONFIG; make
- カーネルのコンパイルが終了するのを待ちます.
cp kernel /
- reboot
[注: 現在 FreeBSD 3.x kernel はデフォルトで ELF 形式となっており,
全てのデバッグシンボルを含んだカーネルを, 実際にブートする必要は
ありません. 確実にクラッシュダンプをとるには, /etc/rc.conf を編
集して /etc/rc.conf で設定されていれ ば, /var/crash に保存します.
注: FreeBSD のクラッシュダンプのサイズは, ふつう物理メモリサ
イズと同じです. つまり 64MB のメモリを積んでいれば, 64MB のクラッ
シュ ダンプが生成されることになります. /var/crash に十
分な空き 容量があることを確認してください. 手動で
クラッシュダンプを取り出せたら, 以下のように
% gdb -k /sys/compile/KERNELCONFIG/kernel.debug /var/crash/vmcore.0
(gdb) where
必要な情報が 1 画面に収まらないことも多いので, できれば
もしあなたがデバッグ狂で, 同時に別のコンピュータを利用できる
環境にあれば, [Bill による注: DDB を有効にしていてカーネルがデバッガに
落ちたら, ddb のプロンプトで 'panic' と入力すれば, 強制的にパニッ
クを 起こしクラッシュダンプさせることができます. パニックの途中
で, 再び デバッガに落ちるかもしれませんが, 'continue' と入力すれ
ば, クラッシュダンプを最後まで実行させられます.]
dlsym() が ELF 実行形式では動作しなくなります!
ELF のツール類は, デフォルトでは実行形式の中に定義されている
シンボルをダイナミックリンカから見えるようにはしません.
このため, dlopen(NULL, flags) を呼び出して得られた
ハンドルに対して dlsym() で探索を行っても, こういった
シンボルを見つけられません.
もし, あなたがプロセスの中心にあたる実行形式の中にある
シンボルを探索したければ,
に -export-dynamic オプションを
付けて実行形式をリンクする必要があります.
+
+
+
+ カーネルアドレス空間を大きくしたり、小さくするにはどうしたら良いのですか?
+
+
+ カーネルアドレス空間は, FreeBSD 3.x 上で
+ 256MB, FreeBSD 4.x 上で 1GB がデフォルトになっています.
+ 負荷の高いネットワークサーバ(例えば大きな FTP, HTTP サーバ)を運用する場合は,
+ 256MB では足りないことに気付くかも知れません.
+
+
+ では, アドレス空間を大きくするにはどうしたら良いのでしょうか?
+ それには, 二つの段階を踏みます. まず,
+ より大きいアドレス空間を割り当てることをカーネルに知らせる必要があります.
+ 次に, カーネルはアドレス空間の先頭にロードされるため,
+ アドレスの先頭が天井(訳注:カーネルアドレス空間の最下端アドレスのこと)と
+ ぶつかることのないように, ロードアドレスを今までより低位に設定する必要があります.
+
+
+ 最初の段階は, src/sys/i386/include/pmap.h にある
+
+#ifndef NKPDE
+#ifdef SMP
+#define NKPDE 254 /* addressable number of page tables/pde's */
+#else
+#define NKPDE 255 /* addressable number of page tables/pde's */
+#endif /* SMP */
+#endif
+
+
+
+ 正確な
+ 次の段階を行なうには, ロードアドレスを正確に計算することが必要です.
+ 単純に, アドレス空間の大きさ(バイト単位)を 0x100100000 から引き算して下さい.
+ 1GB アドレス空間の場合, その結果は 0xc0100000 になります.
+ そして, src/sys/i386/conf/Makefile.i386 にある src/sys/i386/conf/kernel.script のセクションの始めの方にある
+ ロケーションカウンタにも同じ値を入れて下さい.
+
+
+OUTPUT_FORMAT("elf32-i386", "elf32-i386", "elf32-i386")
+OUTPUT_ARCH(i386)
+ENTRY(btext)
+SEARCH_DIR(/usr/lib); SEARCH_DIR(/usr/obj/elf/home/src/tmp/usr/i386-unknown-freebsdelf/lib);
+SECTIONS
+{
+ /* Read-only sections, merged into text segment: */
+ . = 0xc0100000 + SIZEOF_HEADERS;
+ .interp : { *(.interp) }
+
+
+
+ それが完了したら, config し直してカーネルを再構築して下さい.
+ おそらく, /usr/include/vm/
+ にコピーした後に,
+ 注意: カーネルアドレス空間の大きさは, 4 メガバイトの倍数である必要があります.
+
+
+ [
+ による補足: カーネルアドレス空間は 2 の乗数である必要があると思いますが,
+ それが確かなことかどうかははっきりしていません.
+ 昔の起動コードには, 良く高位アドレスビットのトリックが使われていたため,
+ 少なくとも 256MB の粒度であることが想定されていたと思います.]
diff --git a/ja_JP.eucJP/FAQ/network.sgml b/ja_JP.eucJP/FAQ/network.sgml
index 980315bc71..a864bdeb06 100644
--- a/ja_JP.eucJP/FAQ/network.sgml
+++ b/ja_JP.eucJP/FAQ/network.sgml
@@ -1,1160 +1,1291 @@
-
+
-
+
ネットワーキング
訳: &a.arimura; &a.shou; &a.nishika;
&a.kiroh .
4 October 1998.
``diskless boot'' に関する情報はどこで得られますか?
``diskless boot'' というのは, FreeBSD がネットワーク上で起動し,
必要なファイルを自分のハードディスクではなくてサーバから読み込むものです.
詳細については
を読んでください.
FreeBSD をネットワークの router として使用することはできますか?
インターネット標準やこれまでのよい経験によって指摘されている通り,
FreeBSD は標準ではパケットを forward するように設定されていません.
しかし, の中で次の変数の値を
gateway_enable=YES # Set to YES if this host will be a gateway
このオプションによって の変数
ほとんどの場合, router についての情報を同じネットワーク
の他の計算機等に知らせるために, 経路制御のためのの process
を走らせる必要があるでしょう. FreeBSD には BSD の標準経路制御デーモン
である
が付属していますが, より複雑な状況に対処するためには
注意してほしいのは, FreeBSD をこのようにして使用している場合でも,
router に関するインターネット標準の必要条件を完全には満たしていない
ということです. しかし, 普通に使用する場合にはほとんど問題ありません.
Win95 の走っているマシンを, FreeBSD 経由でインターネットに接続できますか?
通常, この質問が出てくる状況は自宅に二台の PC があり, 一台では
FreeBSD が, もう一台では Win95 が走っているような場合です.
ここでやろうとしていう事はFreeBSDの走っている計算機をインターネット
に接続し, Win95 の走っているマシンからは FreeBSD の走っているマシンを
経由して接続をおこなう事です. これは二つ前の質問の特別な場合に相当します.
FreeBSDをとして設定する方法については,
役に立つ文書があります.
や
のような また, [ に関する節も参照してください.
]
ISC からリリースされている BIND の最新版は compile できないんでしょうか?
BIND の配布物と FreeBSD とでは ``compat/include/sys/cdefs.h を削除してください.
FreeBSD で SLIP と PPP は使えますか?
使えます. FreeBSD を用いて他のサイトに接続する場合には,
,
,
そして
のマニュアルページを見てください.
は SLIP のサーバ専用で,
は SLIP のクライアント専用です.
これらのプログラムの解説が,
の以下のセクションにあります.
-
「シェルアカウント」を通じてのみインターネットへアクセス可能な場合,
package みたいなものが欲しくなるかもしれませんね.
これを使えば, ローカルマシンから直接 ftp や http のようなサービスに
(限定的ではありますが) アクセスすることができます.
FreeBSD は NAT か IP マスカレードをサポートしていますか?
ローカルなサブネット (一台以上のローカルマシン) を持っているが,
インターネットプロバイダから 1 つしか IP アドレスの割り当てを
受けていない場合 (または IP アドレスを動的に割り当てられている場合でも),
プログラムを使いたくなるかもしれませんね.
も, 同様の機能を持っており,
が使われます.
まず のマニュアルと, のマニュアルと, を読んでみましょう. 次に,
set log Phase Chat Connect Carrier lcp ipcp ccp command
という命令を /etc/ppp/ppp.conf
に加えて
(default セクションの先頭に加えるのが一番良いでしょう)
ログを有効にしてみてください. その際, に
!ppp
*.* /var/log/ppp.log
と書かれた行が含まれているか, また, /var/log/ppp.log
が存在しているかどうか確かめておいてください. さて, これで
何が起きているのか突き止めるために, ログファイルからたくさんの
情報を得られるようになりました. ログに訳の分らない部分があっても
心配ご無用. あなたが助けを求めた誰かにとっては, その部分が
意味をなす場合があるのです.
訳注: ログの取得に syslog を使用するようになったのは
2.2.5 以降からです.
使用中の ppp のバージョンで "set log" 命令を解釈しない場合は,
をダウンロードすべきです. FreeBSD の 2.1.5 以降でビルドできます.
ppp を実行するとハングします
ホスト名の解決がうまくいっていないのでしょう. まず,
リゾルバが /etc/hosts を参照するように,
/etc/host.conf の最初の行に host と書き込んでください.
つぎに, /etc/hosts に使用しているマシンのエントリを
書き加えます. ローカルでネットワークを使用していない場合は,
localhost の行を以下のように変更してください:
127.0.0.1 foo.bar.com foo localhost
使用しているホストのエントリを追加してもかまいません.
詳細は関連するマンページを参照してください.
ppp が -auto モードでダイアルしてくれない
まず最初に, デフォルトルートが確立しているかどうかチェックして
ください. を実行すると, 以下のような情報が表示されるはずです.
Destination Gateway Flags Refs Use Netif Expire
default 10.0.0.2 UGSc 0 0 tun0
10.0.0.2 10.0.0.1 UH 0 0 tun0
これはあなたがハンドブックやマニュアル, ppp.conf.sample の中で
出てくるアドレスを使用していると仮定した場合の例です.
デフォルトルートが確立していない場合, ppp.conf の中の が走っている可能性があります. FreeBSD 2.2.5 より前の
バージョンに付属していた
add 0 0 HISADDR
と書かれた行を以下のように修正してください.
add 0 0 10.0.0.2
netstat -rn でデフォルトルートの情報が表示されない場合, もう一つ,
(2.2.2 より前のリリースでは
/etc/sysconfig と呼ばれていました) の中でデフォルトの
ルータを誤って設定し, ppp.conf から
delete ALL
の行をうっかり消してしまった可能性があります.
この場合は, ハンドブックの
- の項を読み直してください.
"No route to host" とはどういう意味ですか?
このエラーは通常, /etc/ppp/ppp.linkup に以下のような
セクションが無い場合に起こります.
MYADDR:
delete ALL
add 0 0 HISADDR
これは動的 IP アドレスを使用している場合, またはゲートウェイの
アドレスを知らない場合にのみ必要な設定です. インタラクティブモード
を使用している場合,
delete ALL
add 0 0 HISADDR
詳しい情報については, ハンドブックの
- の項を参照してください.
3 分ほど経つと接続が切れてしまう
ppp のタイムアウトは デフォルトでは 3 分です. これは
set timeout NNN
という命令によって調整することができます. ppp.conf
に入れることも, インタラクティブモードでプロンプトから入力することも
できます. ソケットを用いる
か
を使用し, 訳注 pppctl は 2.2.5R からです.
詳しい情報は
のマニュアルを参照してください.
負荷が高いと接続が切れてしまう
Link Quality Reporting (LQR) の設定を行っている場合,
マシンと接続先の間で非常にたくさんの LQR パケットが失われている
可能性があります. 結果として ppp は回線の具合いが悪いと考え,
回線を切断するのです. 2.2.5 より前のバージョンの FreeBSD では
LQR はデフォルトで有効になっています. 現在ではデフォルトの状態で
無効です. LQR は以下の命令で無効にすることができます.
disable lqr
接続がランダムに切れてしまう
時々, ノイズの多い回線, あるいは待ち機能付きの回線では,
モデムが (誤って) キャリアを失ったと思い込み, ハングアップしてしまう
ことがあります.
大多数のモデムでは, 一時的なキャリアの喪失にどれだけ我慢するか
設定で決めることができます. 例えば USR Sportster では, S10 レジスタ
の値を 10 倍した秒数がその値になります. この場合, モデムをもっと
のんびり屋さんにするには, dial 行に次のような文字列を加えると
良いでしょう.
set dial "...... ATS10=10 OK ......"
詳しくはお使いのモデムのマニュアルをご覧ください.
+
+ 接続が不規則にハングアップしてしまう
+
+ たくさんの人が, 原因不明のハングアップを経験しています.
+ 検証のために必要なのは, まずどちら側のリンクでそれが起こっているか,
+ ということです.
+
+
外部接続型モデムを利用しているなら, 単に 問題が回線のどちら側かにあることが分かったら,
+ つぎの二つの可能性が考えられるでしょう.
+
+
+ 回線の向こう側での反応がない
+
+ これに対処できることはほとんどありません. 大部分の ISP
+ は, Microsoft 社製 OS 以外の利用者に対してのサポートを拒否するでしょう.
+ まず最初に, こちら側の圧縮機能を全て無効にしてみて下さい.
+ それには, 設定ファイルをつぎのようにします.
+
+
+ disable pred1 deflate deflate24 protocomp acfcomp shortseq vj
+ deny pred1 deflate deflate24 protocomp acfcomp shortseq vj
+
+
+
そして再接続し, 変更前と同じように通信できることを確認します.
+ もしこれによって状況が改善されるか, 完全に解決したら,
+ (上の設定のうち)どの設定で状況が変化したのかを,
+ 色々な組合せで試してみて下さい. これは, ISP
+ に問い合わせを行なうときの有効な情報となります(ただし,
+ あなたが Microsoft 社製品以外のものを利用していることも
+ 明らかにしてしまいますが).
+
+
ISP に問い合わせを行なう前に, こちら側の非同期ログを有効にして,
+ 接続がハングアップするまで待って下さい. この作業は,
+ 非常に多くのディスク空間を消費するかも知れません.
+ 興味の対象となっているのは, 通信ポートから最後に読み込まれたデータです.
+ それは通常 ASCII データで, 問題点の詳細(``Memory fault, core dump''など)が
+ 記載されている可能性があります.
+
+
回線の向こう側で通信ログを監視することは可能なはずですので,
+ ハングアップが発生した時, ISP の対応が好意的ならば
+ どうして ISP 側で問題が発生したのかこちらに伝えてくれるかも知れません.
+
+ まで詳細を送って頂くか, ISP に直接私に連絡するように伝えて下さっても構いません.
+
+
+ ppp がハングアップする
+
+ ベストな方法は, スタックトレースの結果は, まで送って下さい.
+
Login OK! のメッセージが出た後, 何も起こらない
2.2.5 より前のリリースの FreeBSD では,
はリンクが確立した後, 接続先が Line Control Protocol (LCP)
- を発信するのを待ちます. しかし, 多くの ISP ではネゴジェーションを
+ を発信するのを待ちます. しかし, 多くの ISP ではネゴシエーションを
自分からは起こさず, クライアントが起こすのを待っています.
set openmode active
でもまだ "magic is the same" というエラーが出る
時折, 接続直後のログに "magic is the same" というメッセージが
あらわれることがあります. このメッセージがあらわれても何も起きない
場合もありますし, どちらかの側が接続を切ってしまう場合もあります.
ppp の実装の多くはこの問題に対応できておらず, その場合にはちゃんと
link が上がっている状態であっても, ppp が最終的にあきらめてしまい
接続を切るまで, 設定のリクエストが繰り返し送られ, 設定が行われた
という通知が log ファイルに残ると思います.
これは通常, ディスクアクセスの遅いサーバマシンのシリアルポートで
getty が生きていて, ppp がログインスクリプトか, ログイン直後に
起動されたプログラムから実行されている場合に起こります. slirp を使用
している場合に同様の症状が見られたという報告もあります. 原因は
getty の終了されるまでと, ppp が実行され, クライアント側の ppp が
Line Control Protocol (LCP) を送り始めるまでのタイミングにあります.
サーバ側のシリアルポートで ECHO が有効なままになっているので,
クライアント側の ppp にパケットが「反射」してしまうのです.
LCP ネゴジェーションの一部として, リンクの両サイドで magic number
を定めて, 「反射」が起きていないかどうか確かめる作業があります.
規約では, 接続相手がこちらと同じ magic number を提示してきたら,
NAK を送って新しい magic number を選択しなければならないと
定めています. この作業の間, サーバのシリアルポートの ECHO がずっと
有効になったままなので, クライアント側の ppp は LCP パケットを送り,
パケットが反射して全く同じ magic number が送られてくるのを見つけ,
それに対して NAK を送るのです. 一方 NAK 自体も (これは ppp が magic
number を変更しなければいけないことを意味しています) 反射して
くるので, 結果として magic number が数えきれないほど変更され,
その全てがサーバの tty バッファの中に積み重なることになるのです.
サーバでスタートした ppp はとすぐ magic number であふれかえってしまい,
LCP のネゴジェーションを十分に行ったものと判断して, さっさと接続を
切ってしまいます. 一方, クライアント側は反射が帰ってこなくなったので
満足しますが, それもサーバが接続を切ったことを知るまでです.
この事態は, 以下の行を ppp.conf の中に書いて, 相手がネゴシェー
ションを開始できるようにする事によって回避できます.
set openmode passive
これで ppp はサーバが LCP ネゴジェーションを起こすのを待つように
なります. しかし, 自分からは決してネゴジェーションを起こさないサーバ
もあるかもしれません. もしこの状況に遭遇した場合には, 次のようにして
ください.
set openmode active 3
これによって ppp は 3 秒間 passive モードを続けた後で LCP リク
エストを送り始めます. この間に相手がリクエストを送り始めた場合には
3 秒間待たずにこのリクエストに即座に応答します.
接続が切れるまでLCPのnegotiationが続く.
これが, 片方のこれを回避する最も良い方法は, 片方を
set openmode passive
というコマンドでできます. このオプションは気を付けて使わないといけ
ません. さらに
set stopped N
というコマンドを追加して,
set openmode active N
というコマンド(ここで,
ppp が接続直後に固まってしまう
2.2.5 より前のバージョンの FreeBSD では,
disable pred1
ppp の内部でシェルを起動しようとすると固まってしまう
このような場合は, 代わりに
ヌルモデムケーブルを使用しているとき, ppp が終了しない
ヌルモデムケーブルを使用して直接接続している場合,
enable lqr
- こうすると, 接続先がネゴジェーションを行う場合, デフォルトで
+
こうすると, 接続先がネゴシエーションを行う場合, デフォルトで
LQR の使用を受け入れるようになります.
ppp を -auto モードで動かすと, 勝手にダイアルすることがある
原因を突き止めるためには, 以下の命令を使用してください.
set log +tcp/ip
これで接続を通過する全てのトラヒックをログに残すことができるように
なりました. 次に突然回線がつながったときのログのタイムスタンプを
たどれば, 原因を突き止めることができるはずです.
原因がわかったら, 次に, このような状況ではダイヤルが起こらないように
しましょう. 通常, この手の問題は, DNS で名前の解決をしようとしたために
起こります. DNS による名前の解決によって, 接続が行われるのを防止する
には, 次のような手段を用います (これは
set dfilter 1 deny udp src eq 53
set dfilter 2 deny udp dst eq 53
set dfilter 3 permit 0/0 0/0
これはデマンドダイヤル機能に問題を生じさせるため,
常に適切であるとはかぎりません. ほとんどのプログラムは
他のネットワーク関連の処理をおこなう前に DNS への問い合わせ
が必要になります.
DNS の場合は, 何が実際にホスト名を検索しようとしているのかを
突き止めるべきでしょう. 大抵の場合は,
が犯人です. 設定ファイルで sendmail が
DNS に問い合わせないようになっているか確認すべきです.
自分用の設定ファイルを作成するための詳しい方法は
[ の節をご覧ください.
または, ]
define(`confDELIVERY_MODE', `d')dnl
この行を追加すると, sendmailはメールキューを処理する
(通常sendmailは30分ごとにキューを処理するよう, ``-bd -q30m''
というオプションを付けて起動されます)
までか, または
(多分ppp.linkupというファイルの中で)
``sendmail -q''というコマンドが実行されるまで, 全てのメールを
キューに溜めるようになります．
訳注 ``sendmail -q'' はその時点のメールキューの内容を処理して
終了します．
CCP エラーとはどういう意味ですか
ログファイル中の以下のエラーは,
CCP: CcpSendConfigReq
CCP: Received Terminate Ack (1) state = Req-Sent (6)
ネゴジェーションにおいて ppp は Predictor1 圧縮を用いるべく主張したが,
接続先は圧縮を使用しないことを主張した場合に起こります. このメッセージ
には何の害もありませんが, 出るのが嫌なら, 以下の命令を用いて
こちら側でも Predictor1 圧縮を無効にすることで対応できます.
disable pred1
ファイル転送の途中で, ppp が IO エラーを出して固まってしまう
FreeBSD 2.2.2 以前のバージョンの tun ドライバには, tun インタフェース
の MTU のサイズより大きなパケットを受け取ることができないというバグが
ありました. MTU のサイズより大きなパケットを受け付けると IO エラーが
起こり, syslogd 経由で記録されるのです.
ppp の仕様では, LCP のネゴジェーションを行う場合を含む
どのような場合でも 最低 1500 オクテットの
Maximum Receive Unit (MRU) を受け入れる必要があります.
ですから, MTU を 1500 以下に設定した場合でも, ISP はそれに関係なく
1500 の大きさのパケットを送ってくるでしょう. そしてこのイケてない
機能にぶちあたって, リンクが固まるのを目にすることになるのです.
FreeBSD 2.2.2 以前のバージョンでは, MTU を決して 1500 より小さく
しないことで, この問題を回避することができます.
どうして ppp は接続速度をログに残さないんでしょう?
モデムとの「やり取り」全ての行をログに残すには,
以下のようにして接続速度のログの有効化を行ってください:
set log +connect
これは
に最後にくることが要求されている "expect" という文字列がくるま
でのすべてのものをログに記録させます.
接続速度はログにとりたいけれど, PAP や CHAP を使っている
(その結果, dial スクリプト中の CONNECT 以降に全く「やりとり」
を行わない - "set login" スクリプトには何も書かない) のであれ
ば, ppp に "expect" を含んだ CONNECT 行全てがくるまで待たせる
ようにしないといけません, 以下のようになります:
set dial "ABORT BUSY ABORT NO\\sCARRIER TIMEOUT 4 \"\" ATZ OK-ATZ-OK ATDT\\T TIMEOUT 60 CONNECT \\c \\n"
ここで, CONNECT を受信してから, 何も送らず, linefeed を
待っています,
私のchatスクリプトでは`\'という文字をPPPが解釈して
くれません
PPPは設定ファイルを読み込むときに, chatの各引数が解釈されるときには, ``\P''や``\T''のような
特別なescape sequence (man pageを見てください)を見付けるために
もう1回parseを行います. このようにparseは2回繰り返されま
すので, 正しい回数だけescapeを行わないといけません.
モデムにたとえば``\''のような文字を送りたい場合には, 次のように
する必要があります:
set dial "\"\" ATZ OK-ATZ-OK AT\\\\X OK"
実際にモデムに送られる文字列は次のようになります:
ATZ
OK
AT\X
OK
他の例ですと
set phone 1234567
set dial "\"\" ATZ OK ATDT\\T"
は次のようになります:
ATZ
OK
ATDT1234567
ppp が segmentation fault になるのですが,
ppp (や他のプログラム) はけして core を吐いてはいけません.
ppp は 実効 uid が 0 で動いていますので, オペレーティングシステム
は ppp を終了させる前にディスクに core イメージを書き込みません.
しかし ppp は実際にはセグメンテーション違反や他の core を吐く原因
となるようなシグナルによって
$ tar xfz ppp-*.src.tar.gz
$ cd ppp*/ppp
$ echo STRIP= >>Makefile
$ echo CFLAGS+=-g >>Makefile
$ make clean all
$ su
# make install
# chmod 555 /usr/sbin/ppp
これで debug 可能なバージョンの ppp がインストールされます.
root で ppp を実行し, 全ての特権が無効になっているようにする必要
があるでしょう. ppp を実行する時には, current directory が make
した directory であるようにしてください.
これで, ppp がセグメンテーション例外を受け取ったときには
ppp.core という名前の core ファイルを吐くようになります. core が
吐かれたら次のようにしてください:
$ su
# gdb /usr/sbin/ppp ppp.core
(gdb) bt
.....
(gdb) f 0
.....
(gdb) i args
.....
(gdb) l
.....
質問する際には, これら全ての情報を提供して, 問題点の分析ができ
るようにしてください.
gdb の使い方に慣れている場合には, 実際に dump の原因となった
理由やそのアドレス, 関連した変数の値なども調べる事ができるでしょう.
-
- auto modeでdialをするようなprocessがconnectしてくれない
-
-
- これはauto mode でダイアルをするようなプロセスが接続されない
+
+ これは を呼び出した時, tun intergaceのIP numberが
- socketのendpointに割り当てられます. kernelは最初に外へ出ていく
- packetを作り, それをtunデバイスへ書きます. 次に を呼び出した時, tun インターフェイスの IP
+ アドレスが, ソケットの終端に割り当てられてしまうという問題です.
+ カーネルは, 外へ出ていく最初のパケットを作り, それを tun デバイスへ書き込みます.
+ そして この問題に対処する理論的な方法がいくつかあります. もし可能なら,
- 相手が同じIP numberを割り当てなおす事ができるのが最も良いです我々の側から対処できる最も簡単な方法は, tun interfaceのIP
- numberを固定する事ですが, かわりに外に出ていくpacketを変更して
- source IP numberをinterfaceのIPからnegotiateされたIPに書きかえる
- 事によっても対処できます. これが,
- (およびpppのもう1つの(最も確かな)方法は, 全てのbindされているsocketの
- IPを変更するようにsystem callを実装する事です. 3つ目の方法は, interfaceをIP number無しで立ち上げる事を許す
- ことです. 外に出ていくpacketは最初のSIOCAIFADDR ioctlが終わるまで
- は255.255.255.255というIP numberを与えられます. これによって
- socketを完全にbindすることができます. 現在のところ, これらの方法のどれもまだ実装されていません.
+ 相手が再度, 同じ IP アドレスを割り当ててくれることが一番です 我々の側から対処できる最も簡単な方法は, tun インターフェイスの
+ IP アドレスを固定する事です. またそのかわりに,
+ 外に出ていくパケットを変更して, 発信元 IP アドレスをインターフェイスの IP
+ アドレスから, 交渉によって得られた IP アドレスに,
+ 適宜書きかえる事によっても対処できます. こ
+ これは, 基本的に および, ppp の もう 1 つの(おそらく最も信頼できる)方法は, bind された
+ 全てのソケットの IP アドレスを,
+ 異なるものに変更できるシステムコールを実装することです.
+ 3 つ目の方法は, IP
+ アドレスを指定しないでインターフェイスを利用できるようにすることです.
+ 外に出ていくパケットは, 最初の SIOCAIFADDR ioctl の完了まで,
+ 255.255.255.255 という IP アドレス が与えられます.
+ これによって. ソケットは常に bind することができます.
+
何故ほとんどのゲームが -alias スイッチ付きだと動かないんですか?
訳注:この問題は佐藤 淳一さん作の NAT パッチを使っても解決できます.
をご覧ください.
libalias を使っている時にゲームなどの類のものが動作しない理由は,
外側にあるマシンが接続しようとしているか, 内側にあるマシンに (余計な)
UDP パケットを送信しようとしているからです.
内側のマシンにこれらのパケットを送るべきかについて,
packet alias ソフトウェアは関知しません.
うまく動かすためには, 実行中のものが問題の発生している
ソフトウェアだけであるかを確認し, ゲートウェイの tun インタフェースに対して
tcpdump を実行するか, ゲートウェイ上で ppp tcp/ip logging を有効化
(``set log +tcp/ip'') してください.
行儀の悪いソフトウェアを起動する際に, ゲートウェイマシンを
通過するパケットを監視すべきです. 外側から何かパケットが戻ってきた時に,
そのパケットは破棄されるでしょう (それが問題なのです).
これらのパケットの port 番号に注意して, その行儀の悪いソフトウェアを
停止してください.
これを数回繰り返して port 番号が常に同じであるかを確認してみてください.
同じであった場合は, /etc/ppp/ppp.conf の適切なセクションに次の行を入れると,
そのソフトウェアは動作するようになるでしょう.
alias port proto internalmachine:port port
ここで ``proto'' は ``tcp'' か ``udp'' であり,
``internalmachine'' はパケットを送りたいマシン, そして
``port'' はパケットのディストネーションの port 番号です.
上記のコマンドを変更せずに他のマシン上でそのソフトウェアを
使用できるようにはしたくないかもしれません. そして
同時に二つの内部のマシン上でそのソフトウェアを実行することは
この質問の範囲を超えています. 結局, 外側の世界からは
内部ネットワーク全体がただ一つのマシンとして見えるのです.
port 番号が常に同じとは限らない場合, さらに三つのオプションがあります.
1) libalias でサポートするようにし, 結果を送り付ける.
特定の場合の例は /usr/src/lib/libalias/alias_*.c にあります
(alias_ftp.c は良いプロトタイプです). これには通常, 外向きの特定のパケットを読み,
内部の計算機のある特定のポートへの接続を開始するような命令が
外部の計算機対して送られていることを見分け, 後続のパケットがどこに行けば
いいのかが分かるように, エイリアステーブル中の ``route'' の部分を設定する,
という作業が含まれます.
これは最も難しい方法ですが, 最も良い方法でもありますし, ソフトウェアが
複数の計算機で動くようにできます.
2) プロクシを使う. アプリケーションが, 例えば socks5
をサポートしているか, (cvsup のように) ``passive'' オプションを持っていると
この方法が使えます. ``passive'' とは相手側のほうから接続を求めてくることを
避けるためにあるオプションです.
3) ''alias addr''を使ってなんでもかんでも内部の計算機に向けて
流してしまう. これはちょっと無理矢理な解決法です.
FCS エラーって何?
FCS とは show hdlc
コマンドを使って表示できます.
リンクの品質が悪かったり, シリアルドライバがパケットを取り
こぼしていたりすると, FCS エラーがたびたび発生します. FCS エラー
は, 圧縮プロトコルの速度低下の原因にはなりますが, 特に心配する
必要はありません. 外付けモデムを使っている場合は, ケーブルが
ちゃんとシールドされているかを確認してください. そうでない場合,
FCS エラーの原因となる場合があります.
接続直後からリンクがフリーズし, 大量の FCS エラーが発生する
場合は, リンクが 8 ビットクリーンでない可能性があります. ソフト
ウェアフロー制御 (XON/XOFF) が使われていないことを確認してくだ
さい. どうしてもソフトウェアフロー制御を使わなければならない場
合は, set accmap 0x000a0000 コマンドを使用して, ppp
に ^Q と ^S をエスケープさせてください
リモートホストが ログファイルにリンクを終了した原因となるような記録がない場合は,
リモートホスト(プロバイダ?)の管理者に, セッションを終了された
理由を尋ねてください.
どれにも当てはまらない! どうしたらいいの?
これまでの全ての質問に当てはまらない場合, 設定ファイル, コマンドの出力 (接続前と接続後) を含む,
あなたの持っている全ての情報を
メーリングリストや
ニュースグループへ
送ってください. 誰かがあなたを正しい方向へ導いてくれるでしょう.
/dev/ed0 デバイスを作成することができません.
Berkeley UNIX におけるネットワークの構成においては, ネットワーク
のインタフェースは kernel のコードからのみ直接あつかうことが
できます. より詳しく知りたい場合は, /etc/rc.network
というファイルや, このファイルの中に書いてあるさまざまなプログラム
についてのマニュアルページを見てください. それでもまだ分からない場合には,
他の BSD 系の OS のネットワーク管理についての本を読むべきでしょう.
ごく少しの例外をのぞいては, FreeBSD のネットワーク管理は SunOS 4.0
や Ultrix と基本的に同じです.
Ethernet アドレスのエイリアスはどのようにして設定できますか?
のコマンドラインに ``
ifconfig ed0 alias 204.141.95.2 netmask 0xffffffff
3C503 で他のネットワークの port を使用するにはどのようにすればよいですか?
他の port を使用したい場合には, のコマンドラインにパラメータを
追加しなければなりません. default は ``.
の using the ifconfig_* の変数を使って指定されるはずです.
FreeBSD との間で NFS がうまくできません.
PC 用のネットワークカードによっては NFS のようなネットワークを
酷使するアプリケーションにおいて問題を起こすものがあります.
この点に関しては
を見てください.
何故 Linux のディスクを NFS マウントできないのでしょうか?
Linux の NFS のコードによっては許可されたportからの
リクエストからしか受けつけないものがあります.
以下を試してみてください.
mount -o -P linuxbox:/blah /mnt
何故 Sun のディスクを NFS マウントできないのでしょうか?
SunOS 4.X が走っている Sun Workstation は許可された port からの
mount のリクエストしか受けつけません.
以下を試してみてください.
mount -o -P sunbox:/blah /mnt
PPP で NeXTStep に接続する際に問題があるのですが.
の中で次の変数を NO にして,
TCP extension を無効にしてみてください.
tcp_extensions=NO
Xylogic の Annex も同様の問題がありますので, Annex 経由で PPP をおこなう
場合にもこの変更を行ってください.
IP multicast を有効にするには?
2.0 かそれ以降の FreeBSD は, 標準の状態で完全に multicast に対応しています.
現在使用している計算機を multicast の router として使用するには,
/etc/rc.conf でフラグ MBONE用のツールは ports 内の専用のカテゴリー mbone にあります.
詳しい情報は
にあります.
DEC の PCI チップセットを用いている network カードにはどのような物がありますか?
による一覧に, よりmodernな物を追加したものを
以下に示します.
Vendor Model
----------------------------------------------
ASUS PCI-L101-TB
Accton ENI1203
Cogent EM960PCI
Compex ENET32-PCI
D-Link DE-530
Dayna DP1203, DP2100
DEC DE435
Danpex EN-9400P3
JCIS Condor JC1260
Linksys EtherPCI
Mylex LNP101
SMC EtherPower 10/100 (Model 9332)
SMC EtherPower (Model 8432)
TopWare TE-3500P
Zynx ZX342
何故自分のサイトのホストに対して FQDN を使用する必要があるのですか?
実際にはそのホストは別のドメインにあるのではないですか. たとえば,
foo.bar.edu というドメインの中から, bar.edu ドメインにある
``mumble'' というホストを指定したい場合には, ``mumble'' だけでは
駄目で, ``mumble.bar.edu'' という fully-qualified domain name で
指定しなければなりません.
伝統的に, BSD の BIND の resolver ではこのような事は可能でしたが,
FreeBSD に入っている
の現在のバージョンでは, 自分以外のドメインに対して FQDN
でない別名を自動的につけてくれるような事はありません.
したがって mumble というホスト名は mumble.foo.bar.edu
という名前か, もしくは root ドメイン内にある場合にしか適用されません.
これは, mumble.bar.edu と mumble.edu
ということなったドメイン名に対してホスト名のサーチがおこなわれていた
以前の振る舞いとは異なったものです. このような事が悪い例もしくは
セキュリティホールとみなされる理由については RFC 1535 を見てください.
の中で
domain foo.bar.edu
と書いてある行を
search foo.bar.edu bar.edu
のように書きかえることで, 上のような事ができます. しかし,
RFC 1535 にあるように, search order が ``ローカルな管理と
パブリックな管理の境界'' をまたがないようにしてください.
すべてのネットワークの操作に対して ``Permission denied'' というメッセージが表示されるのですが.
- もしfirewallの設定を間違えた場合にネットワークの操作が再びできる
- ようにするには, root で login して次のコマンドを実行してください.
+
もしファイアウォールの設定を間違えた場合にネットワークの操作が再びできる
+ ようにするには, root でログインして次のコマンドを実行してください.
ipfw add 65534 allow all from any to any
-
/etc/rc.conf に"firewall_type='open'"を追加してもよい
+
/etc/rc.conf に "firewall_type='open'" を追加してもよい
でしょう.
-
FreeBSD の firewall の設定についての情報は
+
FreeBSD のファイアウォールの設定についての情報は
にあります.
- IPFWのオーバーヘッドはどのくらいでしょうか?
+ IPFW のオーバーヘッドはどのくらいでしょうか?
- この答えはあなたのrule setとprocessorのスピードによって
- ほとんど決まります. Ethernetに対して少しのrule setだけを使っ
+
この答えはあなたのルールセットとプロセッサのスピードによって
+ ほとんど決まります. イーサネットに対して少しのルールセットだけを使っ
ているほどんどの場合には, その影響は無視できる程度です. 実
際の測定値を見ないと満足できない方々のために, 実際の測定結
果をお見せしましょう.
-
次の測定は486-66上で2.2.5-STABLEを使用しておこなわれました.
- IPFWは変更が加えられて, 次の測定は 486-66(訳注: Intel 社製 CPU i486, 66MHz のこと)上で
+ 2.2.5-STABLE を使用しておこなわれました.
+ IPFW は変更が加えられて, それぞれ1000ずつのruleが入っている2つのrule setでテストが
- おこなわれました. ひとつ目のsetは最悪のケースを見るために
+
それぞれ 1000 ずつのルールが入っている 2 つのルールセットでテストが
+ おこなわれました. ひとつ目のルールセットは最悪のケースを見るために
ipfw add deny tcp from any to any 55555
- というruleを繰り返したものです.
+ というルールを繰り返したものです.
-
このsetを用いますと, (port番号によって) packetが全てのruleにマッチ
- しない事が最終的に決まるまでに, IPFWのpacketをチェックするルーチン
- のほとんど全てが実行されますので, 最悪のケースとなります. この
- ruleを999個繰り返した後にallow ip from any to any が
+
パケットが(ポート番号のせいで)このルールにマッチしないことがわかるまでに,
+ 何度も実行される IPFW のパケットチェックルーチンによって,
+ これは最悪のケースを示します.
+ このルールを 999 個繰り返し並べた後に allow ip from any to any が
書かれています.
-
2つ目のsetは, なるべく早くチェックが終了するように書かれたものです:
-
+
2つ目のルールセットは, なるべく早くチェックが終了するように書かれたものです:
+
ipfw add deny ip from 1.2.3.4 to 1.2.3.4
-
このruleではsource側のIPアドレスがマッチしないのでチェックは
- すぐに終了します. 上のsetとおなじように, 1000個目のruleは
+
このルールでは, 発信元の IP アドレスがマッチしないのでチェックは
+ すぐに終了します. 上のルールセットとおなじように, 1000 個目のruleは
allow ip from any to any です.
-
1つ目のsetでは, packetあたりのoverheadはだいたい2.703ms/packet,
- 言いかえると1つのruleあたり2.7マイクロ秒です. したがってこのruleに
- おけるpacketを処理する時間の理論的な限界は1秒あたり約370 packetです.
- 10MbpsのEthernetで1500 byte以下のpacketサイズを仮定すると, 55.5%の
- バンド幅までしか使えない事になります.
-
-
2つ目のsetでは, それぞれのpacketはだいたい1.172msで処理されて
- いますので1つのruleあたり1.2マイクロ秒となります. packetの
- 処理時間の理論的な限界はだいたい1秒あたり853 packetとなりますので
+
1 つ目のルールセットでは, パケットあたりのオーバヘッドはおよそ
+ 2.703ms/packet, これはだいたい 1 つのルールあたり 2.7 マイクロ秒
+ かかっていることになります.
+ したがって, このルールにおけるパケット処理時間の理論的な限界は,
+ 毎秒約 370 パケットです.
+ 10Mbps のイーサネットで 1500 バイト以下のパケットサイズを仮定すると,
+ バンド幅の利用効率は 55.5% が限界となることになります.
+
+
2 つ目のルールセットでは, それぞれのパケットがおよそ
+ 1.172msで処理されていますので, だいたい 1 つのルールあたり 1.2 マイクロ秒
+ かかっていることになります.
+ パケット処理時間の理論的な限界は, 毎秒約 853 パケットとなりますので,
10Mbps Ethernetのバンド幅を使い切ることができます.
-
このテストでのruleの数は多過ぎますので, 実際に使用している際の
+
このテストでのルール数は多過ぎるため, 実際に使用する際の
結果を反映している訳ではありません. これらは上に示した数値を出す
- ためだけに用いられたものです. 実際に効率の良いrule setを作るために
- は, 次のような事を考えておけばよいでしょう.
+ ためだけに用いられたものです. 効率の良いルールセットを作るためには,
+ 次のような事を考えておけばよいでしょう.
- - `確定している' ruleは, TCPのtrafficの多数を処理するために
- 前の方に持ってきてください. そしてこのruleの前には
allow tcp
- という記述をしないでください.
+ - `確定している' ルールは先頭の方に持ってきてください.
+ これは, 多数の TCP のトラフィックがこのルールで処理されるためです.
+ そしてこのルールの前には
allow tcp という記述を置かないでください.
- - 良く使われるruleを, あまり良く使われないruleよりも
- 前の方に(もちろん
firewallの許可の設定を変えない範囲で )
+ - 良く使われるルールを, あまり良く使われないルールよりも
+ 前の方に(もちろん
ファイアウォールの許可設定を変えない範囲で )
持ってきてください.
- ipfw -a l のようにしてpacket数の統計を取ることによって
- どのruleが最もよく使われているかが分かります.
+ ipfw -a l のようしてパケット数の統計を取ることで,
+ どのルールが最もよく使われているかを調べることができます.
サービス要求を他のマシンにリダイレクトするには?
FTP などのサービスのリクエストは, 'socket' パッケージを利用
してリダイレクトできます. 'socket' パッケージは ports の
'sysutils' カテゴリに含まれています. リダイレクトしたいサービ
- ス(/etc/inet.conf のコマンド行を socket を呼ぶように変
+ ス(/etc/inet.conf のコマンド行をソケットを呼ぶように変
更してください. 変更例:
ftp stream tcp nowait nobody /usr/local/bin/socket socket ftp.foo.com ftp
ここで 'ftp.foo.com' はリダイレクト先のホスト名, 行の最後の'ftp'
はポートです.
+
+ バンド幅の管理を行なえるツールはどこで手に入れられますか?
+
+ FreeBSD 用のバンド幅管理ツールには, 無料で手に入れられる
+ と,
+
+ から入手できる Bandwidth Manager という市販のものの 2 種類があります.
+
+
+ なぜ ``/dev/bpf0: device not configured" が出るのでしょうか?
+
+ バークレーパケットフィルタ
+ ドライバは, それを利用するプログラムを実行する前に有効にしておく必要があります.
+ カーネルコンフィグファイルに, 次のように追加してカーネルの再構築をして下さい.
+
+
+ pseudo-device bpfilter # Berkeley Packet Filter
+
+
+ そして再起動してから, 次にデバイスノードを作成する必要があります.
+ これは, 次のように入力し, /dev を変更することで行ないます.
+
+
+ # sh MAKEDEV bpf0
+
デバイスノードの作成の詳細は, を参照して下さい.
+
diff --git a/ja_JP.eucJP/FAQ/troubleshoot.sgml b/ja_JP.eucJP/FAQ/troubleshoot.sgml
index 2688b4f28b..ea152fd6e3 100644
--- a/ja_JP.eucJP/FAQ/troubleshoot.sgml
+++ b/ja_JP.eucJP/FAQ/troubleshoot.sgml
@@ -1,454 +1,545 @@
-
+
-
+
トラブルシューティング
訳: &a.yoshiaki;.10 November 1997.
ハードディスクに不良ブロックがあります!
SCSI ディスクの場合は自動的に再マップする機能があるはずです.
しかし, 理解し難い理由から多くのドライブがこの機能が無効化
されて出荷されています...
これを有効化するには, 最初のデバイスのモードページを変更する
必要があります. これは次のコマンドを実行することで, FreeBSD
上でおこなうことができます (root 権限でおこないます).
scsi -f /dev/rsd0c -m 1 -e -P 3
そして, AWRE と ARRE の値を 0 から 1 へ変更します:-
AWRE (Auto Write Reallocation Enbld): 1
ARRE (Auto Read Reallocation Enbld): 1
-
他の種類のディスクでは, オペレーティングシステムからサポート
- されているかによります. 残念ながら, この目的のために FreeBSD
- が提供する ``bad144'' コマンドはかなり手を入れる必要があります...
-
-
IDE ディスクは, おそらく不良ブロックの再マップを内蔵していると
- 思います; ディスクの説明書がある場合は, この機能が無効になって
- いるかを確認するとよいでしょう. しかし, ESDI, RLL, ST-506
- ディスクは, 通常これをおこないません.
-
-
再マップが可能になっていて不良ブロックを見つけたのであれば,
- ドライブを交換することを考えましょう. 不良ブロックの状態は時間と
- ともに悪い方向にしか行きません.
+
以下は,
+ から寄せられたものです.
+
+ IDE ドライブの場合は通常, 不良ブロックは潜在的な障害の兆候です.
+ 最近の IDE ドライブは, 内部の不良ブロック再マッピング機能を有効にした状態で
+ 出荷されています. また, 今日の IDE ハードディスクメーカは,
+ 出荷以降に不良ブロックが発生することに関して保証を提供していて,
+ 不良ブロックのあるディスクドライブを交換するサービスを行なっています.
+
+
もし, 不良ブロックのある IDE ディスクドライブを復旧しようと思うなら,
+ IDE ドライブメーカが提供する IDE 診断プログラムをダウンロードして,
+ そのドライブに使ってみてください. この種のプログラムは大抵,
+ ドライブの制御部分に対して不良ブロックを再走査し,
+ 不良ブロックを使用不能にするようにセットすることができます.
+
+
ESDI, RLL および MFM ドライブの場合, 不良ブロックはドライブの
+ 正常な部分であり, 一般的に言って障害を表すものではありません.
+ PC では, ディスクドライブコントローラカードと BIOS が不良ブロックの
+ 使用不能化の作業を行ないます. DOS など, ディスクアクセスに BIOS
+ を経由する OS にとっては有効に働きますが, FreeBSD
+ のディスクドライバは BIOS を利用しません. そのため,
+ 代替として bad144 という機構が存在します.
+ bad144 は, wd ドライバにだけ作用し, SCSI ドライバに利用することは
+ *できません*. bad144 は, 検出された不良セクタをスペシャルファイルに
+ 記録するという働きを持っています.
+
+
bad144 を利用する上で, 注意しなければならない点が一つあります.
+ それは, 不良ブロックスペシャルファイルは, ディスクの最終トラックに
+ 置かれるということです. このファイルには, ディスクの先頭の付近,
+ /kernel ファイルが位置しているであろう部分で発生した不良セクタが
+ 記録されています. したがって, このファイルは BIOS コールを使って
+ カーネルファイルを読み込む起動プログラムがアクセス可能でなければなりません.
+ これはつまり, bad144 を利用するディスクは, 1024 シリンダ,
+ 16 ヘッド, 63 セクタを超えてはならないということを意味し,
+ bad144 を利用したディスクが実質 500MB を超えられないことになります.
+
+
bad144 を使うには, FreeBSD のインストール時に表示される fdisk 画面で,
+ "Bad Block" 走査を ON に設定するだけです. これは, FreeBSD 2.2.7 以降で
+ 機能します. ディスクは, 1024 シリンダ以内でなければなりません.
+ ディスクドライブは事前に少なくとも 4 時間, ディスクが温度によって膨張し,
+ トラックに曲がりが出るまで回転させることをお薦めします(訳注: 温度変化に
+ 対する膨張によって, ディスクが微小変形することにより発生する不良セクタを
+ 確実に検出するためです).
+
+
大容量の ESDI ドライブのように, 1024 シリンダを超えるディスクの場合,
+ DOS 上でそのディスクが利用できるように, ESDI コントローラは特殊な変換モードを
+ 利用します. fdisk の "set geometry" コマンドを使って
+ "変換された(translated)" ジオメトリに切替えると, wd ドライバは
+ この変換モードを解釈できます.
+ その際, FreeBSD パーティションを作成するのに "dangerously dedicated" モードを
+ 利用してはいけません. このモードは, そのようなジオメトリを無視するからです.
+ たとえ fdisk がオーバーライドされたジオメトリ情報を使ったとしても,
+ 已然としてディスクの真の大きさを保持しているため, 大きすぎる FreeBSD
+ パーティションを作成しようとしてしまうでしょう.
+ ディスクジオメトリ情報が変換されたジオメトリ情報にかわっている場合は,
+ 手動でブロック数を入力し, パーティションを作成する必要があります.
+
+
大容量の ESDI ディスクを ESDI コントローラでセットアップするには,
+ ちょっとしたトリックを使います. まず, DOS のディスクで起動して
+ そのディスクを DOS パーティションとしてフォーマットします.
+ そして FreeBSD を起動し, インストーラの fdisk 画面で
+ DOS パーティションのブロックサイズとブロック数を読みとり, メモしておきます.
+ ジオメトリ情報を DOS が利用しているものと同一に再設定し,
+ DOS パーティションを削除して "cooperative" FreeBSD パーティションを
+ 先程記録したブロックサイズを使って作成して下さい.
+ そのパーティションを起動可能パーティションに設定し, 不良ブロック走査を
+ 有効にして下さい. 実際のインストールでは, ファイルシステムが作成される前に
+ bad144 が最初に実行されます(Alt-F2 を押すことで状況を確認できます).
+ 不良セクタファイルを作成中に何らかの障害が発生したなら,
+ システムを再起動して, もう一度最初からやり直しになります.
+ おそらくディスクジオメトリ情報の設定を大きくしすぎているのでしょう.
+ (やり直しは, DOS によるフォーマットとパーティション確保を含みます)
+
+
もし, 不良ブロックの再マッピングを有効にしていて不良ブロックが見付かったら,
+ ドライブの交換を考えて下さい. 不良ブロックは, 時間とともに悪化するからです.
Bustek 742a EISA SCSI が認識されません.
この情報は 742a のためのものですが, 他の Buslogic カードについても
同様のことが言えます. (Bustek = Buslogic)
742a カードには大きくわけて 2つのバージョンが存在します.
ハードウェアリビジョンの A-G と H 以降です. リビジョンの
文字はカードの隅にあるアセンブリ番号の後ろにあります.
742a は二つの ROM チップを持っており, 一つは BIOS チップで
もう一つはファームウェアチップです. FreeBSD はあなたの
持っているものがどの BIOS バージョンかは問題ありませんが,
ファームウェアバージョンについては問題となります.
Buslogic の技術サポート部門に連絡すれば, アップグレード版の
ROM を送ってくれることでしょう. BIOS チップと
ファームウェアチップはペアで出荷されます.
アダプタカードのハードウェアリビジョンにあわせた
最も新しいファームウェア ROM を使用しなければなりません.
リビジョン A-G のカードには, 2.41/2.21 までの
BIOS/ファームウェアのセットを使用することができます.
リビジョン H 以降のカードには, 最新のものである
4.70/3.37 の BIOS/ファームウェアのセットを
使用することができます. これらのファームウェアの違いは,
ファームウェア 3.37 が 「ラウンドロビン方式」
をサポートしているところからきています.
Buslogic のカードには, 製造番号も刻印されています. 古い
ハードウェアリビジョンのカードを持っている場合は, Buslogic の RMA
部門に問い合わせて製造番号を伝えると, 新しいハードウェアリビジョンの
カードに交換することもできます. もしカードが十分新しければ, 彼らは
交換に応じてくれるでしょう.
FreeBSD 2.1 は ファームウェアリビジョン 2.21
以降のものをサポートしています.
これよりも古いファームウェアリビジョンのものは,
Buslogic カードとして正常に認識されません.
しかし, Adaptec 1540 として認識されるかもしれません.
初期の Buslogic のファームウェアは AHA1540 互換モードを
持っています. しかし, EISA カードにとってこれは
よいことではありません.
古いハードウェアリビジョンのカードを持っていてファームウェア
2.21 を入手するのであれば, ジャンパ W1 の位置をデフォルトの
A-B から B-C に合わせる必要があるでしょう.
742a EISA カードには, [の節で説明している
「16 MB を越える」ことによる問題はありません.
これは Vesa-Local Buslogic SCSI カードで発生する問題です.
]
HP Netserver 上のオンボード SCSI コントローラが認識されません.
基本的にこれは既知の問題です. HP Netserver マシンの
EISA オンボード SCSI コントローラは EISA のスロット番号 11
を占有しますが, 「本当の」EISA スロットはすべてそれよりも
前のアドレスに配置されているのです. 残念ながら,
10 番以上の EISA スロットは PCI に割り当てられたアドレス空間
と衝突し, FreeBSD
の自動コンフィグレーションは, 現状ではうまくこの状況を
処理できていないのです.
ですから現時点での最良の方法は, カーネルオプションの
に記述されているようにしてカーネルをコンパイルし,
構築してください.
もちろん, これはこのようなマシンにインストールする際に
卵が先か鶏が先か」といった問題を生み出すことになります.
この問題を回避するために, ユーザコンフィグ
(UserConfig) の中には特別な仕組みが組み込まれています.
このとき ``visual'' インタフェースは使用せず,
コマンドラインインタフェースを使用してください. 単純に
eisa 12
quit
とプロンプト上から打ち込み,
後は普通にインストールをおこなってください.
とにかくカスタムカーネルのコンパイルとインストールをおこなうことを
おすすめしますが,
も現時点ではこの値の変更を認識するようになっています.
うまくいけば, 将来のバージョンではこの問題が解決していることでしょう.
をご覧ください.
この CMD640 IDE コントローラはどこかおかしいようです.
それは壊れているのです. 両方のチャンネルを同時に制御できないのです.
現在ではこのチップを使っているシステムでは自動的に検出して
うまく動かすためのしくみが使えるようになっています. くわしくは
マニュアルページのディスクドライバ (man 4 wd) を参照してください.
CMD640 IDE コントローラを使っているシステムで FreeBSD 2.2.1
あるいは 2.2.2 を使っている場合でセカンダリのチャネルを
使いたいのであれば
``
たぶん IRQ の衝突が原因でしょう (二つのボードが同じ IRQ
を使用しているなど). FreeBSD 2.0.5R 以前では, これに関しては
寛大で IRQ の衝突があってもネットワークドライバは機能して
いました. しかし 2.0.5R 以降は IRQ の衝突はもはや寛大では
ありません. -c オプションをつけてブートして ed0/de0/... の
エントリをボードの設定に合わせてください.
ネットワークカードの BNC コネクタ (訳注: 10BASE-2 タイプ
のインターフェース) を使っている場合, デバイスのタイムアウト
はターミネーションの不良によっても起きます.
これをチェックするにはケーブルを外してターミネータを直接 NIC
に接続します. そしてエラーメッセージが消えるかどうか
確認します.
NE2000 コンパチブルカードのなかには UTP ポートのリンクが
なかったりケーブルが接続されていない場合にこのエラーを出す
ものがあります.
CDROM をマウントしようとすると ``Incorrect super block'' と言われます.
にマウントしたいデバイスのタイプを指定する必要
があります. デフォルトでは
はファイルシステムを
`` オプションをつけて明示する必要があります.
これはもちろん
CDROM が ISO 9660 ファイルシステムである場合です. ほとんどの
CDROM はこの形式です. 1.1R の FreeBSD では (訳注: 現行の 2.1.5R,
2.2R でも同様です) 自動的に Rock Ridge 拡張
(長いファイル名への対応) をうまく解釈します.
CDROM のデバイス ``/dev/cd0c '' を
/mnt にマウントしたい場合の例では, 次のようにします:
mount -t cd9660 /dev/cd0c /mnt
デバイスの名前はインタフェースによっては別の名前になっている
かもしれないので注意してください (``/dev/cd0c '' は
この場合の例です).
オプション ``
mount_cd9660 /dev/cd0c /mnt
CDROM をマウントしようとすると ``Device not configured'' と言われます.
これは 一般的に CDROM ドライブの中に CDROM が入っていないか,
ドライブがバス上に見えないことを意味します. ドライブに CDROM
を入れるか, IDE (ATAPI) であれば master/slave の状態をチェック
してください. CDROM ドライブに CDROM を入れてから認識するまで
数秒かかりますので少し待ってみてください.
SCSI CDROM ではバスリセットへの応答時間が遅いために失敗する
ことがあるかもしれません. SCSI CDROM を持っている場合は
カーネルコンフィグレーションファイルに以下の行を加えて
再コンパイルして試してみてください.
options "SCSI_DELAY=15"
(訳注: 現在の GENERIC カーネルでは上の設定はデフォルトに
なっています. 問題のある場合は SCSI_DELAY の数値を増やして
みてください.)
私のプリンタはとてつもなく遅いのです. どうしたらよいのでしょう?
パラレルインタフェースで, 問題はとんでもなく遅いだけであるなら,
プリンタボートを ``polled'' モードに設定してみてください:
lptcontrol -p
HP の新しいプリンタのいくつかは割り込みモードでは
使えないようです. (完全にわかったわけではありませんが)
タイミングの問題のように思われます.
私のプログラムは時々 ``Signal 11'' のエラーで止まってしまいます.
これはハードウェア (メモリ, マザーボードなど) の不具合いが
原因です. PC でメモリテストプログラムを動かしてみてください.
ただしメモリが正常に動作していると報告されたとしても, ぎりぎりで
メモリテストにパスしたメモリは, 処理の内容 (例えば
kernel のコンパイルや特にシステムの負荷が高いような場合には,
Adaptec 1542 などの SCSI コントローラのバスマスタ DMA など)
によっては問題が起きる可能性は大いにあります.
SIG11 FAQ (後で URLを示します) では遅いメモリが一般的に問題
を起こしがちであることを指摘しています. BIOS セットアップで
ウエイトステート数を増やすかメモリを速いものに交換してください.
私の場合はキャッシュ RAM やオンボードキャッシュコントローラ
の問題でした. このような問題ではないか確認するために BIOS
セットアップでオンボード (セカンダリ) キャッシュを無効にして
みてください.
以下のところには広い範囲の FAQ があります.
ブートの時に画面が真っ暗になって同期も取れません.
これは ATI Mach 64 ビデオカードの既知の問題です.
この問題はカードがアドレス
ドライバのバグ
(仕様?) のため4番目のシリアルポートがなくても, 通常この
アドレスを使う sio3 (4 番目のポートにあたります) を無効にしても,
ドライバはこのアドレスをさわります.
バグが修正されるまでは, 次のようにして対処してください.
- ブートプロンプトが出たら
問題はありません.
- exit とタイプしてブートを続行します.
もしシリアルポートを有効にしたいのであれば以下の変更をおこなって
新しいカーネルを作る必要があります.
/usr/src/sys/i386/isa/sio.c の中で1ヵ所ある
この対処をおこなった後でもまだ X ウィンドウシステムはうまく
動かないかもしれません. いくつかの新しい ATI Mach 64 ビデオカード
(特に ATI Mach Xpression) は現在のバージョンの
を見てベータリリースへのリンクを追ってください.
以下のファイルを持ってきましょう.
AccelCards, BetaReport, Cards, Devices, FILES, README.ati,
README.FreeBSD, README.Mach64, RELNOTES, VGADriver.Doc,
X312BMa64.tgz
古いファイルをこの新しいバージョンのファイルに置き換え,
をもう一度実行します.
128MB の RAM があるのですが, 64MB しか認識しません.
FreeBSD がメモリのサイズを BIOS から取得する方法の制限により,
KB 単位で 16 ビット分までしか検出できません
(すなわち最大 65535Kb=64MB です)(これより少ない場合もあります. ある BIOS
の場合はメモリサイズが 16MB に制限されます).
64MB 以上のメモリを積んでいる場合, FreeBSD はそれを検出しようとし
ます. しかしその試みは失敗するかもしれません.
この問題を回避するには, 以下に示すカーネルオプションを
使用する必要があります. 完全なメモリ情報を BIOS から取得する
方法もありますが, ブートブロックに空きが無いため実装できません.
ブートブロックの問題が解決されれば, いつか拡張 BIOS
機能を使用して完全なメモリ情報を取得できるようになるでしょう.
とりあえず現在は, カーネルオプションを使ってください.
options "MAXMEM=<n>"
FreeBSD 2.0 が ``kmem_map too small!'' と言ってパニックします.
このパニックは, ネットワークバッファ (特に mbuf クラスタ)
の仮想メモリが無くなったことを示します. 以下のオプションを
カーネルコンフィグファイルに追加して mbuf クラスタに使用できる
仮想メモリの量を増やしてください.
options "NMBCLUSTERS=<n>"
<n> には, 同時に使用したい TCP コネクションの数に応じて
512 から 4096 までの数値を指定できます. とりあえず 2048 を
試してみるのを勧めます. これでパニックは完全の予防できるはずです.
mbuf クラスタの割り当て／使用状況については,
で知ることができます.
name="netstat -m"> で知ることができます. NMBCLUSTERS の
デフォルト値は
新しいカーネルでリブートすると ``CMAP busy panic'' となってパニックを起こしてしまいます.
ファイル /var/db/kvm_*.db において範囲外のデータを
検出するためのロジックは失敗することがあり, こうした矛盾のある
ファイルを使用することでパニックを引き起こすことがあります.
これが起こったなら, シングルユーザでリブートした後に,
以下のコマンドを実行してください.
rm /var/db/kvm_*.db
ahc0: brkadrint, Illegal Host Access at seqaddr 0x0 というエラーが出ます
これは Ultrastor SCSI Host Adapter と衝突しています.
ブート時に kernel configuration メニューに入り, 問題を起こしている
を disable にしましょう.
sendmailが ``mail loops back to myself'' というメッセージを出すのですが.
この事は, sendmail FAQ に次のように書いてあります.
* "Local configuration error" というメッセージが出ます. 例えば:
553 relay.domain.net config error: mail loops back to myself
554 ... Local configuration error
のような物ですが, どのようにしたらこの問題を解決できますか?
これは, 例えば domain.net のようなドメイン宛てのメールを
MX record で特定のホスト (ここでは relay.domain.net) に送ろう
としたのに, そのホストでは domain.net 宛てのメールを受け取れる
ような設定になっていない場合です. 設定の際に
FEATURE(use_cw_file) を指定してある場合には/etc/sendmail.cw
の中に domain.net を追加してください. もしくは, /etc/sendmail.cf
の中に "Cw domain.net" を追加してください.
もはや現在の は sendmail release とは一緒には保守されて
いません. しかし次のネットニュースに定期的に投稿されてます.
,
,
,
,
.
また, メール経由でコピーを入手する場合は
宛まで本文に "send
usenet/news.answers/mail/sendmail-faq" と書いて送ります.
リモートマシン上のフルスクリーンアプリケーションがうまく動かない
リモートマシンのターミナルタイプが FreeBSD のコンソールで
つかわれている cons25 以外のものです.
この問題を解決する方法はいろいろあります:
- リモートマシンに login した後, shell 変数の TERM に
ansi か sco のいずれかを設定します.
- ローカル側で
のような VT100 エミュレータを使用します.
screen は一つのターミナルの中で複数のセッションを
並列動作させることができますし, 本来の機能も優れています.
- リモートマシンのターミナルデータベースに
cons25
のエントリをインストールします.
- Xを起動してリモートマシンに
xterm から login
します. (訳注: 日本語が必要な場合は kterm 等を
利用します)
+
+
+ 私のマシンで "calcru: negative time..." と表示されるのですが
+
+ これは, 割り込みに関連するさまざまな不具合によって発生します.
+ あるいは, あるデバイスが元々持っているバグが表面化したのかも知れません.
+ この症状を再現させる一つの方法として, パラレルポート上で,
+ TCP/IP を 大きな MTU で走らせるというものがあります.
+ グラフィックアクセラレータがこの症状を起こすことがありますが,
+ その場合はまず, カードの割り込み設定を確認して下さい.
+
+
この問題の副作用として, プロセスが "SIGXCPU exceeded cpu time limit"
+ というメッセージとともに終了してしまう, というものがあります.
+
+
1998 年 11 月 29 日に公開された FreeBSD 3.0 以降で
+ この問題が解決しないなら, 次の sysctl 変数をセットしてください.
+
+
+ sysctl -w kern.timecounter.method=1
+
+
+
これは, パフォーマンスへ強い影響を与えますが, 問題の発生に比べれば
+ おそらく気にならない程度でしょう. もし, これでもまだ問題が残るようなら,
+ カーネルオプションの "NTIMECOUNTER" を大きな値に増やして下さい.
+ "NTIMECOUNTER=20" にまで増やしても解決しない場合は,
+ 計時処理の信頼性が保てない程の割り込みが, そのマシン上で起こっていることを
+ 意味します.
+