から寄せられたものです.
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" にまで増やしても解決しない場合は,
計時処理の信頼性が保てない程の割り込みが, そのマシン上で起こっていることを
意味します.