JP4077815B2 - 発明者ＪｏｈｎＷ．Ｃｕｒｒｙによる、オペレーティングシステムと共に使用される改良された診断モニタおよびその方法 - Google Patents

Description

［関連出願］
本出願は、本発明の譲受人に譲渡された同時係属中の、発明者John W. Curryによって２００３年２月２７日に出願された「IMPROVED DIAGNOSTIC EXERCISER AND METHODS THREFOR」と題する、米国特許出願第１０／３７６，４３６号に対し米国特許法第１２０条に基づく優先権を主張する。

［発明の背景］
コンピュータおよびオペレーティングシステムが複雑になるにつれて、障害および性能の分析はより難しくなってきている。
信頼性の理由から、コンピュータシステムは、使用に供する前に徹底的に試験することが非常に望ましい。
一般的に言うと、コンピュータシステムのハードウェアの特定の部分を試験するコードを作成することは可能である。
しかしながら、このような狭い部分に集中した試験は、概してコンピュータシステム全体に全体的にストレスを加えておらず、コンピュータシステムが現場で使用される傾向にある態様を反映していない。

別の手法は、診断実行装置（diagnostic exerciser）等、オペレーティングシステムの下で実行されてエラーを検出する診断ツールの使用を伴うものである。今日、診断実行装置は、通常、例えばＬｉｎｕｘ、ＨＰＵＸ（商標）（カリフォルニア州パロアルト所在、Hewlett-Packard Company）、またはＷｉｎｄｏｗｓ（ワシントン州レドモンド所在、Microsoft Corporation）等の製品オペレーティングシステム（ＯＳ）の下で実行するように設計される。
製品ＯＳの下で実行される診断実行装置は、特別なドライバおよび／またはオペレーティングシステム呼び出しを使用する専用に設計されたアプリケーションを使用することにより、特定の方法でコンピュータシステムにストレスを加えることができ、一定のエラーが発生したときにそれらを検出することができる。
これらの診断実行装置はＯＳを使用するので、それら診断実行装置のアプリケーションは、より十分に、かつ、例えば、マルチスレッド、高速ディスクＩ／Ｏオペレーション等の機能を伴うコンピュータシステムの現場での使用態様により類似した方法で、ハードウェアにストレスを加えることができる。

一般に、コンピュータシステムが受けるストレスの量は、診断実行装置のどのアプリケーションが実行されているかに応じて変化する可能性がある。
しかしながら、所与の診断実行装置が、製品オペレーティングシステムの下で実行されると、このような診断実行装置の能力は、そのオペレーティングシステムによって制約を受ける。
例えば、製品オペレーティングシステムは、競争に勝つために、現場の性能を得るように最適化される傾向があり、広範な診断能力を得るようには最適化されない傾向がある。

したがって、このような製品ＯＳの下で実行される診断実行装置は、その診断能力が制約される傾向がある。
同様に、データ収集、エラー検出、およびエラー分析に役立つ他の機能を設けると、ＯＳの性能が極度に阻害され、かつ／または、現場のコンピュータシステムのセキュリティが危険にさらされることになることから、このような機能は、製品ＯＳでは利用可能でないことがある。

さらに、製品ＯＳの下で実行されるほとんどの診断実行装置は、特権プロセスおよび／または特権ドライバとして実行される傾向がある。
このことによって、カーネルクラッシュの状況では、診断実行装置の有用性が制限される傾向がある。
例えば、カーネルのブート中にカーネルがクラッシュすると、従来技術の診断実行装置の一般的な診断モニタは、起動されなくなってしまい、それによって、カーネルのブート障害の検出および分析にほとんど意味がなくなる。

その上、カーネルがクラッシュした場合のほとんどの一般的な診断技法には、カーネルダンプの取得およびカーネルダンプデータの分析が含まれる。
しかしながら、このような診断技法は、カーネルダンプファイルに保存された情報によって本質的に制限される。
カーネルダンププログラムを最初に設計したプログラマが、一定の情報を保存しないようにしていた場合、このような情報は、カーネルダンプファイルにおいて分析用に利用できないことになる。
さらに、カーネルダンプファイルで利用可能な情報の内容およびフォーマットは、カーネルダンプを最初に設計したプログラマの裁量に応じて変わる場合がある。
したがって、カーネルダンプ情報を解読することは困難となることがあり、カーネルを最初に設計したプログラマを探し出して、カーネルダンプファイルの分析を援助してもらうことが必要になることがある。
ＯＳが制作された時期と、特定のエラーが発生し、その結果、カーネルダンプが行われた時期との間に長い時間が経過している場合、そのプログラマは、もはや援助に役立たないおそれがあり、カーネルダンプデータを精密に調査するには、おそらくカーネルのエキスパートを使用する必要がある。

［発明の概要］
本発明は、一実施の形態では、コンピュータシステムが製品オペレーティングシステム（ＯＳ）を使用してユーザアプリケーションを実行する際に、コンピュータシステムを監視する、コンピュータ実施される方法に関する。
このＯＳは、カーネルトラップ処理を備えたＯＳカーネルを有する。
この方法は、診断モニタを設けることであって、たとえＯＳカーネルが実行できない場合であっても実行することができるように構成され、かつ、モニタトラップテーブルを有する、診断モニタを設けることを含む。
ユーザアプリケーションの実行中にトラップが発生した場合に、この方法は、当前記トラップがＯＳカーネルによってハンドリングされるべきか、または診断モニタによってハンドリングされるべきかを、診断モニタを使用して確認することを含む。
トラップがＯＳカーネルによってハンドリングされるべきである場合に、この方法は、トラップをＯＳカーネルに渡すことであって、それによって、ハンドリングさせる、トラップをＯＳカーネルに渡すことを含む。

別の実施の形態では、本発明は、コンピュータシステムにおいて、ユーザアプリケーションプログラムを実行している間にコンピュータシステムを診断する装置に関する。

このユーザアプリケーションプログラムは、製品オペレーティングシステム（ＯＳ）カーネルの下で実行される。
この装置は、このＯＳカーネルと協働的に実行するように構成された診断モニタを含む。
このＯＳカーネルは、アプリケーションプログラムの実行中に生成されるトラップタイプのメッセージおよびインターラプトタイプのメッセージの少なくとも一方をハンドリングするカーネルトラップ処理を有する。
診断モニタは、たとえＯＳカーネルが実行できない場合であっても実行し続けることができる。
診断モニタは、トラップタイプのメッセージおよびインターラプトタイプのメッセージの少なくとも一方をハンドリングするモニタトラップテーブルを含む。
診断モニタは、アプリケーションプログラムの実行中に生成されるトラップを受け取るように構成され、かつ、受け取った所与のトラップについて、ＯＳカーネルがその受け取ったトラップをハンドリングするのか、または診断モニタがその受け取ったトラップをハンドリングするのかを決定するように構成される。

さらに別の実施の形態では、本発明は、コンピュータ可読コードが具現化されるプログラム記憶媒体を含んだ製品に関する。
このコンピュータ可読コードは、コンピュータシステムのエラーをハンドリングするように構成される。
この製品は、診断モニタを実施するコンピュータ可読コードを含む。
この診断モニタは、コンピュータシステムの製品オペレーティングシステム（ＯＳ）カーネルと協働して実行するように構成され、かつ、たとえＯＳカーネルが実行できない場合であっても、実行できるように構成される。
診断モニタは、コンピュータシステムで生成されるトラップを受け取るように構成されたモニタトラップテーブルを含む。
ＯＳカーネルは、診断モニタから渡されたトラップをハンドリングするように構成されたカーネルトラップ処理を有する。
この製品は、システムの起動時に、ＯＳカーネルのロード前に、診断モニタをロードするコンピュータ可読コードを含む。

本発明のこれらの特徴および他の特徴については、以下の本発明の詳細な説明において、図面と共に詳述する。

本発明を、添付図面の図に、限定としてではなく一例として図示する。
添付図面において、同じ参照符号は、同様の要素を表す。

［好ましい実施の形態の詳細な説明］
次に、添付図面に図示するような本発明のいくつかの好ましい実施の形態を参照して、本発明を詳細に説明する。
以下の説明では、本発明の実施の形態の十分な理解を提供するために、多数の具体的な詳細について説明する。
しかしながら、本発明は、これらの具体的な詳細の一部またはすべてがなくても実施可能であることが当業者には明らかであろう。
それ以外の場合には、本発明を不必要に分かりにくくしないように、既知のプロセスのステップおよび／または既知の構造は、詳細に説明されていない。

本発明の一実施の形態によると、純粋なオフラインの診断手法によって提供される利点と、オンラインのＯＳベースの診断手法によって提供される利点とを組み合わせた診断装置および診断技法が提供される。
純粋なオフラインの診断手法によって提供される利点としては、例えば、コンピュータハードウェアへの広範なアクセスおよびコンピュータハードウェアの広範な制御と、エラー検出およびエラー分析の容易さとが挙げられる。
オンラインのＯＳベースの診断手法によって提供される利点としては、例えば、より十分に、かつ、コンピュータハードウェアが現場で受けるストレスをより良く表現する方法で、ハードウェアにストレスを加えることができることが挙げられる。

オフラインおよびオンラインという用語が本明細書で使用されるが、診断ツールがその診断タスクに製品ＯＳを使用しない場合に、その診断ツールは、オフラインであると言われる。
オフライン診断ツールは、個々のハードウェアサブシステムへの広範なアクセスおよび／またはその制御を行うことができるが、それらの診断手法は、局所化された刺激応答に基づく傾向がある。

オフライン診断ツールに基づく刺激応答試験は、一定の一時的エラーを効率的に検出するのに適していないことが知られている。

さらに、オフライン診断ツールは、コンピュータシステムのハードウェアに、包括的な方法でストレスを加えず、また、コンピュータハードウェアが現場で受けるストレスを表すようにコンピュータシステムのハードウェアにストレスを加えない。
したがって、被試験サブシステムが現場で受ける可能性のあるシナリオのほとんどを、実行された試験が確実にカバーするには、多数の刺激（およびその刺激の多数の並べ替え）を使用することが必要とされている。

プラスの面として、オフライン診断ツールは、ＯＳに仲介としての役割をさせることなく、刺激応答試験に基づいて、コンピュータシステムのハードウェアの個々のサブシステムを試験する傾向があるので、ハードウェアの機能への広範なアクセスおよびハードウェアの機能の広範な制御が可能であり、エラーの分離および分析の複雑さが少なくなる傾向がある。

これと対照的に、診断ツールは、その診断タスクに製品ＯＳを使用する場合に、オンラインであると言われる。
診断アプリケーションがＯＳの下で実行される場合、ハードウェアの制御は、直接的な形式で行われることは少なくなり、ハードウェアへのアクセスは、はるかに多く制約される。
しかしながら、オンライン診断アプリケーションは、マルチスレッド、高速Ｉ／Ｏアクセス等のＯＳに関連した機能を使用して、概してコンピュータシステム全体に、より十分なストレスを加えることができる。
オンライン診断アプリケーションは、ＯＳの下で実行されるので、コンピュータシステムは、コンピュータハードウェアが現場で受けるストレスにより類似した方法でストレスを受ける傾向がある。

さらに、オンライン診断ツールでは、可能性のある使用のシナリオおよび／または現実的な使用のシナリオへ試験をより近づけることができ、オフライン診断実行装置の場合のように、さまざまな並べ替えをランダムに試験することが行われないので、試験に要する時間を短くすることができる。
なお、オフライン診断実行装置で行われる並べ替えのいくつかは、非現実的なものとなることがあり、かつ／または、コンピュータシステムが現場で決して受けないものとなることがある。

しかしながら、オンライン診断ツールは、能力が追加された代償として、柔軟性がなく、複雑になっている。
既存のＯＳベースの診断ツールは、製品ＯＳ（すなわち現場で使用されるＯＳ）の下で実行される傾向があるので、セキュリティおよび性能への配慮から、既存のＯＳベースの診断ツールの診断能力および／または分析能力が厳しく制限される。
ＯＳおよび／またはＯＳカーネルの設計に応じて、一定のタイプの情報は、エラー検出および／またはエラー分析用に、取り込みおよび／またはアクセスができないことがある。
ハードウェアへのアクセスおよび／またはハードウェアの制御は、きびしく制限されることがある。
たとえ情報が取り込まれる場合であっても、カーネルダンプ等の情報は、分析してエラー源を確認するのが困難な場合がある。
また、ＯＳベースの診断ツールは、エラー源を簡単な方法で分離することも困難となる傾向がある。

先に述べたように、本発明の診断実行装置の実施の形態は、純粋なオフラインの診断手法によって提供される利点と、オンラインのＯＳベースの診断手法によって提供される利点とを組み合わせている。
ハードウェアシステムを十分に働かせて、コンピュータシステムが現場で使用されるやり方をより良く表す試験を使用してコンピュータシステムのより統制された試験を行うために、診断実行装置は、ＯＳを使用する。
しかしながら、使用されるＯＳは、診断カーネルに基づく非製品ＯＳである。
非製品ＯＳ、より具体的には、診断能力を向上させるように変更された非製品カーネルを使用することにより、本発明は、有利なことに、製品ＯＳの制限を回避することができる。
なお、この制限は、例えばセキュリティおよび／または性能の理由に基づいて課されるものである。
診断試験が、制御された非製品環境で実行されるので、現場で配慮されるセキュリティおよび性能の重要性は低くなる。

さらに、診断モニタは、非製品カーネルと協働的に監視を行い、かつ、動作するように設けられる。
この協働的という用語が本明細書で使用されるが、診断モニタは、非製品カーネルの下で動作しないので、非製品カーネルと協働的に実行されると言われる。
本発明の一定の実施の形態によると、理解しやすいように障害分析を提供するルールベースの機構（facilities）が提供される。
本発明の技法を使用すると、ブート中または診断アプリケーションプログラムの実行中にカーネルがクラッシュしたとしても、障害分析が容易になる。

好ましい実施の形態では、カーネルについての詳細な情報（すなわちデータ構造体、カーネルデータの位置等）を有する診断モニタが、ＯＳが使用しないメモリ領域にロードされる。
この診断モニタは、カーネルのロードおよびブートの前にロードされ、トラップベクタテーブルを制御する。
カーネルのブート中、または、カーネル（すなわちＯＳ）の実行中、発生するあらゆるトラップまたはインターラプトが、診断モニタによって検査されて、それらのトラップまたはインターラプトをどのようにハンドリングすべきかが判断されることになる。

詳しく述べると、現代のコンピュータアーキテクチャのトラップ／インターラプトメカニズムでは、一定の状況が発生すると、特権コードを実行することが可能になる。
特定のアーキテクチャに応じて、これらの状況には、一定のハードウェアイベントおよびいくつかのソフトウェア生成イベントが含まれる。
このトラップ／インターラプトベースのメカニズムは、本発明の診断モニタによって利用されて、エラー検出を容易にすることに加えて、一定のエラーに関するデータ収集およびデータ分析を容易にする。

