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,6 +1,6 @@ - + - + 商用アプリケーション @@ -19,7 +19,63 @@ 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 に関する情報は から 手に入れることができます. @@ -30,7 +86,8 @@ uil, mrm, xm, xmcxx, インクルードファイルや Imake ファイルといった開発者向けキット - スタティックライブラリ, およびダイナミックライブラリ + FreeBSD 2.2.8 以前のバージョンで利用できるスタティックライブラリ, + およびダイナミックライブラリ デモンストレーションプログラム @@ -38,7 +95,7 @@

注文する際には FreeBSD 用の Motif であることをきちんと - 確認してください. BSDI や Linux 用の Motif も Xi Graphics + 確認してください. BSDI や Linux 用の Motif もまた, Xi Graphics から販売されています. 現在フロッピーディスク 4枚組ですが, 将来的には CDE のように統合された CD に変わるでしょう. @@ -48,24 +105,48 @@

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 サーバってあるんですか? -

はい, +

はい, と + から, FreeBSD ほか Intel ベースのシステムで動作する Accelerated-X という製品が販売されています. +

この高性能な X サーバは楽に設定をおこなえるほか, 数多くのビデオボード +

Metro Link は, FreeBSD のパッケージ操作ツールを利用することで + 容易に設定が行なえるほか, 数多くのビデオボードをサポートした + 高機能な X サーバを提供しています. 配布はバイナリ形式のみで, + FTP が利用可能です. もちろん, とても安価($39)に手に入れることができます. +

また, Metro Link は ELF 版, a.out 版の FreeBSD 用 Motif + も販売しています(前を参照). + + + + + + または + 電子メールアドレス + + + +

Xi Graphics が提供している高性能な X サーバは楽に設定をおこなえるほか, + 数多くのビデオボード をサポートしています. サーバはバイナリのみが含まれます. FreeBSD 用と Linux 用の統合されたフロッピーディスクに入っています. + Xi Graphics は Laptop サポートに特化した高性能 X サーバも提供しています. -

バージョン 3.1 の「互換デモ」が無料で入手できます. +

バージョン 5.0 の「互換デモ」が無料で入手できます.

また Xi Graphics は FreeBSD 用の Motif と CDE も販売しています (前を参照). 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,6 +1,6 @@ - + - + まじめな FreeBSD ハッカーだけの話題 @@ -52,7 +52,7 @@

次に, CVS リポジトリ全体を手元においておく必要があります. これを入手するには - + が使用できますが, supfile で release の名称を cvs にして 他のタグや date フィールドを削除する必要があります: @@ -138,10 +138,12 @@ - インターネットアクセスに制限があっても current を追いかけられますか? -

はい, を使って +

はい, を + 使って ソースツリー全体のダウンロードを @@ -502,4 +504,81 @@ Cc: current@FreeBSD.ORG name="ELF リンカ"> に -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,6 +1,6 @@ - + - + ネットワーキング @@ -118,7 +118,7 @@ - @@ -153,7 +153,7 @@

まず のマニュアルと, のマニュアルと, を読んでみましょう. 次に, @@ -247,7 +247,7 @@ default 10.0.0.2 UGSc 0 0 tun0

の行をうっかり消してしまった可能性があります. この場合は, ハンドブックの - の項を読み直してください. @@ -273,7 +273,7 @@ default 10.0.0.2 UGSc 0 0 tun0

詳しい情報については, ハンドブックの - の項を参照してください. @@ -336,13 +336,93 @@ default 10.0.0.2 UGSc 0 0 tun0

詳しくはお使いのモデムのマニュアルをご覧ください. + + 接続が不規則にハングアップしてしまう + +

たくさんの人が, 原因不明のハングアップを経験しています. + 検証のために必要なのは, まずどちら側のリンクでそれが起こっているか, + ということです. + +

