--ホーム--
--Links--
|
Signal 11問題に関連したCPUのバグ
CPUのバグというのはいろいろあるわけですが，Signal 11問題に関連したもの
をいろいろまとめてみました．
Signal 11問題のメインに戻る
- Cyrix 486 SLC/DLC/SLC2/DLC2/SRx/DRx/SRx2/DRx2 CPU
- Cyrix 486DX CPU (違うかも知れない)
では，なぜか不思議なことに，ページフォールトの時にページフォールトを起
こしたアドレスが取得できないことがあります．ページフォールトを起こした
アドレスは，rcr2()で取得するのですが，何故かその値が0に
なってしまいます．本来なら，ページフォールトを起こしてからCR2レジスター
を読み出すまでは値が変化しないはずですが,ハードウェア割り込みによって
値が壊れてしまいます．PC-98ではCyrixの486 CPUを使用したCPUアクセラレー
タというものがよく売れていたために極めて重要な問題として取り扱う必要が
ありました．そこで，PC-98ではカーネルを再構築することにより，
- 例外14をトラップゲートから割り込みゲートにして割り込みを禁止する．
これによってCR2が破壊されるのを
防ぐ．
- trap()関数の先頭で，
- とにかく真っ先にCR2の内容を読み出す．
- ページフォールトでしかも割り込み禁止状態なら，割り込みを許可する．
という対策が取られます．割り込み禁止時間が長くなるのでパフォーマンスロ
ス(といっても無視できる程度だと思います)になりますが，Signal 11問題に
悩まされるよりはましだと思います．
Signal 11問題のメインに戻る
BTB，LOOP，IORT，RSTKにはバグがあります(BIOS Writers Guide参照)．
LOOP，RSTKはパフォーマンスを向上させますが，ほぼ確実にシステムをクラッ
シュさせます．BTBもパフォーマンスを向上させますが,システムを密かにクラッ
シュさせます(発見しにくい)．また，IORTはデフォールトの値ではなく,0にし
てディレイタイムを0にしないとよくわからないうちにシステムをクラッシュ
します．これらのオプションは，Signal 11問題の原因にもなりますが，ディ
スククラッシュなども引き起こします．Cyrix 5x86 CPUのバグによりおかしな
ことが起こった例は，カーネルデバッグの実
例(その1)にあります．
Cyrix 5x86 CPUなら，write backキャッシュとDTEによってかなりのパフォー
マンス向上が得られるので危険な機能を使用しない方が良いと思います．
誤解がないように付け加えておきますが，Cyrix 5x86 CPUは，486ピンアウト
の中では私が一番気に入っているCPUです．バグバグな機能を使わないように
すればなかなかのものだと思います．しかし，すでに現行商品ではないのが残
念です．
Signal 11問題のメインに戻る
バグといえるかどうかわかりませんが，初期のCyrix 6x86 CPUは，内部キャッ
シュをwrite backモードにするとシステムが不安定になるという問題がありま
す．これについて，Windows NTやFreeBSD-currentおよびRELENG_2_2ブランチ
では，CPUのリビジョン番号が2.7未満の時はL1キャッシュをwrite throughモー
ドに設定し直します．ただし，カーネルの再構築でwrite backモードにするこ
とは可能です．
未確認情報ですが，実はリビジョン2.5でCPUの設計が大きく変わっているが
2.7では変わっていないという情報があります．これが何を意味するかいまの
ところわかりません．
Signal 11問題のメインに戻る
Stepping Bのバグでシステムを不安定にするもの
- Higher strength drive
- Higher strength driveにしていると，信号波形が乱れる．
- REP MOVS命令
-
- アドレスサイズオーバーライドプレフィックスを使用している．
- ECXを6にして命令を実行しはじめる．
- CPUがECXが0かどうか検査している時に割り込みが発生する．
- REP MOVSに続く命令がキャッシュに入っている．
- 実行アドレスサイズまたはセグメントレジスタがREP MOVSのものと異なっている．
- 普段の行いが悪い．
などの条件が重なった時．
- Re-execution of Instruction Due to Self-Modifying Code
- 32MBを越えるRAMを搭載しているマシンで，システムが不安定になります．
Signal 11問題のメインに戻る
|