一般に、エラーでないすべてのトラップは、診断モニタによって通常のカーネルベクタテーブルに渡されることになる。
そうでない場合には、診断モニタは、メモリのカーネルデータ構造体から収集できるあらゆる情報と共に、トラップ情報を検査し、この情報を使用してエラーを分離することになる。
カーネルパニックは、強制的なトラップを診断モニタに引き起こすことがある。
多くのアーキテクチャでは、タイムスライスイベントであるプロセスが、エラーでないトラップを引き起こすことがある。
これらのトラップは、診断モニタによって使用されて、ランタイムにおけるハードウェアパラメータおよびカーネルパラメータの「監視」が可能になる。
例えば、ＣＰＵがタイムスライストラップを有する場合に、診断モニタは、そのＣＰＵ上で実行されているプロセスに関連したプロセスデータ構造体を検査することにより、そのＣＰＵがアイドルであったかどうかを判断することができる。
ＣＰＵがアイドルである場合には、診断モニタは、ＣＰＵを使用してエラーをチェックすることができる。

チェックが完了すると、ＣＰＵは、そのアイドルループに戻ることになる。
このように、診断モニタは、カーネルに対する自身の動作の影響を小さくすることができる。

一般的なほとんどのオペレーティングシステムでは、セマフォは、時限付きにはなっていない。
すなわち、カーネルスレッドが或るセマフォを捕らえようと試みると、そのカーネルスレッドは、そのセマフォを獲得するまで、時間に制限なく捕らえようと試みることになる。
しかしながら、カーネルのセマフォルーチンが、或る時間の経過後、タイムアウトしてトラップを強制するように変更されると、診断モニタを使用して分析を行うことができる。

本発明の一実施の形態によると、ローダプログラム（ローダ）が最初に実行される。
次いで、このローダは、ブートデバイス（ディスク等）から診断モニタを探し出して、その診断モニタを起動する。
診断モニタは、初期化を行い、自身が実行されているコンピュータのモデルが何であるかを判断しようと試みる。
一般に、所与の診断モニタは、特定のマシンアーキテクチャ向けにコンパイルされている。
次いで、診断モニタは、自身が実行されているコンピュータのモデルに適したライブラリモジュールをロードするようにローダに要求する。
このライブラリは、さまざまなハードウェアエラーの検出ルーチンおよび分離ルーチン等、監視されるコンピュータについてのモデル固有の情報を有する。

さらに、ライブラリは、実行されるオペレーティングシステムについての詳細な情報も有する。

診断モニタは、一般に、ＯＳがロードされることになるプロセスデータ構造体のレイアウト等、ＯＳのさまざまな詳細を知る必要がある。
また、カーネルのシンボルテーブルもロードされて、診断モニタによって使用され、その結果、診断モニタは、固定されたカーネルデータ構造体の位置を知る。
ほとんどのランタイムカーネル構造体の位置は、一定の固定された構造体の位置を知ることにより推定することができる。
あらゆる例外について、カーネルは、それらの位置を、ＯＳの初期化中または構造体作成時に診断モニタに渡すことができる。
加えて、診断モニタは、自身のトラップベクタテーブルも、使用されるものとしてインストールする。
次いで、診断モニタは、ローダに制御を返す。

本発明の詳細および利点は、以下の図面および説明を参照することにより、より良く理解できる。
図１は、診断を受けるコンピュータハードウェア１０２と診断実行装置１０４とを含む診断環境を、本発明の一実施の形態に従って示している。

診断実行装置１０４は、ローダモジュール１０５を含む。
このローダモジュール１０５は、システム起動時に、診断実行装置１０４の主要なコンポーネントをメモリにロードする役割を有する。
これらの主要なコンポーネントは、以下で説明する。

診断実行装置１０４は、診断カーネル１０６を含む。
この診断カーネル１０６は、診断目的で使用される非製品ＯＳ（例えば、非製品Ｗｉｎｄｏｗｓ（商標）または非製品Ｌｉｎｕｘ ＯＳ）のカーネルを表す。
複数のドライバ１０７ａ、１０７ｂ、１０７ｃが診断カーネル１０６と共に設けられる。
これらのドライバは、診断実行装置１０４がＩ／Ｏデバイスに関する情報を取得できるようにするために設けられたドライバのいくつかを表す。

したがって、Ｉ／Ｏデバイスが故障した場合、関連するドライバ上で計測を実行して、カード／デバイス電子機器から情報を収集することができ、それによって、診断実行装置１０４は、そのエラーを分析することが可能になる。

一般的に言うと、コンピュータハードウェア１０２が現場で受けるストレスを表すようにコンピュータハードウェア１０２にストレスを加えることを可能にするために、診断カーネル１０６と製品ＯＳのカーネルとの間の変更点は、最小限に維持することが好ましい。
しかしながら、診断モニタ（後述）が、カーネル１０６を監視する機能、エラー検出機能、およびエラー分析機能を実行できるようにするには、一定の変更が必要とされる。
一実施の形態では、カーネル１０６は、診断モニタおよびドライバの初期化を可能にし、診断アプリケーションの実行中に診断モニタと通信することを容易にし、かつ、追加された診断能力（プロセッサ親和性、物理メモリの割り当て等）を提供するように変更される。
製品カーネルに対する他の可能な変更点については、以下にさらに説明する。

また、診断実行装置１０４は、診断モニタ１０８も含む。
この診断モニタ１０８は、エラーの検出および分析に必要とされる監視ソフトウェアを表す。
診断モニタ１０８は、カーネル１０６と通信し、カーネル１０６を監視するように設計される。
一実施の形態では、モニタ１０８およびカーネル１０６は、個別のバイナリファイルとして提供される。
それによって、モニタ１０８は、ＯＳから独立したものとなる（すなわち、モニタ１０８は、カーネル１０６の下で実行されるのではなく、カーネル１０６と共に実行される）。
モニタ１０８は、好ましくは、カーネル１０６が使用しないメモリ位置にロードされて、カーネル１０６が、意図しない改変をモニタ１０８に行うことを回避する。
カーネル１０６にエラーが発生すると、モニタ１０８は、そのエラーの分析を試み、かつ、その問題を、ＦＲＵ（フィールド交換可能ユニット（field replaceable unit））、または、違反の可能性のあるＦＲＵ（potential offending FRU）のリストへ分離することを試みる。
この意味で、本発明の診断実行装置は、通常はオフライン診断ツールに関連した木目の細かさを有するエラー分離を提供する。

図１に示すように、診断モニタ１０８は、モニタロジック１１０、モニタライブラリ１１２、およびモニタトラップテーブル１１４の３つのメインモジュールを含む。
モニタロジック１１０は、アーキテクチャ（例えば、ＰＡＲＩＳＣ（商標）、Ｉｔａｎｉｕｍ（商標）等）に依存する。
コンピュータハードウェア１０２の特定のアーキテクチャおよびボックス（box）のタイプ（これらに関する情報はリンク１１６を介して取得できる）に応じて、適切なモニタライブラリ１１２がロードされる。
このように、一実施の形態では、モニタライブラリ１１２は、特定アーキテクチャ向けおよび特定ボックス向けの双方のものである。

モニタトラップテーブル１１４は、診断アプリケーションの実行中に管理されるトラップテーブルを表す。
本明細書で後に説明するように、診断モニタ１０８の主要な機能の１つは、トラップハンドラを制御することである。
カーネル１０６が遭遇するどのトラップも、モニタ１０８によって検査される。
モニタ１０８は、そのトラップを自身でハンドリングするのか、またはそのトラップをカーネルに渡してハンドリングさせるのかを決定することになる。

また、カーネルも、トラップテーブルを有するが、カーネルのトラップテーブルは、特定のトラップをカーネルにハンドリングしてほしいと診断モニタ１０８が決定した場合にのみ、制御が許可される。
このような場合、制御は、カーネルのトラップテーブルにおける、トラップをハンドリングするのに適切なオフセットに渡る。
このように、カーネルが関与している限り、カーネル自身のトラップテーブルは、カーネルがハンドリングする必要があるトラップをトランスペアレントな形式で得る。
それ以外のトラップは、モニタトラップテーブル１１４によって保持され、ハンドリングされる。

アプリケーション１３０、１３２、１３４、および１３６は、カーネル１０６の下で実行できるいくつかの診断アプリケーションを表し、コンピュータハードウェア１０２の特定の部分にストレスを加える。
例えば、ＣＰＵアプリケーション１３０は、ＣＰＵの試験に重点を置くように設計され、メモリアプリケーション１３２は、メモリの試験に重点を置くように設計され、Ｉ／Ｏアプリケーション１３４は、Ｉ／Ｏサブシステムの試験に重点を置くように設計される。
コンピュータハードウェア１０２の他のサブシステムおよび／もしくは他の態様ならびに／またはＯＳを試験するために、他のアプリケーションが提供されてもよい。
これらの他のアプリケーションは、図１では、アプリケーション１３６によって総括して表されている。

図２は、診断モニタ１０８を、本発明の一実施の形態に従ってより詳細に示している。
図から分かるように、モニタロジック１１０は、コアモニタコード２１４に加えて、アーキテクチャルーチン２１０およびルールエンジン２１２を含む。
アーキテクチャルーチン２１０およびルールエンジン２１２は、説明を容易にするために、図２では、モニタロジック１１０とは別に示しているが、実際は、モニタロジック１１０の一部となっている。
アーキテクチャルーチン２１０は、所与のアーキテクチャレベルに基づいて標準的なタスクを実行できるルーチンを表す。
例えば、すべての汎用レジスタの内容を保存することが必要となる場合がある。
これは、アーキテクチャルーチンによって行われることになる。
汎用レジスタのサイズおよび個数は、検討対象の特定のアーキテクチャに依存する（例えば、ＰＡＲＩＳＣ ２．０は６４ビット幅のレジスタを有し、一方、ＰＡＲＩＳＣ １．０は３２ビット幅のレジスタを有する）。
一実施の形態では、コアモニタは、アーキテクチャに依存するが、さまざまなモニタライブラリが、さまざまなボックスを収容するように提供され、それによって、所与のアーキテクチャに関するすべてのボックスに対してコアモニタを使用することが可能になる。

モニタトラップテーブル１１４は、実行中に機能的なトラップハンドラとなるように設計される。
したがって、カーネル１０６（図１参照）によるあらゆるトラップ／インターラプトは、予期されるか否かを問わず、カーネル１０６を診断モニタ１０８に強制的に移行させることになる。
この機能により、診断モニタ１０８は、あらゆるエラートラップに直ちに気付くことが可能になり、その時点で、診断モニタ１０８は、他のすべてのプロセッサを停止でき、あらゆる状態情報を収集することができる。
エラーでないトラップの場合、例えば、診断モニタ１０８は、一定の統計値（もし必要ならば）を収集でき、次いで、トラップの基本的な機能を続行して、最終的にはカーネルに戻ることができる。

診断モニタ１０８がどのルーチンを実行すべきかをカーネル１０６が（エラーでないトラップに対して）指定できるように、診断モニタ１０８のトラップハンドラが編成される。

この指定は、カーネルの初期化中において、診断モニタ１０８が存在することをカーネルが知ると直ちに行われるべきである。
それ以外の場合には、カーネルは、自身のデフォルトトラップハンドラを使用することができる。

一定のエラートラップは、特別な方法でハンドリングすることが必要となる場合がある。
例えば、深刻なハードウェアエラー、重大なソフトウェアエラー、およびハードウェアリセットの場合、ハードウェアは、ファームウェアルーチンに自動的に分岐することができる。
ＰＡＲＩＳＣ（商標）マシンに関して、例えば、ＨＰＭＣ（高優先度マシンチェック（High Priority Machine Check））、ＬＰＭＣ（低優先度マシンチェック（Low Priority Machine Check））およびＴＯＣ（制御の転送（Transfer of Controls））が、ハードウェアをファームウェアルーチンに自動的に分岐させることができる。
次に、このファームウェアは、プロセッサのレジスタの状態を保存して、あらゆるエラー状況をクリアすることができる。
診断モニタ１０８の適切なトラップハンドラルーチンが、適切にセットアップされている場合には、ファームウェアルーチンは、診断モニタ１０８のハンドラに分岐することができる。
この時点で、診断モニタ１０８は、次の分析を開始することができる。

モニタロジック１１０のルールエンジン２１２は、或るエラー状況のＦＲＵを探し出す方法を決定するためにモニタライブラリ１１２に問い合わせを行う１組のルーチンを含む。
ルールエンジン２１２は、ルール２２０（後述）を解釈するために使用され、エラー分析にどのルールが使用されるか、また、エラー分析はいつ完了したか等の機能を含むこともできる。
所与のアーキテクチャの「ボックス」のタイプごとに１つのライブラリが存在してもよい。
このライブラリは、何が故障しているのかを解明するために、収集データを分析できるルール機能を（特に）含むことができる。
それらのルールへのインターフェースは、さまざまなアーキテクチャ間で同じにすることができる。

モニタライブラリ１１２は、コアライブラリコード２２４に加えて、ルール２２０および特定ハードウェア向けルーチン２２２を含む。
ルール２２０は、検討対象のアーキテクチャに特有のルールを表し、エラー分析に使用される。
ルール２２０は、さまざまなエラー状況の推論を有し、エラーを、障害のあるＦＲＵに変換することができる。
特定ハードウェア向けルーチン２２２は、特定のボックスに特有のルーチンを含み、例えば、必要なあらゆる情報をその特定のボックスから収集することを容易にする。

コンピュータシステムの初期化時に、ローダモジュール１０５は、特定のシーケンスで診断実行装置１０４のコンポーネントをロードする。
図３は、初期化時のロードシーケンスを、本発明の一実施の形態に従って示している。
ブロック３０２において、ローダは、診断モニタ（診断モニタ１０８の２値画像等）がブートデバイス上に存在するかどうかを確認する。
ブートデバイスとしては、例えば、ハードディスク、ＣＤＲＯＭ、さらにはネットワークにおける特定の記憶位置がある。
診断モニタがブートデバイス上に存在しない場合には、ローダは、ブロック３０４において、カーネル（カーネル１０６等）がブートデバイス上に存在するかどうかを確認する。
カーネルがブートデバイス上に存在しない場合には、ロードプロセスは、ブロック３０６において、失敗したことを表示する。