外部接続型モデムを利用しているなら, 単に 問題が回線のどちら側かにあることが分かったら, + つぎの二つの可能性が考えられるでしょう. + + + 回線の向こう側での反応がない + +

これに対処できることはほとんどありません. 大部分の 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 ではネゴシエーションを 自分からは起こさず, クライアントが起こすのを待っています. -

こうすると, 接続先がネゴジェーションを行う場合, デフォルトで +

こうすると, 接続先がネゴシエーションを行う場合, デフォルトで LQR の使用を受け入れるようになります. @@ -729,49 +809,65 @@ default 10.0.0.2 UGSc 0 0 tun0 理由やそのアドレス, 関連した変数の値なども調べる事ができるでしょう. - - 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の我々の側から対処できる最も簡単な方法は, tun インターフェイスの + IP アドレスを固定する事です. またそのかわりに, + 外に出ていくパケットを変更して, 発信元 IP アドレスをインターフェイスの IP + アドレスから, 交渉によって得られた IP アドレスに, + 適宜書きかえる事によっても対処できます. こ + これは, 基本的に および, ppp の もう1つの(最も確かな)方法は, 全てのbindされているsocketの - IPを変更するようにsystem callを実装する事です. もう 1 つの(おそらく最も信頼できる)方法は, bind された + 全てのソケットの IP アドレスを, + 異なるものに変更できるシステムコールを実装することです. + 3つ目の方法は, interfaceをIP number無しで立ち上げる事を許す - ことです. 外に出ていくpacketは最初のSIOCAIFADDR ioctlが終わるまで - は255.255.255.255というIP numberを与えられます. これによって - socketを完全にbindすることができます. 現在のところ, これらの方法のどれもまだ実装されていません. +

3 つ目の方法は, IP + アドレスを指定しないでインターフェイスを利用できるようにすることです. + 外に出ていくパケットは, 最初の SIOCAIFADDR ioctl の完了まで, + 255.255.255.255 という IP アドレス が与えられます. + これによって. ソケットは常に bind することができます. + 何故ほとんどのゲームが -alias スイッチ付きだと動かないんですか? @@ -1054,90 +1150,94 @@ default 10.0.0.2 UGSc 0 0 tun0 すべてのネットワークの操作に対して ``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%の - バンド幅までしか使えない事になります. +

1 つ目のルールセットでは, パケットあたりのオーバヘッドはおよそ + 2.703ms/packet, これはだいたい 1 つのルールあたり 2.7 マイクロ秒 + かかっていることになります. + したがって, このルールにおけるパケット処理時間の理論的な限界は, + 毎秒約 370 パケットです. + 10Mbps のイーサネットで 1500 バイト以下のパケットサイズを仮定すると, + バンド幅の利用効率は 55.5% が限界となることになります. -

2つ目のsetでは, それぞれのpacketはだいたい1.172msで処理されて - いますので1つのruleあたり1.2マイクロ秒となります. packetの - 処理時間の理論的な限界はだいたい1秒あたり853 packetとなりますので +

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 のようしてパケット数の統計を取ることで, + どのルールが最もよく使われているかを調べることができます. @@ -1147,7 +1247,7 @@ default 10.0.0.2 UGSc 0 0 tun0

