そもそもIRQ-07は受け付けないように設定しているわけですが、なぜこんな割り込みが起きるのでしょうか?これは実はマスタPICの「不完全割り込み」というもので、要するにPICが「お、なんか割り込み来たな?」と回路が動き出したところで割り込み信号が途絶えてしまい、何番の割り込みだったのか記憶するのが間に合わず、分からなかったという状態です。PICの反応速度を越えた割り込み信号の急激な変化、と言うと分かりやすいでしょうか。こんなときでもPICはとりあえず割り込みがあったことをCPUに伝えようとします。そのときには、とりあえずそのPICが管理している最大の番号の割り込み番号を使うという仕様になっています。今回問題を起こしているのはマスタPICなので、それでIRQ-07が発生するんです。そんなへんてこな割り込み信号をマスタPICに送った犯人は誰でしょうか。実はスレーブPICです。この問題を引き起こすチップセット内のスレーブPICは、初期設定すると割り込み通知信号線に一瞬ノイズが載るようです。この線はまさにマスタPICのIRQ-02につながっているため、マスタは割り込みが来たと思ってしまい、しかしこれは一瞬のノイズでしかないのですぐ消えてしまいます。それでマスタPICは不完全割り込みを起こしてしまうのでしょう。(上級者向け追加コメント)ちなみにPICが不完全割り込みを起こすのはエッジトリガモードのときだけです。IBMの設計者がもうちょっとまともでTOWNSのようにレベルトリガモード前提でハードウェアを設計してくれていたら、こんなややこしいことに悩まされずに済んでいたものを・・・。(中略)}「説明しよう!」ひよひよさんの報告から考えてみると、どうやらAlthon64X2では、PICへの設定中はCLIにしておかないとまずいのではないかと推測される。いうことで、PICへの設定中はCLIにするようにしてみた。(asmhead.nasで、直後にCLIすることが分かっているのにあえて一度STIするのは、PIC設定中に受け付けた割り込みがもしあったら(まあ多分ないだろうけど)、それを32bitモードに入る前に処理させてあげるため。)結局これもイマイチ効果なし。(中略)「説明しよう!」どうやら一部のチップセットでは、キーボードデータが来る前に入力ポートを空読みするとチップセットが暴走するようだ。本来の8042では、空読みした場合、直前のデータが何度でも読み取れることになっていた。この仕様を一部のチップセット開発者が勝手に変更してしまったのだろう。結果は如何に?!効果ありのようだ。i810やi845などのインテル系チップセットでは、この対策をしないと無事に起動しないらしい。(中略)「説明しよう!」MonaOSでキーボードコントローラに謎の0xffを送信しているらしいので、真似してみた。(中略)「説明しよう!」どうもこれは効果がなかった。チップセットの反応が遅すぎたわけではなかった。(中略)「説明しよう!」どうやらキーボードコントローラはCPUに比べて動作が遅いらしく、A20GATE信号を設定してもすぐには反映されていなかったようだ。そのため、一部のCPUが高速な機種では(もしくはチップセットが遅い機種では)たとえばメモリの0x00123456番地を読み書きしても、0x00023456番地を読み書きしてしまうという問題が起きていたようだ。この番地の間違いが起きると、asmhead.nasでのmemcpyがうまくいかないことになる。0x00100000番地にあるはずのディスクデータがなかったり、もしくは0x0010c200番地に書いたつもりが実は0x0000c200番地に書いていた、なんてことになる。後者は深刻で、asmhead.binが0x0000c200番地以降にあるので、これを上書きしてしまうとまさに自殺になってしまい、謎のデータを実行することになってしまう。tanakaさんの報告でDSKCACの値を変えたら動いたというのは、まさにこれなんじゃないかと思う。それでこの修正を思いついたわけだ。・・・(少なくとも一部の機種においては)この予想が的中したみたいなのでよかった。他の機種ではハングアップ問題が発生。このパッチはどうも使えないようだ。↑こめんと欄ひよひよさんによる報告。さしたる根拠はないが、Kはダブルフォールト(やトリプルフォールト)が直接の原因ではないと思っている(間接的な原因である可能性はありうる)。17:37:11私の持っているパソコンのうちの1台で動作しなかったので報告させていただきます。82810と結構古いパソコンです。私の場合は、asmhead.nasのmemcpyを3回目に実行する時点でパソコンが再起動してしまいます。02:48:54qwertさんへ。情報ありがとうございます。GT4012j(Athlon64x2、nForce410)でもCDブートさせるとすぐにリセットがかかります。13:56:02ご報告ありがとうございます。17:10:37ほんをかったんですけど、動かなかったので本捨てちゃいました。家の殆どのPCで動かなかったと思います。03:49:06それはもったいない。捨てる前にここで聞いたらよかったですね。1.8G/asusP4B266/radeon8500)報告まで。13:00:22tanakaさんの情報が正しいと仮定すると、CPUの動作が速すぎてA20GATE信号線の切り替わりが間に合っていない可能性が考えられますね。今日中にテスト用の対策コードを準備しますので少しお待ちください。14:23:24とりあえず適当に作ってみました(バージョン1)。興味のある方は実機テストをどうぞ。)によると、この対策コードは効果があったそうです。これで他の機種でも問題が解決するかどうかは分かりませんが、とにかく一歩前進です!tanakaさん、ひよひよさん、ありがとうございました。適用して試したところ真っ暗画面のままでした。同じなので、どこで問題が発生しているかを見極める必要がありそうです。今日のところはおやすみなさい。00:11:26qwertさんのi810機でもこの修正で改善する可能性がありそうです。00:26:59実験してみたので報告します。ループを抜けられないようです。A20GATEに問題があるのかどうか私にはわかりませんが、メモリのアドレス指定に問題があるのは間違いないようです。23:16:14GT4012jで報告した者です。さんと同じようにharib27fにパッチを当ててみましたが、リセットする現象は直りませんでした。23:35:06私もパッチを当ててみましたが動かなくなりましたorz。メモリアドレス0x00100000付近に原因があるのではないかと推測。09:18:34手動バイナリサーチ結果報告です。0x00108000以上正常動作。結果から、メモリマップ以外の所にも何か入ってるみたいです。10:16:18みなさん実験と報告をありがとうございます。パッチを入れたら黒い画面のまま動かなくなる症状が多数報告されていますが、これはA20GATEの設定そのものに失敗しているせいではないかと思います。