他方、カーネルがブートデバイス上に存在する場合には（ブロック３０４において確認）、ブロック３０８において、そのカーネルがロードされ、そのカーネルに制御が渡される。
この場合、モニタは存在せず（先のブロック３０２で判断）、したがって、ブロック３１０において、カーネルは、診断モニタが存在しないことを確認する。
この診断モニタの存在のチェックは、製品ＯＳに対して行われた変更の一部であることに留意されたい。
カーネルは、診断モニタが存在しない状態では、管理するカーネルのトラップテーブルを用いて通常どおり実行される。

診断モニタがブートデバイス上に存在する場合には（ブロック３０２で確認）、ブロック３３０において、ローダは、診断モニタ１０８のモニタロジック１１０をメモリにロードする。
その後、ブロック３３２において、モニタロジック１１０は、初期化され、例えば、関連するアーキテクチャルーチン（図２のアーキテクチャルーチン２１０等）を使用して試験されるハードウェアのボックス情報を確認する。
次いで、このボックス情報は、ローダに渡され、それによって、ローダは、ブロック３３４において、必要なモニタライブラリがブートデバイスまたは別のデバイスに存在するかどうかを確認することができる。
必要なモニタライブラリが存在しない場合には、モニタをロードするプロセスは、失敗に終わる。
その場合、この方法は、ブロック３０４に戻って、カーネルのロードを開始する。
すなわち、その時点からの状況は、あたかもモニタがブートデバイス上に存在しなかったように取り扱われる。

他方、必要なモニタライブラリが発見された場合には（ブロック３３４で確認）、その必要なモニタライブラリが、ブロック３３６においてロードされる。
必要なモニタライブラリがロードされ、（例えば動的リンク技術を使用して）モニタロジック１１０との通信に同期した後、制御はローダに戻される。
次いで、ローダは、ブロック３３８において、カーネルがブートデバイス上に存在するかどうかを確認する。

この時点で、診断モニタは、すでにロードされ、初期化されていることに留意されたい。

したがって、カーネルが発見されない場合（ブロック３３８）、または、カーネルがブートできない場合、もしくは、別の問題がカーネルに存在する場合に、診断モニタは、そのエラーの検出、分析、および報告を検出することができる。
これは、製品ＯＳの下で実行される既存の診断ツールによる状況と異なる。
既存の診断ツールが製品ＯＳの下で実行される場合には、ＯＳがロードされないと、診断ツールは、初期化されていないことになり、したがって、そのエラーの検出、分析、および／または報告が意味のないものになる。

カーネルが発見できないと、ＯＳの下でアプリケーションが実行できないので、カーネルが、ブロック３３８において発見されない場合には、ロードプロセスは、ブロック３０６において失敗したことを報告する。
他方、カーネルが発見されると、カーネルシンボルテーブルが、ブロック３４０においてロードされる。
一般的に言うと、このシンボルテーブルは、カーネルの重要な要素（データ構造体やサブルーチン等）のアドレスを提供する。
診断モニタは、カーネルシンボルテーブルに依拠し、カーネルシンボルテーブルは、カーネルバイナリの非ストリップ版（non-stripped version）に内蔵される。
したがって、一実施の形態では、ローダは、カーネルＥＬＦバイナリからそのシンボルテーブルを取得して、メモリに当前記シンボルテーブルをロードする。

シンボルテーブルがブロック３４０においていったんロードされると、カーネルがブロック３０８においてロードされる。
カーネルは、メモリの固定アドレスにロードされることが好ましい。
ブロック３１０において、カーネルは、モニタが存在するかどうかを確認する。
一実施の形態では、モニタの存在に関する情報が、ローダからカーネルに渡される。
理由で何であろうとも、診断モニタが存在しないとみなされる場合には（ブロック３１０で確認）、カーネルは、自身の管理するトラップテーブルを用いて、ブロック３１２において通常どおり実行される。
他方、診断モニタが存在すると（ブロック３１０で確認）、カーネルは、任意選択で、（ブロック３１４において）診断モニタを呼び出すことができ、例えば、どのトラップが診断モニタのトラップテーブルによってハンドリングされ、どのトラップがカーネルのトラップテーブルによってハンドリングされるかを確認することができる。
もちろん、どのトラップがカーネルによってハンドリングされ、どのトラップが診断モニタによってハンドリングされるかに関する決定は、事前に行われ、ハードコード化することができる。
このような場合、任意選択のステップ３１４は省略することができる。

カーネルは、診断モニタを用いて初期化を完了すると、診断モニタおよび管理するモニタテーブルと共に実行される（ブロック３１６）。

図４は、診断モニタによるエラーハンドリングステップを、本発明の一実施の形態に従って示している。
トラップは、通常のオペレーションの結果である場合もあるし、問題を表す場合もあるので、診断モニタは、トラップを検査して、トラップをどのようにハンドリングするかに関して、一定の決定を行う必要がある。
ブロック４０２において、診断モニタは、トラップがカーネルによってハンドリングされるべきか、それとも診断モニタ自身によってハンドリングされるべきかを確認する。
一実施の形態では、この決定は、変数の特定の位置のビットを検査するビットマスク技法を使用して行われる。
他の技法も使用することができ、この技法には、配列を使用するものが含まれる。

トラップが、ページ不在等の通常のオペレーションの結果である場合、このようなトラップは、ＯＳのカーネルによってハンドリングすることができる。
その場合、この方法はブロック４０４に進む。
ブロック４０４において、（例えば図３のブロック３４０において）先にロードされたシンボルテーブル、および／または、（例えばブロック３１４において）カーネルによる診断初期化呼び出し中に取得された情報を使用して、この方法は、適切なＯＳトラップテーブルのオフセットに分岐する。

例えば、ＰＡＲＩＳＣ（商標）の実施態様では、例えば相対分岐命令（例えば５個だけ離れた命令への分岐）を使用することによるか、または、分岐命令で分岐先の実際のアドレスを与えることにより、分岐を実行することができる。

あるいは、分岐は、アドレスを含んだ汎用レジスタを参照することにより行うこともできる。

しかしながら、Ｉｔａｎｉｕｍベースのシステムでは、カーネルも分岐レジスタを使用するので、分岐命令が分岐レジスタを使用すると、カーネルにより使用されている分岐レジスタの内容が不注意に上書きされる可能性がある。
これらのレジスタの値を一時的に記憶させて復帰させることをカーネルに強制的に行わせることができるが、それは、製品カーネルに対する一定の変更の追加を必要とすることがある。

カーネルに対する変更点の個数を少なく維持するために、本発明の一実施の形態によると、診断モニタ内にロング分岐テーブルが設けられる。
例えば、ＩＰＦ（商標）の実施態様の場合、この分岐テーブルは、最初に、すべての分岐がその分岐自身にジャンプするようにセットアップされる。
初期化中、モニタは、ロング分岐命令のアドレスを動的に計算することができ、分岐テーブルのすべての分岐を、カーネルトラップテーブルの適切なオフセットへ分岐するように変更することができる。
これが可能な理由は、カーネルトラップテーブルが固定アドレスに存在するからである。

明確にすると、ロング分岐は、長いオフセットへ分岐することを可能にするタイプの相対分岐である。
この長いオフセットは、通常の相対分岐を使用して通常実行されるものよりも通常長いものである。
ロング分岐を使用することにより、メモリの任意の所望の位置にモニタを配置することができ、それでも、モニタは、カーネルトラップハンドラに到達することができる。
ロング分岐を使用しない場合には、モニタは、メモリにおいて、カーネルのトラップハンドラの近くに存在しなければならないことになる。
さらに、モニタのロング分岐テーブルにより、モニタは、カーネルによって利用される分岐レジスタの使用を回避することができる。
したがって、分岐レジスタの内容を把握するには、カーネルの変更がさらに必要となるが、把握する必要はない。
分岐レジスタを必要としない実施態様、例えばＰＡＲＩＳＣ（商標）の場合、汎用レジスタを代わりに使用することができる。

図４に戻って、トラップが、診断モニタによって処理されることになる場合には（ブロック４０２において確認）、ブロック４０６において、トラップがカーネルによる明示的なモニタ呼び出しであるかどうかを診断モニタが確認し、判断する。
例として、呼び出しの監視に使用されるブレークトラップ命令に関連した即値が指定され、それによって、診断モニタは、トラップがカーネルによる明示的なモニタ呼び出しであるかどうかを確認することが可能になる。
トラップが明示的なモニタ呼び出しである場合、そのトラップは、ブロック４４０においてハンドリングされる。
ブロック４４０については、以下で図６と共に説明する。

トラップが明示的なモニタ呼び出しでない場合（ブロック４０６において判断）、図４Ｂのブロック４０８において、ハードウェアトリガエラーが決定され、そのエラーが深刻であるかどうかが判断される。
一例として、カーネルブートの失敗は、深刻なエラーである。
ＩＰＦ（商標）では、例えば、マシンチェックアボート（ＭＣＡ（Machine Check Abort））の状況の発生は、通常、深刻なエラーとみなされる。
ＰＡＲＩＳＣ（商標）では、例えば、高優先度マシンチェック（ＨＰＭＣ）状況の発生は、通常、深刻なエラーとみなされる。

一般的に言うと、各アーキテクチャは、深刻なエラーを表すそれ自身の方法を有する。

しかしながら、エラーの詳細は、ボックスのタイプが異なると変化し得る。
例えば、エラーが深刻なものである場合に、プロセッサの所与のハードウェアレジスタの１ビットがセットされることがある。
診断モニタがコンピュータハードウェアに直接アクセスできることによって、ブロック４０８の決定が容易になる。
一般的に言うと、エラーの詳細は、ルールを使用して確認することができる。

エラーが深刻であるとみなされる場合（ブロック４０８において確認）、診断モニタは、インターラプト信号を他のすべてのプロセッサ（複数のプロセッサが存在すると仮定する）に送出することにより、カーネルの実行を停止する。
例えば、或るプロセッサが深刻なエラー（例えばＰＡＲＩＳＣ（商標）の場合のＨＰＭＣ）を受ける可能性があるが、コンピュータシステムの他のプロセッサは、同じ深刻なエラーを受けないことがある。
外部インターラプト信号によってそれらのプロセッサをフリーズさせることにより、それらのプロセッサの状態をブロック４１２において収集して、ブロック４１４における分析を容易にすることができる。
もちろん、システムに１つのプロセッサしか存在しない場合には、存在しない他のプロセッサにインターラプト信号を送出する必要はなく、この場合には、ブロック４１０は必要ない。

ブロック４１４では、例えば、モニタライブラリの特定ハードウェア向けルーチン（図２の２２２）を使用して、エラー分析を行うことができる。
特定ハードウェア向けルーチンは、プロセッサのさまざまなレジスタ、Ｉ／Ｏレジスタ、カーネルの一定のデータ構造体等を検査して、エラーおよび／またはエラーの原因を確認することができる。
その分析結果は、ブロック４１６において表示される。
一実施の形態では、その結果は、ＯＳのシェルとは別のモニタシェルに表示することができる。
モニタシェルは、一定の診断に関連した入力および出力を可能にし、ＯＳがクラッシュした場合であっても動作し続けることができる。
例えば、モニタシェルを使用して、一定のカーネルデータ構造体およびルーチンを指定することができ、検査用にそれらを表示するように指定できる。
このことは、図４のブロック４１８に表されている。

他方、エラーが、（ブロック４０８によって）深刻でないとみなされる場合、エラーに関する状態情報をブロック４３０において収集することができる。
ブロック４３２において、ライブラリのルールおよび特定ハードウェア向けルーチンを使用して分析が実行され、エラーが、１つまたは２つ以上のＦＲＵ（フィールド交換可能ユニット）に絞り込まれる。
例えば、単一のビットエラーが発生した場合、ブロック４３２は、そのエラーを、単一のＤＩＭＭおよび／または単一のメモリスロットに絞り込むように試みることができる。

モニタのルールおよびルールエンジンによって、モニタは、関連する（場合によっては特定ボックス向けの）レジスタと、カーネルのデータ構造体（必要ならば）とを分析することが可能になり、その問題を、例えば、障害のあるＦＲＵに絞り込むことが可能になることに留意されたい。
これは、標準的なＯＳを使用する従来技術の状況とは著しく異なる。
従来技術の状況では、経験豊富なユーザまたはエキスパートが、カーネルによってダンプされたデータを手動で分析しなければならないことになる。

さらに、モニタは、すべてのシステムおよびカーネルデータにアクセスすることができる。
それによって、モニタは、エラー検出タスクおよびエラー分析タスクを正確に実行するために必要なあらゆる情報を確実に取得することできる。
これと異なり、カーネルによってダンプされたデータは、場合によっては、エラー分析に必要なすべてのデータを含まないことがある。

ブロック４３４において、エラーに関する情報が、ログに記録される。
アプリケーションプログラムは、後の時点でモニタ呼び出しを使用して、ログに記録されたエラーを（例えばさらに分析または表示を行うために）取り出すことができる。
ブロック４３６では、この方法は、エラーが深刻なものでないことから、次の命令に続き、呼び出し側に戻って実行の継続を可能にすることが好ましい。

カーネルパニックがトラップなしで発生するときがある。
例えば、カーネルは、リソース（例えばメモリ）の外部で実行されたり、解決できない問題（例えば解決不能なページフォルト）に直面したりする或る違法な状況に遭遇していることがある。
この場合、カーネルは、パニック呼び出しを行っていることがある。
このパニック呼び出しは、非製品カーネルによってモニタ呼び出しに変換され、それによって、診断モニタが関与することが可能になる。
一方、カーネルパニックに関係したモニタ呼び出しは、そのモニタ呼び出しを、カーネルパニックの結果により発生したものと特定する情報を含む。
パニックに関係したモニタ呼び出しが受け取られると、このモニタ呼び出しは、図５のブロック５０２〜５１０においてハンドリングされる。

ブロック５０２〜５１０は、図４のブロック４１０〜４１８によって実行されるのと類似の形式でエラーハンドリングを実行する。

図６は、図４のブロック４４０を、本発明の一実施の形態に従ってより詳細に示している。
この場合、モニタ呼び出しは、ハードウェアによってもたらされたものでもないし、カーネルパニックによって引き起こされたものでもない。
そうではなく、アプリケーションが、エラーの報告、または、例えばエラーについて問い合わせを行うために、モニタ呼び出しを行っている。
したがって、ブロック６０２において、診断モニタは、このモニタ呼び出しが、単なる通常のモニタ呼び出しか、または、モニタエラー呼び出しかを判断する。
すなわち、モニタエラー呼び出しでは、アプリケーションは、エラーが存在することをすでに判断していることになる。
エラーモニタ呼び出しは、例えば、ＥＣＣ（エラー訂正コード（Error Correcting Code））回路装置に不具合があるとアプリケーションが判断した場合に行うことができる。
モニタ呼び出しがエラーモニタ呼び出しである場合、この方法は、ブロック６０４に進む。
ブロック６０４は図７に続き、この図７において、エラーモニタ呼び出しがハンドリングされる。
図７については、本明細書の後の部分に説明する。