FTP などのサービスのリクエストは, 'socket' パッケージを利用 してリダイレクトできます. 'socket' パッケージは ports の 'sysutils' カテゴリに含まれています. リダイレクトしたいサービ - ス(/etc/inet.confのコマンド行を socket を呼ぶように変 + ス(/etc/inet.confのコマンド行をソケットを呼ぶように変 更してください. 変更例: @@ -1157,4 +1257,35 @@ 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,6 +1,6 @@ - + - + トラブルシューティング @@ -28,18 +28,81 @@ 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 が認識されません. @@ -450,5 +513,33 @@ します. (訳注: 日本語が必要な場合は 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,6 +1,6 @@ - + - + 商用アプリケーション @@ -19,7 +19,63 @@ 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 に関する情報は から 手に入れることができます. @@ -30,7 +86,8 @@ uil, mrm, xm, xmcxx, インクルードファイルや Imake ファイルといった開発者向けキット - スタティックライブラリ, およびダイナミックライブラリ + FreeBSD 2.2.8 以前のバージョンで利用できるスタティックライブラリ, + およびダイナミックライブラリ デモンストレーションプログラム @@ -38,7 +95,7 @@

注文する際には FreeBSD 用の Motif であることをきちんと - 確認してください. BSDI や Linux 用の Motif も Xi Graphics + 確認してください. BSDI や Linux 用の Motif もまた, Xi Graphics から販売されています. 現在フロッピーディスク 4枚組ですが, 将来的には CDE のように統合された CD に変わるでしょう. @@ -48,24 +105,48 @@

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 サーバってあるんですか? -

はい, +

はい, と + から, FreeBSD ほか Intel ベースのシステムで動作する Accelerated-X という製品が販売されています. +

この高性能な X サーバは楽に設定をおこなえるほか, 数多くのビデオボード +

Metro Link は, FreeBSD のパッケージ操作ツールを利用することで + 容易に設定が行なえるほか, 数多くのビデオボードをサポートした + 高機能な X サーバを提供しています. 配布はバイナリ形式のみで, + FTP が利用可能です. もちろん, とても安価($39)に手に入れることができます. +

また, Metro Link は ELF 版, a.out 版の FreeBSD 用 Motif + も販売しています(前を参照). + + + + + + または + 電子メールアドレス + + + +

Xi Graphics が提供している高性能な X サーバは楽に設定をおこなえるほか, + 数多くのビデオボード をサポートしています. サーバはバイナリのみが含まれます. FreeBSD 用と Linux 用の統合されたフロッピーディスクに入っています. + Xi Graphics は Laptop サポートに特化した高性能 X サーバも提供しています. -

バージョン 3.1 の「互換デモ」が無料で入手できます. +

バージョン 5.0 の「互換デモ」が無料で入手できます.

また Xi Graphics は FreeBSD 用の Motif と CDE も販売しています (前を参照). 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,6 +1,6 @@ - + - + まじめな FreeBSD ハッカーだけの話題 @@ -52,7 +52,7 @@

次に, CVS リポジトリ全体を手元においておく必要があります. これを入手するには - + が使用できますが, supfile で release の名称を cvs にして 他のタグや date フィールドを削除する必要があります: @@ -138,10 +138,12 @@ - インターネットアクセスに制限があっても current を追いかけられますか? -

はい, を使って +

はい, を + 使って ソースツリー全体のダウンロードを @@ -502,4 +504,81 @@ Cc: current@FreeBSD.ORG name="ELF リンカ"> に -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,6 +1,6 @@ - + - + ネットワーキング @@ -118,7 +118,7 @@ - @@ -153,7 +153,7 @@

まず のマニュアルと, のマニュアルと, を読んでみましょう. 次に, @@ -247,7 +247,7 @@ default 10.0.0.2 UGSc 0 0 tun0

の行をうっかり消してしまった可能性があります. この場合は, ハンドブックの - の項を読み直してください. @@ -273,7 +273,7 @@ default 10.0.0.2 UGSc 0 0 tun0

詳しい情報については, ハンドブックの - の項を参照してください. @@ -336,13 +336,93 @@ default 10.0.0.2 UGSc 0 0 tun0

詳しくはお使いのモデムのマニュアルをご覧ください. + + 接続が不規則にハングアップしてしまう + +

たくさんの人が, 原因不明のハングアップを経験しています. + 検証のために必要なのは, まずどちら側のリンクでそれが起こっているか, + ということです. + +

外部接続型モデムを利用しているなら, 単に 問題が回線のどちら側かにあることが分かったら, + つぎの二つの可能性が考えられるでしょう. + + + 回線の向こう側での反応がない + +

これに対処できることはほとんどありません. 大部分の 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 ではネゴシエーションを 自分からは起こさず, クライアントが起こすのを待っています. -

こうすると, 接続先がネゴジェーションを行う場合, デフォルトで +

こうすると, 接続先がネゴシエーションを行う場合, デフォルトで LQR の使用を受け入れるようになります. @@ -729,49 +809,65 @@ default 10.0.0.2 UGSc 0 0 tun0 理由やそのアドレス, 関連した変数の値なども調べる事ができるでしょう. - - 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の我々の側から対処できる最も簡単な方法は, tun インターフェイスの + IP アドレスを固定する事です. またそのかわりに, + 外に出ていくパケットを変更して, 発信元 IP アドレスをインターフェイスの IP + アドレスから, 交渉によって得られた IP アドレスに, + 適宜書きかえる事によっても対処できます. こ + これは, 基本的に および, ppp の もう1つの(最も確かな)方法は, 全てのbindされているsocketの - IPを変更するようにsystem callを実装する事です. もう 1 つの(おそらく最も信頼できる)方法は, bind された + 全てのソケットの IP アドレスを, + 異なるものに変更できるシステムコールを実装することです. + 3つ目の方法は, interfaceをIP number無しで立ち上げる事を許す - ことです. 外に出ていくpacketは最初のSIOCAIFADDR ioctlが終わるまで - は255.255.255.255というIP numberを与えられます. これによって - socketを完全にbindすることができます. 現在のところ, これらの方法のどれもまだ実装されていません. +

3 つ目の方法は, IP + アドレスを指定しないでインターフェイスを利用できるようにすることです. + 外に出ていくパケットは, 最初の SIOCAIFADDR ioctl の完了まで, + 255.255.255.255 という IP アドレス が与えられます. + これによって. ソケットは常に bind することができます. + 何故ほとんどのゲームが -alias スイッチ付きだと動かないんですか? @@ -1054,90 +1150,94 @@ default 10.0.0.2 UGSc 0 0 tun0 すべてのネットワークの操作に対して ``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%の - バンド幅までしか使えない事になります. +

1 つ目のルールセットでは, パケットあたりのオーバヘッドはおよそ + 2.703ms/packet, これはだいたい 1 つのルールあたり 2.7 マイクロ秒 + かかっていることになります. + したがって, このルールにおけるパケット処理時間の理論的な限界は, + 毎秒約 370 パケットです. + 10Mbps のイーサネットで 1500 バイト以下のパケットサイズを仮定すると, + バンド幅の利用効率は 55.5% が限界となることになります. -

2つ目のsetでは, それぞれのpacketはだいたい1.172msで処理されて - いますので1つのruleあたり1.2マイクロ秒となります. packetの - 処理時間の理論的な限界はだいたい1秒あたり853 packetとなりますので +

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 のようしてパケット数の統計を取ることで, + どのルールが最もよく使われているかを調べることができます. @@ -1147,7 +1247,7 @@ default 10.0.0.2 UGSc 0 0 tun0

FTP などのサービスのリクエストは, 'socket' パッケージを利用 してリダイレクトできます. 'socket' パッケージは ports の 'sysutils' カテゴリに含まれています. リダイレクトしたいサービ - ス(/etc/inet.confのコマンド行を socket を呼ぶように変 + ス(/etc/inet.confのコマンド行をソケットを呼ぶように変 更してください. 変更例: @@ -1157,4 +1257,35 @@ 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,6 +1,6 @@ - + - + トラブルシューティング @@ -28,18 +28,81 @@ 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 が認識されません. @@ -450,5 +513,33 @@ します. (訳注: 日本語が必要な場合は 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" にまで増やしても解決しない場合は, + 計時処理の信頼性が保てない程の割り込みが, そのマシン上で起こっていることを + 意味します. +