他方、モニタ呼び出しがエラーモニタ呼び出しでない場合、この方法は、ブロック６０６に進む。
ブロック６０６において、診断モニタは、受け取った非エラーモニタ呼び出しの性質を確認する。
一実施の形態では、この確認は、テーブルの呼び出しインデックスを調べることにより行われる。
アプリケーションによって行われるこのような非エラーモニタ呼び出しの例には、システムのプロセッサ数を求める呼び出しや、訂正可能なエラーが発生したかどうかを判断する呼び出しが含まれることがある。

診断モニタが、受け取った非エラーモニタ呼び出しの性質を確認すると、非エラーモニタ呼び出しで要求された動作が、ブロック６０８において実行される。

ブロック６１０において、非エラーモニタ呼び出しで要求された情報がもしあれば、この情報が、呼び出し側アプリケーションに返される。

図７は、図６のブロック６０４を、本発明の一実施の形態に従ってより詳細に示している。
図７では、エラーモニタ呼び出しが受け取られる。
このエラーモニタ呼び出しは、図４によってハンドリングされるハードウェア生成トラップとは異なる。
この場合、アプリケーションは、ハードウェアによるエラーが存在すると判断しており、診断モニタは、データ収集およびエラー分析の実行に移って、報告されたエラーモニタ呼び出しを確認する。
したがって、ブロック７０２において、診断モニタは、受信したエラーモニタ呼び出しを、アプリケーションによって提供されたあらゆるデータと共にログに記録する。
ブロック７０３において、エラーモニタ呼び出しは、例えばルールベースの分析を使用して分析される。
ブロック７０４において、診断モニタは、エラーモニタ呼び出しが深刻なエラーに関係するものかどうかを確認する。
ＨＰＭＣ（ＰＡＲＩＳＣ（商標））またはＭＣＡ（ＩＰＦ（商標））は、明示的なタイプのトラップを引き起こす深刻なエラーの例を表す。
深刻であるが、トラップを引き起こさないタイプのエラーの例としては、例えば、セマフォのタイムアウトがある。
セマフォのタイムアウトでは、或るプロセッサが、或る一定の閾値よりも長い時間の間、セマフォを捕らえており、この状況は、ハングが差し迫っていることを示す。
この場合、例えば、セマフォはタイムアウトすることができ、その結果、モニタへの呼び出しが行われる。

ブロック７０４において、エラーモニタ呼び出しが深刻であるとみなされる場合には、診断モニタは、カーネルパニックを取り扱うのと同じ方法で、その深刻なエラーモニタ呼び出しを取り扱うことになる。
したがって、この方法は、ブロック７０８に進み、ブロック７０８において、深刻なエラーモニタ呼び出しが、図５と共に先に説明した方法でハンドリングされる。

他方、エラーモニタ呼び出しが、深刻でないエラーに関係するものである場合には、（エラーモニタ呼び出しは、ブロック７０２においてすでにログに記録されているので）この方法は、ブロック７０６に進み、呼び出し側ルーチンに戻って実行を継続する。

上記内容から分かるように、本発明の診断実行装置は、オフライン診断実行装置の手法の最良なものと、オンライン診断実行装置の手法の最良なものとを組み合わせたものである。
非製品カーネルを使用することにより、製品ＯＳによって課される制限は、効果的に除去され、それによって、本発明の診断実行装置は、コンピュータハードウェアへより直接的にアクセスすることが可能になり、製品カーネルの場合に当前記製品カーネルから取得できなかった情報を有することが可能になる。
コンピュータハードウェアとカーネルデータ構造体とサブルーチンとにアクセスすることが強化されたことにより、本発明の診断実行装置のエラー検出能力およびエラー分析能力は向上する。

一方、製品ＯＳとの相違（この相違は、診断モニタを収容するために行われたものである）を最小にした非製品ＯＳの使用により、本発明の診断実行装置は、コンピュータハードウェアに、より十分にストレスを加えることができ、（必要な診断試験時間を大幅に削減できる）適切に設計されたアプリケーションによるより直接的な試験に対応することができ、さらには、コンピュータハードウェアが現場で使用され得るやり方をより反映した試験に対応することができる。

さらに、非製品ＯＳの下ではなく、非製品ＯＳと協働して実行される診断モニタを提供することにより、診断モニタは、カーネルの障害を監視でき、カーネルの障害に関する情報を分析のために取り込むことができる。
診断モニタが、非製品カーネルのロード前にロードされるので、たとえカーネルがロード中に障害を受けても、診断が可能である。

ルールベースの分析システムを提供することにより、エラーが発生した場合、エラーおよび／またはエラー源の分析ならびに表示が、理解しやすい形式で容易に行われる。

<例示の実施態様>
以下に説明する例では、Ｌｉｎｕｘオペレーティングシステムに基づく診断実行装置の例示の実施態様を説明する。
この付録Ａの例示の実施態様は、本発明の一実施態様にすぎず、この特定の実施態様のために提案された設計選択、仮定、および限定はすべて、本発明を限定するものと包括的に解釈されるべきでないことに留意すべきである。
明らかに、本発明の限定は、本明細書の特許請求の範囲によって規定される。

以下の例示の実施態様において、Ｒａｇｅは、非製品カーネルに与えられた名前であり、Ｒａｇｅｍｏｎは、診断モニタに与えられた名前である。

［導入］
［機能／特徴］
ＲＡＧＥは、ＬＩＮＵＸに基づくオフライン実行装置である。
ＲＡＧＥは、個々のエグゼキュータブル（executable）がＲＡＧＥを監視できるような装備を有するように設計される。
ＲＡＧＥの下で実行されるアプリケーションは、ハードウェアにストレスを加えるように設計されると共に、いくつかの診断能力を実行するように設計される。
ＲＡＧＥＭＯＮは、ＲＡＧＥを監視するように設計されたエグゼキュータブルである。
ＲＡＧＥおよびこのモニタの双方は、ローダＥＬＩＬＯによってメモリにロードされる。
ローダＥＬＩＬＯは、標準的なＬＩＮＵＸローダの変更版である。

Ｒａｇｅは、以下の特徴を実施することを意図している。

我々の従来の「ポイントツーポイント」の試験のカバレッジを拡張すること。
より多くのストレスパターンを生成することにより、一時的エラーをより良く取り込むこと。
ハードウェアエラー（すなわちＭＣＡ）を検出して、そのエラーから復旧する能力を有すること。
ハードウェアエラーをＦＲＵまたは少なくともＦＲＵの小さなリストに分離する能力を有すること。

対象となるプラットフォームはＯｒｃａである。

以下の特徴リストも、このオフライン実行装置に設けることが望ましいとされるものである。

主要なすべてのハードウェア要素をカバーする試験スイート。
特定の対象ハードウェア向けの「ポイントツーポイント」試験を追加する能力。
プラットフォームの移植性。
どのストレス試験スイートが実行されるべきか、および、どの対象で実行されるべきかを指定する能力。
小さな初期フットプリント（footprint）を有する高速ロード。
モニタは、カーネルがクラッシュしても依然として活動する。

［依存するもの］
一般に、ＲＡＧＥは、依存するものとして以下のものを有する。

最も明らかに依存するものは、もちろんＬＩＮＵＸカーネル自身である。
ＥＦＩルーチンサービス。
ＰＡＬおよびＳＡＬのファームウェア呼び出し。
適切なコンパイラ。

仮定
ＬＩＮＵＸカーネルは、Ｏｒｃａをサポートする（ブート、実行などを行うことができる）ものと仮定する。

［設計の概要］
［設計の背景状況］
まず、ＲＡＧＥは、ＯＤＥベースの診断機能を実行した後、オフライン環境で使用することができる。
ＲＡＧＥは、調整された後、最終的に、コアとなる１組のＯＤＥベースの試験だけを残して、標準的なオフライン診断機能の多くと取って代わることができる。
この小さなコアとなる１組の試験は、キャッシュパターン試験およびＴＬＢの機能用に、主としてＣＰＵを中心に取り扱う。
次いで、ＲＡＧＥは、システムの残りの部分にストレス試験を行うように起動することができる。

最終的に、ＲＡＧＥは、標準的なオンライン試験にも同様にして取って代わることができるべきである。
最終的な所望のシナリオは、１）コアＯＤＥ試験、２）ＲＡＧＥ試験である。

オペレーションの概要
図Ａ１の図は、ＲＡＧＥ実行装置のプラットフォームを構成する基本モジュールを示している。

この図が示すように、ＲＡＧＥは、カーネル、モニタ、およびＲＡＧＥアプリケーションの３つのコンポーネントから構成される。
カーネルおよびモニタは、同じレベルにあることに留意されたい。
ＲＡＧＥモニタは、カーネルの下で実行されるのではなく、カーネルと共に実行される。
ＲＡＧＥアプリケーションは、予想されるように、カーネルの下で実行される。
そして、ＲＡＧＥアプリケーションは、実際に、ハードウェアにストレスを加えることを実行する。
これらのアプリケーションは、ＯＤＥプラットフォームの下におけるＯＤＥ診断機能と類似している。

主要なモジュール
以下のシナリオは、主要なＲＡＧＥモジュールのさらに詳細な説明を与える。

［ローダ］
ローダの基本的な機能は、図Ａ２の図に示されている。

カーネルローダは、すべてのＲａｇｅモジュールをメモリにロードする役割を有する。
カーネルローダがロードする最初のモジュールは、モニタである。
モニタは、ロードされると、或る初期化（図Ａ２の符号１）を行い、次いで、自身がどのハードウェア上で実行されているかを判断する。
その情報に基づいて、モニタは、どのライブラリをロードするかをローダに通知する。

このライブラリは、診断を受ける一定のレジスタの内容を取り込む方法等の専用化された情報を含む「ボックス版」特有のモジュールである。
モニタは、それ自体、アーキテクチャにのみ特有のものである。
ライブラリは、我々が実行している特定のタイプのボックスに特別なルーチンの集まりとしてみなされるべきである。
適切なライブラリがロードされると、そのライブラリは、モニタを用いて初期化を行う（図Ａ２の符号２）。

初期化には、そのライブラリのエントリポイントの場所をモニタに知らせること等が含まれる。

ライブラリがロードされるとすぐに、ローダは、ＲＡＧＥカーネルをロードする。
ローダは、モニタのトラップハンドラのアドレスをカーネルに渡す。
モニタがブートデバイス上に存在しない場合には、ローダは、ＲＡＧＥモニタのトラップハンドラのアドレスとしてゼロを渡す。
このようにして、カーネルは、自身の内部トラップハンドラを使用するのか、それともモニタのトラップハンドラを使用するのかを知ることになる。
モニタのトラップハンドラのアドレスがゼロでない場合、カーネルは、モニタが存在すると仮定する（図Ａ２の符号３参照）。

［モニタ］
ＲＡＧＥＭＯＮのジョブは、エラー発生時に、カーネルのどこに障害が発生したかを決定すること、および、交換を行うために、その問題をＦＲＵ（または少なくともＦＲＵの順序リスト）へ分離することを試みることである。
これを行うために、ＲＡＧＥＭＯＮは、カーネルが提供した情報を有する。
例えば、ＲＡＧＥＭＯＮは、プロセスに利用可能となるメモリではなく、メモリのどの範囲がカーネルによって実際に占有されているかを知りたい。

カーネルは、最初に起動して、モニタが存在することを検出すると、モニタを用いて初期化を行い、一定の重要な情報を渡す。
ＲＡＧＥＭＯＮ（利用可能ならば）は、カーネルが実行されている間存在し、カーネルがブート中の際にも存在する。
カーネルは、常に（所定の）固定アドレスにロードされる。

図Ａ３の図面から分かるように、モニタは、当前記モニタを構成するいくつかの主要な領域を有する。
アーキテクチャルーチンは、所与のアーキテクチャレベルに基づく標準的なタスクを実行するルーチンである。
例えば、すべての汎用レジスタの内容を保存する必要がある。
この保存は、アーキテクチャルーチンによって行われる。
汎用レジスタのサイズおよび個数は、使用されている特定のアーキテクチャに依存する（例えばＰＡＲＩＳＣ ２．０は６４ビット幅のレジスタを有する一方、ＰＡＲＩＳＣ １．０は３２ビット幅のレジスタを有する）。
モニタ自身も、アーキテクチャに依存することに留意されたい。
したがって、ＰＡＲＩＳＣ ２．０マシン用のモニタは、ＩＡ−６４マシン用のモニタとは異なる。

しかしながら、各モニタ内のルーチンの基本的な機能は同じである。

モニタ内のトラップハンドラは、ＲＡＧＥカーネルが実行されている間、機能的なトラップハンドラとなるように設計される。
したがって、カーネルによるあらゆるトラップ／インターラプトは、予期されるか否かを問わず、カーネルをモニタに強制的に移行させることになる。
この特徴により、モニタは、あらゆるエラートラップに直ちに気付くことが可能になる。
その時点で、モニタは、他のすべてプロセッサを停止でき、あらゆる状態情報を収集することができる。
エラーでないトラップの場合、モニタは、一定の統計値（もし必要ならば）を収集でき、次いで、トラップの基本的な機能を続行して、最終的にはカーネルに戻ることができる。
モニタは、カーネルシンボルテーブルからカーネルのトラップハンドラの位置を知る。
その結果、モニタは、カーネルトラップテーブルの適切なオフセットに分岐することができる。
そうでない場合には、カーネルは、自身のデフォルトトラップハンドラを使用する。
一定のエラートラップは、特別な方法で処理する必要がある。
ＭＣＡおよびＣＭＣの場合、ハードウェアは、ファームウェアルーチンに自動的に分岐する。
次いで、このファームウェアは、プロセッサのレジスタの状態を保存して、あらゆるエラー状況をクリアする。
モニタの適切なトラップハンドラルーチンが、適切にセットアップされており、かつ、ファームウェアが、そのエラーを、再ブートが必要となるほど深刻であるとみなさない場合、ファームウェアルーチンは、モニタのハンドラに分岐する。
この時点で、モニタは、次の分析を開始することができる。

モニタのルールエンジンは、基本的には、或るエラー状況のＦＲＵを探し出す方法を決定するためにライブラリに問い合わせを行うことをモニタに可能にする１組のルーチンである。
所与のアーキテクチャの「ボックス」のタイプごとに１つのライブラリが存在する。
このライブラリは、障害が発生したものを解明するために、収集データを分析するルール機能を（特に）含む。
それらのルールへのインターフェースは、アーキテクチャを問わず同じである。

モニタは、それ自身の別個のシェルを有する。
このシェルの第１の目的は、モニタの分析をユーザに表示すること、および、ユーザが一定の状態情報を観察することを可能にすることである。
したがって、このモニタのシェルは、カーネルのシェルに見られる特徴の多くを伴わない非常に簡単なものである。
初心者のユーザは、モニタのＦＲＵまたはＦＲＵのリストに簡単に目を通し、したがって、モニタシェルと何ら対話することなく行動することが予想される。
しかし、エキスパートのユーザは、障害の状態についてより詳細な情報、および、場合によってはモニタの決定プロセスを観察したいことがある。

［カーネル］
アプリケーションが診断時により良く機能できるように、カーネルを第１に変更しなければならない。しかしながら、目標は、この変更をできるだけ最小にすることである。以下のリストは、変更する必要のあるカーネルの領域を示している。

初期化（モニタ用）
初期化（ドライバ用）
モニタインターフェース変更（以下のカーネルインターフェースの節を参照）
新しい診断能力
プロセス親和性（まだ存在しない場合）
物理的なメモリ割り当て

［主要なインターフェース］
この文書で検討されるインターフェースのグループとして、以下の２つのグループが存在する。

外部モニタインターフェース（モニタ／カーネルおよびモニタ／アプリケーション）
内部モニタインターフェース
カーネル／アプリケーションインターフェース

［外部モニタインターフェース］
カーネルからモニタ（ＲＡＧＥＭＯＮ）へのアクセスを可能にする方法として、以下の４つの基本的な方法がある。

１）トラップ／インターラプト
２）カーネルパニック
３）明示的なモニタ呼び出し
４）明示的なモニタエラー呼び出し

以下の節は、これらのアクセス方法のそれぞれのより詳細な内容を与える。

すべての方法について、モニタはリアルモードにあり、ほとんどのトラップは無効にされることに留意されたい。

［トラップ／インターラプト］
カーネルの実行中、カーネルは、さまざまな時点で、トラップ、フォルト、インターラプト、またはチェックに遭遇することがある。
これらの状況のすべてが、エラー状況を示しているとは限らない。
しかしながら、このようないずれの状況も、カーネルをモニタに移行させることになる。
これは、カーネルのトラップハンドラが、モニタのハンドラを指し示しているからである。
これにより、モニタは、これらの重要なトラップ状況のいずれも取り込むことが保証される。
複数のプロセッサの場合、モニタは、プロセッサごとに個別のハンドラを提供しなければならないか、または、プロセッサがモニタコードのいずれの重要な部分も上書きしないようにするセマフォを使用しなければならない。
いずれにしても、モニタは、プロセッサがいくつ存在するかを知らなければならない。

初期化中、カーネルは、エラーでないケースをハンドリングするルーチンのアドレスをモニタに通知しなければならない。
これらのエラーでないトラップの１つが発生すると、モニタは、カーネルのレジスタの状態を変更しないように、適切なルーチンに分岐する。

［カーネルパニック］
カーネルパニックは、一般に、カーネルが或る違法な状況に遭遇した時、または、カーネルが或る問題（例えば解決できないページフォルト）を解決できない時に発生する。
カーネルパニックは、ソフトウェアエラーまたはハードウェアエラーが原因で発生し得る。
モニタは、カーネルパニックの区別を行うことができるように、カーネルパニックが発生した時点を知る必要がある。
カーネルのすべての「パニック」呼び出しは、ブレーク命令の変形（例えばブレーク２）を使用して実施される。
このブレーク命令の変形は、カーネルをモニタに強制的に移行させ、そこで、モニタは、そのパニックに適切な動作を決定することができる。

［モニタ呼び出し］
初期化中、カーネルは、情報をモニタに渡す必要があり、場合によってはモニタから情報を得る必要がある。
このタイプのカーネル／モニタ通信は、エラーとは無関係である。
これらのタイプの呼び出しの場合、モニタは、エラー状況を判断する必要もないし、カーネルをフリーズさせるように試みる必要もない。
あらゆるトラップ状況に対して、モニタに移行するので、標準的なモニタ呼び出しに対する別のブレーク命令の変形（例えばブレーク３）を使用することができる。

［モニタエラー呼び出し］
アプリケーションが、ハードウェアエラー状況を直接検出する場合がある。
そのアプリケーションは、システム呼び出しを使用して、カーネルに通知することができる。
次に、カーネルは、モニタエラー呼び出しを介してモニタに知らせることができる。
標準的なモニタ呼び出しと異なり、このエラー呼び出しは、モニタがカーネルをフリーズさせ、エラー情報を収集し、かつ、障害分析を開始すべきであることを示す。
この場合も、モニタに対する一貫性のあるインターフェースを維持するには、ブレークの変形（例えばブレーク３）を使用するのが便利である。
アプリケーションがこれらの呼び出しを直接起動できるようにすることは、さらに良いことであり、その結果、モニタは、エラーについての「新鮮な」情報を収集することができる。
ブレーク命令によって、モニタは、レジスタの状態について、エラーイベントの間近な「スナップショット」を有することが可能になる。
ブレーク命令は、即値フィールドを取ることに留意されたい。
このフィールドは、異なるタイプのモニタ呼び出しを区別するために使用される。

［モニタフリーズ呼び出し］
モニタは、エラー状況の通知を受けると、カーネルを「フリーズ」させる必要がある。
「フリーズ」は、基本的には、すべてのカーネルプロセスの停止を意味する。
この特徴は、或るプロセスが別のプロセスを妨害した場合の障害分析に有益である。
妨害を受けたプロセスは、トラップを引き起こすことができる。
この場合、トラップを引き起こしたプロセスを妨害した側のプロセスについての情報を有することは有益である。
トラップ発生時において、妨害した側のプロセスについて得ることができる情報が多いほど、その情報はより有益になる。

シングルプロセッサシステムでは、プロセスがモニタにトラップを発生すると、カーネルは、基本的に「フリーズ」される。
これは、１つのＣＰＵしか存在せず、したがって、１つのスレッドしか存在しないので、それ以外のプロセスは実行できないからである。
しかし、マルチプロセッサシステム（ＭＰシステム）では、他のプロセッサを停止しなければならない。
これを行うために、モニタは、「制御の転送」（ＴＯＣまたはリセットコマンド）を発行して、すべてのプロセッサを強制的に既知の場所に移行させる。
ＴＯＣは、カーネルを有効に「フリーズ」させる。

フリーズ呼び出しは、これまで説明したように、カーネルがモニタへ通信を開始するのではなく、モニタがカーネルへ通信を開始する唯一の呼び出しである。
ＭＰシステムでは、トラップを発生したプロセッサが深刻な機能不良状態である場合において、トラップを発生していないプロセッサにモニタを切り換えることができるとき、フリーズ呼び出しは有益である。

デフォルトの場合、ＭＣＡまたはＣＭＣが発生すると、モニタに戻る前に、ファームウェアが引き継ぐ。
次いで、ファームウェアは、ＰＤモナークプロセッサ（PD Monarch processor）上のモニタに戻る前に、すべてのプロセッサに強制的に状態を収集させ、「待ち合わせ（rendezvous）」させる。
他のエラーについては、ファームウェアは介入せず、モニタは、特別な外部インターラプトそのものを（ライブラリルーチンを介して）発行して、他のプロセッサを「フリーズ」させなければならない。

［内部モニタインターフェース］
モニタ／カーネルインターフェースと異なり、ライブラリとモニタとの間の通信は、プロシージャ呼び出しを通じて行われる。
そして、ライブラリおよびモニタは、個別に実行可能であるので、通信を行うには、両者の間に、或る種のスタブメカニズムが存在しなければならない。
ライブラリは、ＲＡＧＥが異なるボックス上で実行される場合に変化し得る特定「ボックス」向けのモジュールであることを想起されたい。
したがって、モニタとライブラリとの間には、或る種の標準的なインターフェースが存在する必要がある。
これにより、モニタは、どのライブラリが存在するかを知る必要はない。
モニタがライブラリに対して行うことができる標準的な１組の呼び出しが存在する。
この１組の読み出しによって、モニタは、ライブラリがどの「ボックス」用に記述されているかを問わず、必要な情報を得ることが可能になる。

ライブラリは、モニタ用に実行しなければならないいくつかの関数を有する。
これらの関数は、いくつかの分野、すなわち初期化、エラー復旧、エラー収集、および障害分析の分野に分類することができる。
起動時、ローダ（Ｒａｇｅｌｄｒ）は、最初にモニタをロードする。
次いで、適切なライブラリモジュールがロードされる。
ローダは、そのライブラリモジュールに、モニタの呼び出し側エントリポイントのアドレスを渡す。
ローダは、そのライブラリモジュールに制御を渡し、それにより、そのライブラリモジュールは、モニタを用いて初期化を行うことができる。
その初期化が完了すると、制御はローダに戻され、その結果、ローダはカーネルをロードすることができる。

モニタおよびライブラリは、「スタブ」インターフェースを介して通信する。
呼び出しを表す標準的な１組のインデックス番号がある。
ライブラリは、所望の呼び出しのインデックスを指定するスタブを有する。
ライブラリおよびモニタのいずれが通信を開始した場合も、両者が互いに通信できるように、モニタは同様のスタブを有する。

すべてのモニタ関数は、接頭語「Mon_」で始まる一方、すべてのライブラリ関数は、接頭語「Lib_」で始まることに留意されたい。

［初期化関数］
ローダがまずライブラリをロードし、ライブラリに一時的に制御を渡すと、ライブラリは、その呼び出し側エントリポイントのアドレスをモニタへ渡す必要がある。
ローダは、モニタの呼び出し側エントリポイントをライブラリにすでに渡している。
したがって、ライブラリは、Mon_Init()関数（モニタ初期化（）関数）を呼び出して、その呼び出し側エントリポイントをモニタに渡すことができる。
また、この呼び出しは、深刻なエラー用のデフォルトの「ファームウェア介入」方法を使用するのか、それとも「バックドア（back door）」方法を使用するのかもモニタに通知する。

Lib_Chksum()関数（ライブラリチェックサム（）関数）は、ライブラリの全体を加算したチェックサムを求めるものである。
この関数は、ライブラリがメモリに適切にロードされていることを保証するように設計される。
このチェックサムの結果はゼロになるべきである。
したがって、この関数の戻り値はゼロであるべきである。

Mon_Chksum()関数（モニタチェックサム（）関数）は、モニタがメモリに適切にロードされていることをモニタが保証することを可能にする点を除いて、Lib_Chksum()関数と同様である。

Mon_ProcCnt()関数（モニタプロセッサカウント（）関数）は、カーネルの初期化が完了すると、ライブラリによって呼び出すことができるものである。
この関数は、カーネルが検出したプロセッサの総数を返す。
カーネルがモニタを用いて初期化を行う前に、この関数が呼び出された場合、または、カーネルが初期化中に障害を起こした場合に、この関数は０を返す。

［エラー復旧関数］
Mon_Grs(proc_id)関数（モニタ汎用レジスタ状態（プロセッサＩＤ）関数）は、指定されたプロセッサがモニタに最後に移行した時、または、（モニタがエラー状況を検知した場合の）エラー時における、その指定されたプロセッサの汎用レジスタの状態を返すものである。
この関数は、引数としてプロセッサＩＤを受け取る。
プロセッサがモニタにいつ移行しても、そのレジスタの状態は保存される。

プロセッサがモニタに再度移行すると、保存されたレジスタの状態は上書きされる。

ライブラリルーチンは、この関数を使用して、最後に知られたプロセッサの状態を得ることができる。

エラー状況では、デフォルトのファームウェア介入方法が使用されていると、このルーチンは、ファームウェアからレジスタの状態を得る。
「バックドア」ライブラリでは、モニタは、特別なLib_Grs(proc_id)ルーチン（ライブラリ汎用レジスタ状態（プロセッサＩＤ）ルーチン）に依拠して、この情報を得る。

Mon_Crs(proc_id)関数（モニタ制御レジスタ状態（プロセッサＩＤ）関数）は、Mon_Grsと同様であるが、アーキテクチャの制御レジスタの状態を返すものである。

Mon_Shutdown()関数（モニタシャットダウン（）関数）は、カーネルが実行を停止する前に、モニタがあらゆる必要なクリーンアップを行うことを可能にし、ローダに戻るものである。
この関数が起動されると、モニタは、ＮＶＲＡＭのあらゆる実行フラグをクリアする。

Lib_Spec(index)関数（ライブラリ特殊（インデックス）関数）は、モニタが非標準のライブラリ関数を呼び出すことを可能にするものである。

Lib_Rcv(trap_id)関数（ライブラリ復旧（トラップ識別子）関数）は、トラップが発生し、レジスタの状態が保存された時は常にモニタによって呼び出されるものである。
このライブラリ関数は、プロセッサが依然として実行できるように、トラップを「復旧」する。
ＨＰＭＣおよびＬＰＭＣに対して、デフォルトの「ファームウェア介入」方法が使用される場合、この関数は何も行わない。

デフォルトの「ファームウェア介入」方法が使用されない場合、このルーチンは、変更が予定されるあらゆる特定ハードウェア向けエラーレジスタを保存して退避させる。
ライブラリが深刻とみなすトラップを除いたほとんどのトラップに対して、このルーチンは、有効に「ノーオペレーション（no-op）」になるが、このルーチンは、必要な保存および「クリーンアップ」を行う。

Lib_Freeze()関数（ライブラリフリーズ（）関数）は、モニタがすべてのカーネルプロセスを停止してカーネルの状態を記録したい場合に、モニタによって呼び出されるものである。
これを行うことは、ボックスごとに変化し得るので、このルーチンは、詳細をモニタから抽象化することを可能にする。
デフォルトの場合、ＨＰＭＣおよびＬＰＭＣ以外のどのエラーについても、この関数はＴＯＣを起動する。

Lib_SwitchProc(proc_id)関数（ライブラリプロセッサ切り換え（プロセッサＩＤ）関数）は、モニタが、指定されたプロセッサ上で実行を開始することを可能にするものである。
一定のエラー状況は、モニタが現在実行されているプロセッサを不安定にする場合がある。
このような場合、システムがマルチプロセッサシステムであると、モニタを、より安定したプロセッサに切り換えることが有利である。

Lib_ProcID()関数（ライブラリプロセッサＩＤ（）関数）は、モニタが、現在実行中のプロセッサのプロセッサＩＤを取得することを可能にするものである。

［エラー収集関数］
Lib_Collct()関数（ライブラリ収集（）関数）は、現在実行中のプロセッサ上でエラー状況が発生したものとモニタが判断すると、モニタによって呼び出されるものである。
このルーチンは、すべてのレジスタ情報と、モニタがデフォルトの場合には収集しないそれ以外の情報とを収集する。

この関数により、モニタは、状態の収集が必要なあらゆる特定「ボックス」向けレジスタについて知る必要がなくなる。
デフォルトの場合、ＨＰＭＣおよびＬＰＭＣに対して、この関数は、ファームウェア呼び出しを行い、一定のエラー情報を取得する。

［障害分析］
Lib_FaultAnal()関数（ライブラリ障害分析（）関数）は、障害分析に必要とされる中心となる関数である。
すべてのプロセスについて、すべての情報が収集されると、モニタは、この関数を呼び出す。
この関数は、障害のあるＦＲＵを決定するためにモニタが処理するルールリストを指し示す。

Mon_Printf(…)関数（モニタ印刷（…）関数）は、モニタがコンソールに印刷することを可能にするものである。
この関数は、標準的なｐｒｉｎｔｆ呼び出しと同じパラメータのシグネチャを有する。

Mon_KernelSym(address)関数（モニタカーネルシンボル（アドレス）関数）は、指定されたアドレスを含むカーネル関数の名前を返すものである。

［カーネルインターフェース］
モニタがそのジョブを行うことができるようにするために、標準的なカーネルに対して、以下のようないくつかの変更を行わなければならない。

１）モニタ初期化
２）ハートビート機能
３）時限付きセマフォ
４）明示的なモニタ呼び出し
５）ドライバ変更

これらのカーネルの変更は、モニタが存在しない場合には、モニタへの接触が試みられないように行う必要がある。
モニタが存在する場合には、ローダは、カーネルを起動すると、モニタのトラップハンドラのアドレスを渡す。
モニタが存在しない場合には、ゼロが渡される。このようにして、カーネルは、モニタが利用可能かどうかを知る。

［モニタの初期化］
Ｒａｇｅカーネルは、ブートの開始時に、モニタの存在を検出すると、モニタを用いて初期化を行う必要がある。
初期化には、以下のような、一定のカーネルの仕様をモニタに指定することが必要とされる。

１）カーネルシンボルテーブル
ローダは、カーネルのロード時に、カーネルシンボルテーブルもロードする。
モニタが、カーネルのグローバルアドレスのすべてにアクセスできるように、このテーブルへのポインタがモニタに与えられる。
これにより、カーネルが立ち上がらない場合であっても、モニタは、カーネルを分析することができる。

２）特定のタイプのトラップのカーネルルーチン
カーネルは、自身でハンドリングしたいすべてのトラップをモニタに指定する。

カーネルは、一定のトラップに遭遇した時に呼び出されるルーチンのアドレスを渡さなければならない。
モニタは、そのアドレスを保存し、その結果、トラップが発生した時、モニタは、予め割り当てられた適切なルーチンを呼び出す。

３）フリーメモリのカーネルの先頭
モニタは、フリーメモリのカーネルの先頭を知ると、一定のエラーが、時間データ構造体またはランタイムに作成されたデータ構造体をコンパイルするのに関係するかどうかを判断することができる。
フリーメモリの先頭に加えて、モニタが、一定のランタイム構造体（例えばページアロケータのマップ構造体）の位置を知ることは有益である場合がある。

４）プロセッサの個数
モニタがプロセッサの個数を知る必要があることは明らかである。
これは、例えば、モニタがフリーズを行う場合に重要である。
モニタは、プロセッサのすべてがいつチェックインしたかを知る必要がある。
また、モニタは、最初にトラップを発生したプロセッサのハードウェアの問題を回避するためにプロセッサを切り換えたい場合がある。
モニタは、障害発生時に実行されているすべてのプロセスの状態を知りたい。
あらゆるプロセッサがプロセスを実行している可能性があるので、実行中のすべてのプロセッサを知っていなければならない。
モニタは、自身でプロセッサの個数を求めることができるが、これは、カーネルが行わなければならないので、その理由から、モニタのコードを複製する。
したがって、モニタは、この情報についてはカーネルに依頼することになる。

［ハートビート機能］
一定のエラー状況によって、カーネルは、或る種の無限ループから抜け出せなくなる可能性がある。
通常のオペレーティングシステムでは、この種のエラーを診断することは困難である。
理想的には、モニタがハング状況を検出できるように、カーネルは、モニタで周期的に「チェックイン」することが有益である。
モニタの「ハートビート」機能は、まさにこの状況のために設計される。
ハートビート機能を実施することは、マルチプロセッサシステムよりもユニプロセッサシステムの方が難しい。

ハートビート機能の周期的な性質のため、ハートビート機能の可能性のある候補としては、インターバルタイマインターラプトがある。
プロセッサがタイマインターラプトを発生するごとに、モニタが呼び出される。
この時、モニタは、前回のインターラプトから経過したインターバルタイマのチック数をチェックすることができる。
例えば４つ以上のタイムスライスが経過していると、モニタは、これを、エラー状況の可能性があるとみなす（エラーとみなされるタイムスライスの正確な個数は、カーネルの挙動に基づいてヒューリスティックに求められることに留意されたい）。
モニタは、（ライブラリからのルールによって指定される）アドレスキューを調べて、カーネルが、前回のタイマインターラプトの期間中に実行されていたのと概ね同じ付近で実行されているかどうかを確かめる。
そうである場合、これにより、モニタは、システムをフリーズさせ、カーネルハングを表示する。
次いで、モニタは、このハングをさらに分析することを試みる（すなわち、どのルーチンがハングしているか等を調査する）。

マルチプロセッサシステムでは、すべてのプロセッサが同時にハングすることはあまり起こらない。
したがって、遅かれ早かれ、或るプロセッサがモニタに移行することになる。
その時点で、モニタは、タイマインターラプトを発生したプロセッサに加えて、他のプロセッサもチェックすることができる。
すべてのプロセッサのインターバルタイマが同期している場合（これは、診断命令を介して行うことができる）、モニタは、他の或るプロセッサが、あまりに長い時間を要したことからモニタで「チェックイン」できなかったかどうかを判断することができる。
モニタの受動的な性質のために、ユニプロセッサシステムは、ハングしても、モニタによって検出されない可能性がある。
カーネルが陥る無限ループが、インターバルタイマインターラプトをオフにし、かつ、他のタイプのトラップがループ内で発生しない場合には、モニタは、呼び出されないことになる。

［時限付きセマフォ］
セマフォ機能は、カーネルがハングする可能性のある、インターラプトのない主要なコード例である。
ユニプロセッサシステムでは、モニタが決して呼び出されないので、このようなハングは特に深刻である。
この可能性を低減するには、カーネルのすべてのセマフォ機能を時限付きにすべきである。
換言すると、すべてのセマフォ機能は、一定の時間の間だけセマフォにアクセスを試みるべきである。
その時間が経過すると、セマフォ機能はモニタを呼び出すべきである。

［明示的なモニタ呼び出し］
カーネルは、明示的なモニタ呼び出しを使用してモニタを直接呼び出すことができる。
前述したように、カーネルは、初期化中、モニタを呼び出す。
しかしながら、カーネルが、或る情報をモニタに追跡記録してほしい多くの状況が存在し得る。
例えば、どのプロセッサが所与の時刻に特定のセマフォを得たかをモニタが知ることは有益である。
そのように、他の或るプロセッサがそのセマフォ上でタイムアウトすると、モニタは、どのプロセッサがそのセマフォを得ていたかを知る。
また、特定のアプリケーションがプロセッサによっていつ実行されているかをモニタが知ることも有益である。
そのプロセッサがモニタにトラップを発生した場合に、モニタは、分析を行うために、カーネルではなく、アプリケーションシンボルテーブルを使用することを知ることができる。

明示的なモニタ呼び出しは、カーネルに「装備を取り付ける」ことが意味するものの中核をなすものである。
これらの明示的な呼び出しにより、カーネルは、モニタが障害分析に使用できる情報をモニタに渡すことが可能になる。
これは、強力な特徴である。
最も平凡なカーネルは、発生する性能を重視するために、このようには装備されていない。
しかしながら、ＲＡＧＥカーネルは、性能重視を、デバッグを行うためにカーネルの活動を追跡記録する機能とトレードオフする。
ライブラリのルールは、この追跡記録を行う特徴を他の特徴と共に使用して障害分析を行う。
これらの他の特徴には、ＥＬＦフォーマットのシンボルテーブルを使用してルーチンの名前を探し出すこと、呼び出し時に慣習的に行われる特徴を使用すること等が含まれる。
この呼び出し時の慣習的に行われる特徴は、サブルーチン呼び出しが、常に、戻りアドレスを有するｇｒ２を使用して行われるという特徴である。

［ドライバの変更］
より高速なカーネルブートを容易にするために、カーネルのドライバの多くを変更しなければならない場合がある。
多くのＩ／Ｏカードを有する大規模システムでは、すべてのＩ／Ｏデバイスの初期化を必要とすることから、カーネルのブートは長くなることがある。
これまでのカーネルは、ユーザがコンソールと対話できる前に、すべてのＩ／Ｏデバイスを確実に初期化する。
しかしながら、ＲＡＧＥでは、Ｉ／Ｏの初期化が遅れても構わない。
コアの不可欠なものを除くすべてのドライバは、ＬＩＮＵＸモジュールにすることができる。
したがって、それらの初期化が遅れても、ユーザは、コンソールにアクセスすることができ、初期化されていないＩ／Ｏを必要としないＲＡＧＥアプリケーションを起動することができる。
それらのモジュールが初期化されると、ＲＡＧＥアプリケーションを起動して、それらのモジュールに関連したＩ／Ｏにストレスを加えることができる。
ＲＡＧＥ Ｉ／Ｏを詳細にすることは、第２のＲＡＧＥ開発段階の一部である。
ＲＡＧＥ Ｉ／Ｏの検討が完了すると、関連した検討報告により、ＲＡＧＥ Ｉ／Ｏのより詳細な内容が与えられることになる。

［性能の考慮］
モニタが介入することにより、カーネルの性能は或る程度低下するが、ＲＡＧＥアプリケーションのストレスの影響を低減するほど大幅にカーネルを劣化させるべきではない。

［モジュールの詳細］
エラー状況が発生し、エラー情報が収集されると、モニタは、障害分析を開始する必要がある。
これを行うために、モニタは、ルールベースのエキスパートシステムの方法論を使用する。
これらのルールは、ライブラリモジュールに配置される。概念的には、各ルールは、以下のように見える。

ＩＦ（条件０）（条件１）…（条件Ｎ） ＴＨＥＮ（動作０）（動作１）…（動作Ｎ）

ライブラリモジュールには、このような１組のルールが存在する。
ルールは、ルール処理を高速にするように順序付けられる。
換言すると、先にトリガされる可能性の高いルールは、ルールリストの先頭に近い箇所に配置される。
障害分析を開始するために、ルールリストの各ルールは、順次、評価される。
ルールの「ＩＦ」部の条件は、実際には、関数ポインタである。
指し示される各関数は、０または非ゼロの値のいずれかを返す。
ゼロは、「ＦＡＬＳＥ（偽）」の条件を表す。

ルールが評価されている際、条件が非ゼロであると、その条件は関数ポインタである。
次いで、その関数が実行され、その結果がチェックされる。
関数の戻り値がゼロである場合、そのルールの条件はそれ以上評価されない。
この場合、そのルールは、ＮＯＴ−ＴＲＩＧＧＥＲＥＤ（トリガされない）と言われる。
さらに、条件のいずれかがゼロである（すなわち、その関数ポインタが「ＮＵＬＬ（ヌル）」である）場合、その条件は、ＦＡＳＬＥとみなされる。

したがって、そのルールも、ＮＯＴ−ＴＲＩＧＧＥＲＥＤである。

ルールのすべての条件が非ゼロの値を返す場合、そのルールは、ＴＲＩＧＧＥＲＥＤ（トリガされる）と言われる。
モニタは、ＴＲＩＧＧＥＲＥＤのルールに到達するまで、ルールリストの各ルールの評価を続ける。
ルールのいずれもがＴＲＩＧＧＥＲＥＤでない場合、モニタは、この状況を表示して停止する。
そうでない場合、モニタは、ＴＲＩＧＧＥＲＥＤのルールによって指定された動作のそれぞれを実行することを試みる。
或るルールがＴＲＧＧＥＲＥＤであると、モニタは、ルールリストのルールをそれ以上評価しない。
また、どのトリガルールも、再びＴＲＩＧＧＥＲＥＤとなることができないように無効にされる。
この特徴は、ルール処理を高速化するためのものである。

ルールの動作も、関数ポインタである。
モニタは、ＴＲＲＩＧＧＥＲＥＤのルールの各動作の関数を呼び出す。
各動作関数は、最初のものから開始して、順次呼び出される。
動作関数のすべてが呼び出されると、モニタは、そのルールを無効にし、次いで、ルールリストの先頭から開始して、次のＴＲＩＧＧＥＲＥＤのルールを探す。
ルールがどのように見えるかの例についての上記データ構造の節を参照されたい。

各ルールは、基本的には、そのルールが行おうとすることを記述した短いテキスト文字列を有するべきである。
この特徴により、モニタは、分析中、どのようにしてその結論に達したかを初心者のユーザに英語で表示することが可能になる。

モニタが障害のあるＦＲＵを決定するために利用できる、いくつかのデバッグの特徴として、以下のものがある。

［カーネルシンボルテーブル］
カーネルは、ＥＬＦ−６４バイナリである。
したがって、カーネルには、そのシンボルテーブルがバイナリで内蔵されている。
ライブラリのルールは、この特徴を使用して、カーネル内のエラー発生箇所を決定することができる。
また、アプリケーションも、ＥＬＦ−６４フォーマットにコンパイルされる。

したがって、同じ技法を使用することができる。
例えば、シンボルテーブルは、バイナリで含まれた関数の全開始アドレスを含むので、特定のプロセッサが障害を起こしたアドレスが判明すると、そのプロセッサがその時に実行していた関数をシンボルテーブルから決定することができる。

［プロシージャスタックの巻き戻し］
モニタは、スタックの巻き戻しを利用して、プロシージャを過去に遡ってトレースすることができる。

<製品ＯＳとの実施態様>
上記説明では、本発明の診断モニタが、非製品ＯＳと共に動作するように構成される。
上述したように、製品ＯＳは、通常、診断のためではなく、性能および／またはセキュリティならびにおそらく互換性のために最適化されている。
したがって、製品ＯＳの下で動作する診断実行装置は、通常、そのデータ収集能力、エラー検出能力、およびエラー分析実行能力がきびしく制限される。

本発明の診断モニタでは、製品ＯＳの製品カーネルと協働して動作する独立した診断バイナリを有することが非常に望ましいという状況が存在し得ることを、発明者は本明細書において考えている。
製品カーネルの下で特権プロセスまたはドライバとして実行される傾向のある従来技術の診断ルーチンと異なり、本発明の診断モニタは、カーネルがロードされる前であってもロードされるように構成されることが好ましい。
このように、本発明の診断モニタは、たとえカーネルをロードできない場合であってもエラー分析データを提供することができる。

さらに、本発明の診断実行装置がたとえ製品カーネルと協働して動作しても、本発明の診断モニタは、カーネルから独立して動作し、したがって、カーネルクラッシュの場合にエラー分析を実行することができる。
したがって、カーネルをクラッシュさせたエラーを分析するためにカーネルをダンプするといった多くの時間を要するプロセスおよびカーネルダンプデータを整理するといった大きな労力を要するプロセスが回避される利点がある。

本発明の一実施の形態によると、製品ＯＳは、本発明の診断モニタを収容するように最小限に変更される。
特に、製品ＯＳに対する変更の労力および／または程度を最小にすることが望ましく、変更に必要とされる作業量と、製品ＯＳの性能の特徴および／またはセキュリティの特徴への影響との双方を最小にすることが望ましい。
モニタは、明らかに、より多くのルーチンエラーをハンドリングできるが、性能のトレードオフを考慮する必要がある。
したがって、本明細書のさまざまな実施の形態において、深刻なカーネルエラー、すなわち、カーネルをハングまたはクラッシュさせることができるカーネルエラー、を伴う状況においてのみモニタが必要とされることを、発明者は本明細書において考えている。
これらの深刻なカーネルエラーには、例えば、深刻なハードウェアエラー、カーネルパニック、およびタイムアウトしたセマフォが含まれる。

図８は、製品ＯＳと共に本発明の診断モニタを使用する診断装置を、本発明の一実施の形態に従って示している。
この装置８０４は、ローダモジュール８０５を含む。
このローダモジュール８０５は、システム起動時に診断モニタ８０８の主要なコンポーネントをメモリにロードする役割を有する。
これらの主要なコンポーネントについては、以下に説明する。

装置８０４は、製品カーネル８０６を含む。
この製品カーネル８０６は、現場で使用される製品ＯＳ（例えば、製品Ｗｉｎｄｏｗｓ（商標）、製品ＵＮＩＸ（商標）、または製品Ｌｉｎｕｘ ＯＳ）のカーネルを表す。
複数のドライバ８０７ａ、８０７ｂ、８０７ｃが製品カーネル８０６と共に設けられる。
これらのドライバは、カーネル８０６と共に設けられたＩ／Ｏドライバのいくつかを表す。

診断モニタ８０８は、製品カーネル８０６と通信し、製品カーネル８０６を監視するように設計される。
一実施の形態では、モニタ８０８およびカーネル８０６は、個別のバイナリファイルとして提供される。
それによって、モニタ８０８は、ＯＳから独立したものとされる（すなわち、モニタ８０８は、カーネル８０６の下で実行されるのではなく、カーネル８０６と共に実行される）。
モニタ８０８は、カーネル８０６が使用しないメモリ位置にロードされて、カーネル８０６が、意図しない改変をモニタ８０８に行うことを回避することが好ましい。
深刻なエラーが発生すると、モニタ８０８は、そのエラーの分析を試み、かつ、その問題を、ＦＲＵ（フィールド交換可能ユニット）、または、違反の可能性のあるＦＲＵのリストへ分離することを試みる。
この意味で、本発明の装置は、通常はオフライン診断ツールに関連した木目の細かさを有するエラー分離を提供する。

図８に示すように、診断モニタ８０８は、モニタロジック８１０、モニタライブラリ８１２、およびモニタトラップテーブル８１４の３つのメインモジュールを含む。
モニタロジック８１０は、アーキテクチャ（例えば、ＰＡＲＩＳＣ（商標）、Ｉｔａｎｉｕｍ（商標）等）に依存する。
コンピュータハードウェア８０２の特定のアーキテクチャおよびボックスのタイプ（これらに関する情報はリンク８１６を介して取得できる）に応じて、適切なモニタライブラリ８１２がロードされる。
このように、一実施の形態では、モニタライブラリ８１２は、特定アーキテクチャ向けおよび特定ボックス向けの双方のものである。

モニタトラップテーブル８１４は、診断アプリケーションの実行中に管理されるトラップテーブルを表す。
本明細書で後に説明するように、診断モニタ８０８の主要な機能の１つは、トラップハンドラを制御することである。
カーネル８０６が遭遇するどのトラップも、モニタ８０８によって検査される。
モニタ８０８は、そのトラップを自身でハンドリングするのか、それともそのトラップをカーネルに譲ってハンドリングさせるのかを決定することになる。

深刻なエラー（例えば、カーネルパニック、深刻なハードウェアエラー、またはタイムアウトしたセマフォ）のみが診断モニタによってハンドリングされ、それ以外のトラップおよび／またはエラーはカーネル自身のトラップテーブルによって素早く確認され、ハンドリングされるように、この検査プロセスは最適化されることが好ましい。

カーネルは、トラップテーブルを有し、このカーネルのトラップテーブルは、特定のトラップをカーネルにハンドリングしてほしいと診断モニタ８０８が決定した場合に、制御が許可される。
このような場合、制御は、カーネルのトラップテーブルにおける、トラップをハンドリングするのに適切なオフセットに渡る。
このように、カーネルが関与している限り、カーネル自身のトラップテーブルは、カーネルがハンドリングする必要があるトラップをトランスペアレントな形式で得る。
それ以外のトラップ、例えば深刻なエラーに関係したトラップは、モニタトラップテーブル８１４によって保持され、ハンドリングされる。

アプリケーション８３０、８３２、８３４、および８３６は、通常の実行過程でカーネル８０６の下で実行できるいくつかのユーザアプリケーションを表す。
先に説明した診断アプリケーションとは異なり、これらのユーザアプリケーションは、コンピュータシステムの通常の使用過程でユーザによって実行されるアプリケーションを表す。
これらのユーザアプリケーションには、例えば、データベースアプリケーション、スプレッドシートプログラム、グラフィックスプログラム、ウェブ関連プログラムなどが含まれ得る。

図９は、診断モニタ８０８を、本発明の一実施の形態に従ってより詳細に示している。
図から分かるように、モニタロジック８１０は、コアモニタコード９１４に加えて、アーキテクチャルーチン９１０およびルールエンジン９１２を含む。
アーキテクチャルーチン９１０およびルールエンジン９１２は、説明を容易にするために、図９では、モニタロジック８１０とは別に示しているが、実際は、モニタロジック８１０の一部となっている。
アーキテクチャルーチン９１０は、所与のアーキテクチャレベルに基づいて標準的なタスクを実行できるルーチンを表す。
例えば、すべての汎用レジスタの内容を保存することが、必要となる場合がある。
これは、アーキテクチャルーチンによって行われることになる。
汎用レジスタのサイズおよび個数は、検討対象の特定のアーキテクチャに依存する（例えば、ＰＡＲＩＳＣ １．１は３２ビット幅のレジスタを有する一方、ＰＡＲＩＳＣ ２．０は６４ビット幅のレジスタを有する）。
一実施の形態では、コアモニタは、アーキテクチャに依存するが、さまざまなモニタライブラリが、さまざまなボックスを収容するように提供され、それによって、所与のアーキテクチャに関するすべてのボックスに対してコアモニタを使用することが可能になる。

モニタトラップテーブル８１４は、実行中に機能的なトラップハンドラとなるように設計される。
したがって、カーネル８０６（図８参照）によるあらゆるトラップ／インターラプトは、予期されるか否かを問わず、カーネル８０６を診断モニタ８０８に強制的に移行させることになる。
ルーチンのトラップおよびエラーは、カーネルのトラップテーブルに戻されてハンドリングされる一方、深刻なトラップ／エラーは、診断モニタ自体によってハンドリングされる。
例えば、深刻なハードウェアエラー、重大なソフトウェアエラー、およびハードウェアリセットの場合、ハードウェアは、ファームウェアルーチンに自動的に分岐することができる。
ＰＡＲＩＳＣ（商標）マシンに関しては、例えば、ＨＰＭＣ（高優先度マシンチェック）、ＬＰＭＣ（低優先度マシンチェック）およびＴＯＣ（制御の転送）が、ハードウェアをファームウェアルーチンに自動的に分岐させることができる。
次に、このファームウェアは、プロセッサのレジスタの状態を保存して、あらゆるエラー状況をクリアすることができる。
診断モニタ８０８の適切なトラップハンドラルーチンが、適切にセットアップされている場合には、ファームウェアルーチンは、診断モニタ８０８のハンドラに分岐することができる。
この時点で、診断モニタ８０８は、次の分析を開始することができる。

モニタロジック８１０のルールエンジン９１２は、そのエラー状況のＦＲＵを探し出す方法を決定するためにモニタライブラリ８１２に問い合わせを行う１組のルーチンを含む。

ルールエンジン９１２は、ルール９２０（後述）を解釈するために使用され、エラー分析にどのルールが使用されるかや、エラー分析はいつ完了したか等の機能を含むこともできる。
所与のアーキテクチャの「ボックス」のタイプごとに１つのライブラリが存在してもよい。
このライブラリは、故障した物を解明するために、収集データを分析できるルール機能を（特に）含むことができる。
それらのルールへのインターフェースは、さまざまなアーキテクチャ間で同じにすることができる。

モニタライブラリ８１２は、コアライブラリコード９２４に加えて、ルール９２０および特定ハードウェア向けルーチン９２２を含む。
ルール９２０は、検討対象のボックスおよびアーキテクチャに特有のルールを表し、エラー分析に使用される。
ルール９２０は、さまざまなエラー状況の推論を有し、エラーを、障害のあるＦＲＵに変換することができる。
特定ハードウェア向けルーチン９２２は、特定のボックスに特有のルーチンを含み、例えば、必要なあらゆる情報をその特定のボックスから収集することを容易にする。

コンピュータシステムの初期化時に、ローダモジュール８０５は、特定のシーケンスで診断モニタ８０８および製品カーネル８０６のコンポーネントをロードする。
このシーケンスは、図３Ａおよび図３Ｂで説明したものと類似してので、本明細書では、重複して繰り返さないことにする。
当業者には容易に分かるように、診断モニタが存在すると、その診断モニタを最初にロードできるように製品カーネルを変更する必要がある。
さらに、製品カーネルは、システム初期化時にトラップテーブルを自動的に制御しないことが好ましい。
一実施の形態では、この変更には、（カーネル自体のトラップテーブルのベースアドレスではなく）診断モニタのトラップテーブルのベースアドレスを、このようなデータを記憶するように指定されたレジスタに記憶することが含まれる。

図１０Ａおよび図１０Ｂは、診断モニタによるエラーハンドリングステップを、本発明の一実施の形態に従って示している。
トラップは、通常のオペレーションの結果である場合もあるし、問題を表す場合もあるので、診断モニタは、トラップを検査して、トラップをどのようにハンドリングするかに関して、一定の決定を行う必要がある。
ブロック１００２において、診断モニタは、トラップがカーネルによってハンドリングされるべきか、それとも診断モニタ自身によってハンドリングされるべきかを確認する。
一実施の形態では、この決定は、変数の特定の位置のビットを検査するビットマスク技法を使用して行われる。
一方、製品ＯＳの性能に対する影響を最小にするように最適化を行うことができる。
例として、コードが、モニタのトラップテーブルの適切なアドレスおよびオフセットに自動的に分岐できるように、モニタによってハンドリングされるトラップを列挙することができる。
これに代えてまたはこれに加えて、コードが、カーネルのトラップテーブルの適切なアドレスおよびオフセットに自動的に分岐できるように、カーネル自身のトラップテーブルによってハンドリングされるトラップを列挙することもできる。

トラップが、ページ不在等の通常のオペレーションの結果である場合、このようなトラップは、ＯＳのカーネルによってハンドリングすることができる。
その場合、この方法はブロック１００４に進む。
ブロック１００４において、（例えば図３のブロック３４０において）先にロードされたシンボルテーブル、および／もしくは、（例えばブロック３１４において）カーネルによる診断初期化呼び出し中に取得された情報を使用し、かつ／または、ハードコード化された分岐命令を介して、この方法は、適切なＯＳトラップテーブルのオフセットに分岐する。

例えば、ＰＡＲＩＳＣ（商標）の実施態様では、例えば相対分岐命令（例えば５個だけ離れた命令への分岐）を使用することによるか、または、分岐命令で分岐先の実際のアドレスを与えることにより、分岐を実行することができる。

あるいは、分岐は、アドレスを含んだ汎用レジスタを参照することにより行うこともできる。

しかしながら、Ｉｔａｎｉｕｍベースのシステムでは、カーネルも分岐レジスタを使用するので、分岐命令が分岐レジスタを使用すると、カーネルにより使用されている分岐レジスタの内容が不注意に上書きされる可能性がある。
これらのレジスタの値を一時的に記憶させて復帰させることをカーネルに強制的に行わせることができるが、それは、製品カーネルに対する一定の変更の追加を必要とすることがある。

本発明の一実施の形態によると、診断モニタ内に分岐テーブルが設けられる。
例えば、ＩＰＦ（商標）の実施態様の場合、この分岐テーブルは、最初に、すべての分岐がその分岐自体にジャンプするようにセットアップされる。
初期化中、モニタは、ロング分岐命令のアドレスを動的に計算することができ、分岐テーブルのすべての分岐を、カーネルトラップテーブルの適切なオフセットへ分岐するように変更することができる。
これが可能な理由は、カーネルトラップテーブルが固定アドレスに存在するからである。

明確にすると、ロング分岐は、長いオフセットへ分岐することを可能にするタイプの相対分岐である。
この長いオフセットは、通常の相対分岐を使用して通常実行されるものよりも通常長いものである。
ロング分岐を使用することにより、メモリの任意の所望の位置にモニタを配置することができ、それでも、モニタは、カーネルトラップハンドラに到達することができる。
ロング分岐を使用しない場合には、モニタは、メモリにおいて、カーネルのトラップハンドラの近くに存在しなければならないことになる。
さらに、モニタのロング分岐テーブルにより、モニタは、カーネルによって利用される分岐レジスタの使用を回避することができる。
したがって、分岐レジスタの内容を把握するには、カーネルの変更がさらに必要となるが、必ずしも把握する必要はない。
分岐レジスタを必要としない実施態様、例えばＰＡＲＩＳＣ（商標）の場合、汎用レジスタを代わりに使用することができる。

図１０Ａに戻って、トラップが、診断モニタによって処理されることになる場合には（ブロック１００２において確認）、ブロック１００６において、トラップがカーネルによる明示的なモニタ呼び出しであるかどうかを診断モニタは確認し、判断する。
例として、呼び出しの監視に使用されるブレークトラップ命令に関連した即値が指定され、それによって、診断モニタは、トラップがカーネルによる明示的なモニタ呼び出しであるかどうかを確認することが可能になる。

トラップが明示的なモニタ呼び出しである場合、そのトラップは、ブロック１０４０においてハンドリングされる。
この場合、明示的なモニタ呼び出しが、受け取られている。
アプリケーションは、モニタが或る機能（例えば、エラーログ閾値（error logging threshold）の設定または訂正可能エラー情報を返すこと）を実行するように要求中である。
次いで、モニタは、この機能を実行し、アプリケーションに戻る。

上述したように、深刻なエラーのみが、製品カーネルと協働して実行されている診断モニタによってハンドリングされることが好ましい。
ＨＰＭＣ（ＰＡＲＩＳＣ（商標））またはＭＣＡ（ＩＰＦ（商標））は、明示的なタイプのトラップを引き起こす深刻なエラーの例を表す。
深刻であるが、トラップを引き起こさないタイプのエラーの例としては、例えば、セマフォのタイムアウトがある。
セマフォのタイムアウトでは、或るプロセッサが、或る一定の閾値よりも長い時間の間、セマフォを捕らえており、この状況は、ハングが差し迫っていることを示す。
この場合、セマフォは、例えばタイムアウトすることができ、その結果、モニタへの呼び出しが行われる。
一般的に言うと、診断モニタは、カーネルパニックを取り扱うのと同じ方法で深刻なエラーモニタ呼び出しを取り扱う。
カーネルパニックをハンドリングするステップは、本出願の図１１と共に説明する。

トラップが明示的なモニタ呼び出しでない場合（ブロック１００６において判断）、そのトラップは、深刻なエラーとみなされる。
一例として、カーネルブートの失敗は、深刻なエラーである。
上述したように、深刻なハードウェアエラーは、診断モニタがハンドリングする深刻なエラーの１つの分類である。
ＩＰＦ（商標）では、例えば、マシンチェックアボート（ＭＣＡ）の状況の発生は、通常、深刻なエラーとみなされる。
ＰＡＲＩＳＣ（商標）では、例えば、高優先度マシンチェック（ＨＰＭＣ）状況の発生は、通常、深刻なエラーとみなされる。
一般的に言うと、各アーキテクチャは、深刻なエラーを表すそれ自身の方法を有する。
しかしながら、エラーの詳細は、ボックスのタイプが異なると変化し得る。
例えば、エラーが深刻なものである場合に、プロセッサの所与のハードウェアレジスタの１ビットがセットされることがある。
一般的に言うと、エラーの詳細は、ルールを使用して確認することができる。

深刻なエラーの場合、診断モニタは、インターラプト信号を他のすべてのプロセッサ（複数のプロセッサが存在すると仮定する）に送出することにより、カーネルの実行を停止する。
例えば、或るプロセッサが深刻なエラー（例えばＰＡＲＩＳＣ（商標）の場合のＨＰＭＣ）を受ける可能性があるが、コンピュータシステムの他のプロセッサは、同じ深刻なエラーを受けないことがある。
外部インターラプト信号によってそれらのプロセッサをフリーズさせることにより、それらのプロセッサの状態をブロック１０１２において収集して、ブロック１０１４における分析を容易にすることができる。
もちろん、システムに１つのプロセッサしか存在しない場合には、存在しない他のプロセッサにインターラプト信号を送出する必要はなく、この場合には、ブロック１０１０は必要ない。

ブロック１０１４では、例えば、モニタライブラリの特定ハードウェア向けルーチン（図８の８２２）を使用して、エラー分析を行うことができる。
特定ハードウェア向けルーチンは、プロセッサのさまざまなレジスタ、Ｉ／Ｏレジスタ、カーネルの一定のデータ構造体等を検査して、エラーおよび／またはエラーの原因を確認することができ、そのエラーを１つまたは２つ以上のＦＲＵ（フィールド交換可能ユニット）に絞り込むことができることが好ましい。
例えば、分析は、特定のＣＰＵが、不具合を有し、交換の必要があることを正確に示すことができる。
その分析結果は、ブロック１０１６において表示される。
一実施の形態では、その結果は、ＯＳのシェルとは別のモニタシェルに表示することができる。
モニタシェルは、一定の診断に関連した入力および出力を可能にし、ＯＳがクラッシュした場合であっても動作し続けることができる。
例えば、モニタシェルを使用して、一定のカーネルデータ構造体およびルーチンを指定することができ、検査用にそれらを表示するように指定できる。
このことは、図１０のブロック１０１８に表されている。

モニタのルールおよびルールエンジンによって、モニタは、関連する（場合によっては特定ボックス向けの）レジスタと、カーネルのデータ構造体（必要ならば）とを分析することが可能になり、その問題を、例えば、障害のあるＦＲＵに絞り込むことが可能になることに留意されたい。
これは、標準的なＯＳを使用する従来技術の状況とは著しく異なる。
従来技術の状況では、経験豊富なユーザまたはエキスパートが、カーネルによってダンプされたデータを手動で分析しなければならないことになる。

さらに、モニタは、すべてのシステムおよびカーネルデータにアクセスすることができる。
それによって、モニタは、エラー検出タスクおよびエラー分析タスクを正確に実行するために必要なあらゆる情報を確実に取得することができる。
例えば、一実施の形態では、カーネルのマップファイルは、グローバルなカーネル変数のアドレスおよびカーネル関数アドレスを含むことができ、これらのすべてが、モニタによってアクセス可能である。
これと異なり、カーネルによってダンプされたデータは、場合によっては、エラー分析に必要なすべてのデータを含まないことがある。

カーネルパニックがトラップなしで発生するときがある。
例えば、カーネルは、リソース（例えばメモリ）の外部で実行されたり、解決できない問題（例えば解決不能なページフォルト）に直面したりする或る違法な状況に遭遇していることがある。
この場合、カーネルは、パニック呼び出しを行っていることがある。
このパニック呼び出しは、変更された製品カーネルによってモニタ呼び出しに変換され、それによって、診断モニタが関与することが可能になる。
一方、カーネルパニックに関係したモニタ呼び出しは、そのモニタ呼び出しを、カーネルパニックの結果により発生したものと特定する情報を含む。
パニックに関係したモニタ呼び出しが受け取られると、このモニタ呼び出しは、図１１のブロック１１０２〜１１１０においてハンドリングされる。
ブロック１１０２〜１１１０は、図１０Ｂのブロック１０１０〜１０１８によって実行されるのと類似の形式でエラーハンドリングを実行する。

上記から分かるように、独立したバイナリとして動作する本発明の診断モニタを製品カーネルと協働して使用することにより、本発明の診断モニタは、カーネルクラッシュの場合またはカーネルがロードされない場合であっても、エラー分析を行うことができる。

モニタが深刻なエラーのケースにのみ必要とされ、通常の実行中に発生する深刻でないエラー（例えば、ページフォルト、訂正可能な単一ビットのメモリエラー）のハンドリングに使用されないことから、システムの性能に対する負の影響も削減される。
通常の実行の期間中は、説明される３つのケース（例えば、深刻なハードウェアエラー、カーネルパニック、タイムアウトしたセマフォ）のいずれも発生せず、したがって、システムの性能に対するモニタの影響は最小限に抑えられる。

上述したように、上記例示の実施態様は、本発明の原理による診断モニタの実施態様の一具体例にすぎない。
したがって、この発明について、いくつかの好ましい実施の形態の観点から説明してきたが、この発明の範囲内に入る変更、並べ替え、および均等物が存在する。
また、本発明の方法および装置を実施する多くの代替的な方法が存在することにも留意すべきである。
したがって、添付した特許請求の範囲は、本発明の真の精神および範囲内に入るすべての変更、並べ替え、および均等物を含むものとして解釈されることが意図されている。

診断を受けるコンピュータハードウェアと診断実行装置とを含む診断環境を、本発明の一実施の形態に従って示す図である。 診断モニタを、本発明の一実施の形態に従ってより詳細に示す図である。 初期化におけるロードシーケンスを、本発明の一実施の形態に従って示す図である。 初期化におけるロードシーケンスを、本発明の一実施の形態に従って示す図である。 診断モニタによってコンピュータシステムの性能を診断する論理フローを、本発明の一実施の形態に従って示す図である。 診断モニタによってコンピュータシステムの性能を診断する論理フローを、本発明の一実施の形態に従って示す図である。 カーネルパニックをハンドリングするステップを、本発明の一実施の形態に従って示す図である。 診断アプリケーションによってモニタ呼び出しをハンドリングするステップを、本発明の一実施の形態に従って示す図である。 診断アプリケーションによってエラー呼び出しをハンドリングするステップを、本発明の一実施の形態に従って示す図である。 製品ＯＳと共に本発明の診断モニタを使用する診断装置を、本発明の一実施の形態に従って示す図である。 図８の診断モニタを、本発明の一実施の形態に従ってより詳細に示す図である。 診断モニタによるエラーハンドリングステップを、本発明の一実施の形態に従って示す図である。 診断モニタによるエラーハンドリングステップを、本発明の一実施の形態に従って示す図である。 パニックに関係したモニタ呼び出しをハンドリングするステップを、本発明の一実施の形態に従って示す図である。 ＲＡＧＥ実行装置プラットフォームを構成する基本モジュールを、本発明の例示の一実施態様に従って示す図である。 ローダの基本機能を、本発明の例示の一実施態様に従って示す図である。 モニタの主要なコンポーネントを、本発明の例示の一実施態様に従って示す図である。

符号の説明

１０２・・・コンピュータハードウェア、
１０４・・・診断実行装置、
１０５・・・ローダ、
１０６・・・診断カーネル、
１１０・・・モニタロジック、
１１２・・・モニタライブラリ、
１１４・・・モニタトラップテーブル、
１３０・・・ＣＰＵアプリケーション、
１３２・・・メモリアプリケーション、
１３４・・・Ｉ／Ｏアプリケーション、
１３６・・・他のアプリケーション、
２１０・・・アーキテクチャルーチン、
２１２・・・ルールエンジン、
２１４・・・モニタコード、
２２０・・・ルール、
２２２・・・特定ハードウェア向けルーチン、
２２４・・・ライブラリコード、
８０２・・・コンピュータハードウェア、
８０５・・・ローダ、
８０６・・・製品カーネル、
８１０・・・モニタロジック、
８１２・・・モニタライブラリ、
８１４・・・モニタトラップテーブル、
８３０，８３２，８３４，８３６・・・ユーザアプリケーション、
９１０・・・アーキテクチャルーチン、
９１２・・・ルールエンジン、
９１４・・・モニタコード、
９２０・・・ルール、
９２２・・・特定ハードウェア向けルーチン、
９２４・・・ライブラリコード、

Claims (8)

1. コンピュータシステム（８０２）が、カーネルトラップ処理を備えたＯＳカーネル（８０６）を有する製品オペレーティングシステム（ＯＳ）を使用してユーザアプリケーション（８３０）を実行する際に、前記コンピュータシステム（８０２）を監視するコンピュータ実施される方法であって、
   前記コンピュータが前記ＯＳカーネル（８０６）を実行できない場合であっても、診断モニタ（８０８）を実行することができるように、ローダにより、ブートデバイスから前記ＯＳカーネル（８０６）が使用しないメモリ領域に、トラップを処理するトラップハンドラを保持するモニタトラップテーブル（８１４）を有する診断モニタ（８０８）をロードすることと、
   前記ユーザアプリケーションの実行中にトラップが発生した（encounter）場合に、前記診断モニタが、前記発生したトラップを示すビット列に対してマスクをかけて、特定の位置のビットを取り出し、取り出したビットが第１の値であるとき、前記トラップが前記ＯＳカーネル（８０６）によってハンドリングされることを決定し、前記取り出したビットが前記第１の値と異なる第２の値であるとき、前記トラップが前記診断モニタによってハンドリングされることを決定する（１００２）ことと、
   前記トラップが前記ＯＳカーネルによってハンドリングされるべきである場合に、前記トラップを前記ＯＳカーネルに渡して（１００４）ハンドリングさせることと
   を含む方法。
2. 前記ＯＳカーネル（８０６）は、前記ユーザアプリケーション（８３０）を実行するように構成された製品カーネルである
   請求項１に記載のコンピュータ実施される方法。
3. 前記ＯＳカーネルのロード（３０８）の前に、前記診断モニタがロードされる（３２２）
   請求項２に記載のコンピュータ実施される方法。
4. 前記トラップが前記診断モニタ（８０８）によってハンドリングされるべきである場合に、前記トラップが前記ＯＳカーネルによるモニタ呼び出しを表しているかどうかを、前記診断モニタを使用して確認する（１００６）ことと、
   前記トラップが前記ＯＳカーネルによる前記モニタ呼び出しを表している場合に、前記診断モニタを使用し（１０４０）、前記モニタ呼び出しをハンドリングすることと
   をさらに含む請求項１に記載のコンピュータ実施される方法。
5. 前記トラップが前記モニタ呼び出しを表していない場合に、前記診断モニタを使用することであって、
   ａ）前記コンピュータシステムの他のあらゆるプロセッサにフリーズ信号を送出する（１０１０）ことと、
   ｂ）状態信号を収集する（１０１２）ことと、
   ｃ）前記状態情報の分析を実行する（１０１４）ことと
   を行うこと
   をさらに含む請求項４に記載のコンピュータ実施される方法。
6. 前記トラップが前記モニタ呼び出しを表していない場合に、前記診断モニタを使用することであって、
   ｄ）前記分析の結果をシェルに表示する（１０１６）ことと、
   ｅ）前記シェルからのユーザ入力がある場合には、前記ユーザ入力を受け取る（１０１８）ことと
   を行うこと、
   をさらに含む請求項５に記載のコンピュータ実施される方法。
7. 前記ＯＳカーネル（８０６）を使用して、パニック呼び出しをモニタ呼び出しに変換することと、
   前記モニタ呼び出しが前記診断モニタ（８０８）によって受け取られると、前記モニタ呼び出しが、前記パニック呼び出しを表しているのかどうかを、前記診断モニタ（８０８）を使用して確認することと、
   前記モニタ呼び出しが前記パニック呼び出しを表している場合に、前記診断モニタを使用することであって、
   ａ）前記コンピュータシステムの他のあらゆるプロセッサにフリーズ信号を送出する（１１０２）ことと、
   ｂ）状態情報を収集する（１１０４）ことと、
   ｃ）前記状態情報の分析を実行する（１１０６）ことと
   を行うことと
   をさらに含む請求項１に記載のコンピュータ実施される方法。
8. 前記モニタ呼び出しが、前記パニック呼び出しを表している場合に、前記診断モニタを使用することであって、
   ｄ）前記分析の結果をシェルに表示する（１１０８）ことと、
   ｅ）前記シェルからのユーザ入力がある場合には、前記ユーザ入力を受け取る（１１１０）ことと
   を行うこと
   をさらに含む請求項７に記載のコンピュータ実施される方法。

Images