(57)【要約】【課題】  診断アプリケーションを使用してコンピュータシステムの性能を診断する。【解決手段】  本方法は、コンピュータシステムにおいて、カーネルトラップ機構を有するオペレーティングシステム（ＯＳ）カーネルのもとで実行される診断アプリケーションと、当該ＯＳカーネルと協調的に実行され、モニタトラップ機構を有する診断モニタとを提供する。本発明は、診断アプリケーションの実行中に遭遇したトラップが、ＯＳカーネルによって処理されるのか、または、診断モニタによって処理されるのかを、診断モニタを使用して確認し、さらに、トラップがＯＳカーネルによって処理される場合には、当該トラップをＯＳカーネルに渡して処理する。【選択図】図１
2004259258.tif 000002
【特許請求の範囲】
【請求項１】
診断アプリケーションを使用してコンピュータシステムの性能を診断する、コンピュータ実施される方法であって、
診断アプリケーション（１３０、１３２、１３４、１３６）を提供すること、
オペレーティングシステム（ＯＳ）カーネル（１０６）であって、前記診断アプリケーション（１３０、１３２、１３４、１３６）が、前記コンピュータシステムにおいて該ＯＳカーネル（１０６）のもとで実行されるように構成され、該ＯＳカーネル（１０６）が、カーネルトラップ機構を有するＯＳカーネル（１０６）を提供すること、
前記ＯＳカーネル（１０６）と協調的に実行するように構成され、かつ、モニタトラップ機構（１１４）を有する診断モニタ（１０８）を提供すること、
前記診断アプリケーションの実行中に遭遇したトラップが、前記ＯＳカーネル（１０６）によって処理されるのか、または、前記診断モニタ（１０８）によって処理されるのかを、前記診断モニタ（１０８）を使用して確認すること、
前記トラップが前記ＯＳカーネル（１０６）によって処理される場合には、該トラップを前記ＯＳカーネル（１０６）に渡して処理すること
とを含むコンピュータ実施される方法。
【請求項２】
前記ＯＳカーネル（１０６）は、非製品ＯＳカーネルであり、
該非製品ＯＳカーネルは、前記コンピュータシステムを購入する顧客による使用に提供される製品ＯＳカーネルの変更版を表し、
該非製品ＯＳカーネルは、前記製品ＯＳカーネルによって課される多数の制約よりも少ない制約で、前記診断モニタ（１０８）が、該非製品ＯＳカーネルに利用可能な情報にアクセスすることを可能にする
請求項１に記載のコンピュータ実施される方法。
【請求項３】
前記ＯＳカーネル（１０６）は、該ＯＳカーネルをロードする（３０８）前に、前記診断モニタ（１０８）を初期化する（３３２）ことを可能にするように構成される
請求項２に記載のコンピュータ実施される方法。
【請求項４】
前記トラップが前記診断モニタによって処理される場合には、前記トラップが、前記診断アプリケーションによるモニタ呼び出しを表すかどうかを、前記診断モニタを使用して確認する（４０６）こと、
前記トラップが前記診断アプリケーションによる前記モニタ呼び出しを表す場合には、前記トラップが、エラー呼び出しを表すかどうかを、前記診断モニタを使用して確認する（６０２）こと、
前記トラップが前記エラー呼び出しを表す場合には、前記診断モニタを使用して、前記エラー呼び出しを処理する（６０４）こと
とをさらに含む請求項１に記載のコンピュータ実施される方法。
【請求項５】
前記エラー呼び出しを処理することは、
前記エラー呼び出しが危険なエラー呼び出しを表すかどうかを、前記診断モニタを使用して確認する（７０４）こと、
前記エラー呼び出しが前記危険なエラー呼び出しを表さない場合には、前記エラー呼び出しがログに記録された後に戻る（７０６）こと
とを含む
請求項４に記載のコンピュータ実施される方法。
【請求項６】
前記エラー呼び出しが前記危険なエラー呼び出しを表す場合には、
イ）前記コンピュータシステムの他のあらゆるプロセッサにフリーズ信号を送信する（５０２）こと、
ロ）状態情報を収集する（５０４）こと、
ハ）前記状態情報の分析を実行する（５０６）ことと
を、前記診断モニタを使用して実行すること
をさらに含む請求項５に記載のコンピュータ実施される方法。
【請求項７】
前記エラー呼び出しが前記危険なエラー呼び出しを表す場合には、
ニ）前記分析の結果をシェルに表示する（５０８）こと、
ホ）前記シェルからユーザ入力がある場合には、該ユーザ入力を受け取る（５１０）ことと
を、前記診断モニタを使用して実行すること
をさらに含む請求項６に記載のコンピュータ実施される方法。
【請求項８】
前記トラップが前記エラー呼び出しを表さない（６０２）場合には、
前記診断モニタを使用して、前記トラップの情報によって要求される動作を実行する（６０８）こと、
該動作を実行することから得られる情報を返す（６１０）こと
とをさらに含む請求項４に記載のコンピュータ実施される方法。
【請求項９】
前記トラップが前記モニタ呼び出しを表さない場合には、前記トラップが危険なエラーを表すかどうかを、前記診断モニタ（１０８）を使用して確認する（４０８）こと、
前記トラップが前記危険なエラーを表す場合には、
イ）前記コンピュータシステムの他のあらゆるプロセッサにフリーズ信号を送信する（４１０）こと、
ロ）状態情報を収集する（４１２）こと、
ハ）前記状態情報の分析を実行する（４１４）こと
とを前記診断モニタを使用して実行すること
をさらに含む請求項４に記載のコンピュータ実施される方法。
【請求項１０】
前記トラップが前記危険なエラーを表す場合には、
ニ）前記分析の結果をシェルに表示する（４１６）こと、
ホ）前記シェルからユーザ入力がある場合には、該ユーザ入力を受け取る（４１８）ことと
を前記診断モニタを使用して実行すること
をさらに含む請求項９に記載のコンピュータ実施される方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、コンピュータおよびオペレーティングシステムの障害および性能を分析する改良された診断実行器(DIAGNOSTIC EXERCISER)およびその方法に関する。
【背景技術】
【０００２】
コンピュータおよびオペレーティングシステムが複雑になるにつれて、障害および性能の分析はより難しくなる。
信頼性の理由から、コンピュータシステムは、使用に供する前に徹底的に試験することが非常に望ましい。
一般的に言うと、コンピュータシステムのハードウェアの特定の部分を試験するコードを作成することは可能である。
しかしながら、このような狭い部分に集中した試験は、コンピュータシステムの全てに全体的にストレスを加えておらず、コンピュータシステムの現場で行われる傾向にある使用方法を反映していない。
【０００３】
別のアプローチは、オペレーティングシステムのもとで実行されてエラーを検出する診断ツール、例えば診断実行器などの使用を伴うものである。
今日、診断実行器は、通常、製品オペレーティングシステム（ＯＳ）、例えばＬｉｎｕｘ、ＨＰＵＸ（商標）（カリフォルニア州パロアルトのHewlett-Packard Company）、またはＷｉｎｄｏｗｓ（ワシントン州レドモンドのMicrosoft Corporationの商標）などのもとで実行するように設計される。
製品ＯＳのもとで実行される診断実行器は、特別なドライバおよび／またはオペレーティングシステム呼び出しを使用する専用に設計されたアプリケーションを使用することにより、特定の方法でコンピュータシステムにストレスを加えることができ、ある一定のエラーが発生した時にそれらを検出することができる。
これらの診断実行器はＯＳを使用するので、それら診断実行器のアプリケーションは、より十分に、かつ、例えばマルチスレッド、高速ディスクＩ／Ｏオペレーションなどの特徴を伴うコンピュータシステムの現場での使用方法により近い方法でハードウェアにストレスを加えることができる。
【０００４】
一般に、コンピュータシステムが経験するストレスの量は、診断実行器のどのアプリケーションが実行されているかに応じて変化し得る。
しかしながら、所与の診断実行器が、製品オペレーティングシステムのもとで実行される場合、このような診断実行器の特徴は、そのオペレーティングシステムによって制約を受ける。
例えば、製品オペレーティングシステムは、競争に勝つために、現場の性能を得ることに最適化される傾向にあり、広範な診断能力用には最適化されない傾向にある。
したがって、このような製品ＯＳのもとで実行される診断実行器は、その診断能力が制約される傾向にある。
同様に、データ収集、エラー検出、およびエラー分析に役立つ他の特徴を設けると、ＯＳの性能が極度に阻害され、かつ／または、現場のコンピュータシステムのセキュリティが危険にさらされることになることから、このような特徴は、製品ＯＳでは利用可能でない可能性がある。
【０００５】
さらに、製品ＯＳのもとで実行されるほとんどの診断実行器は、特権プロセスおよび／または特権ドライバとして実行される傾向にある。
この事実によって、カーネルクラッシュの状況では、診断実行器の有用性が制限される傾向にある。
例えば、カーネルのブート中にカーネルがクラッシュすると、従来技術の診断実行器の一般的な診断モニタは、起動されなかったことになり、それによって、カーネルのブート障害の検出および分析にほとんど価値がなくなる。
【０００６】
その上、カーネルがクラッシュした場合のほとんどの一般的な診断技法には、カーネルダンプの取得およびカーネルダンプデータの分析が含まれる。
しかしながら、このような診断技法は、カーネルダンプファイルに保存された情報によって本質的に制限される。
カーネルダンププログラムを最初に設計したプログラマが、ある一定の情報を保存しないことを決定していた場合、このような情報は、カーネルダンプファイルにおいて分析用に利用できないことになる。
さらに、カーネルダンプファイルで利用可能な情報の内容およびフォーマットは、カーネルダンプを最初に設計したプログラマの裁量に応じて変化し得る。
したがって、カーネルダンプ情報を解読することは困難であることがあり、カーネルを最初に設計したプログラマを見つけ出して、カーネルダンプファイルの分析を援助してもらうことが必要になるかもしれない。
ＯＳが制作された時期と、特定のエラーが発生し、その結果、カーネルダンプが行われた時期との間に長時間が経過している場合、そのプログラマは、もはや援助に利用できない可能性があり、カーネルダンプデータを精密に調査するには、カーネルのエキスパートを使用する必要があり得る。
【発明の開示】
【発明が解決しようとする課題】
【０００７】
本発明は、上述した背景からなされたものであり、改良された診断実行器およびその方法を提供することを目的とする。
【課題を解決するための手段】
【０００８】
本発明は、一実施の形態において、診断アプリケーションを使用してコンピュータシステムの性能を診断する、コンピュータ実施される方法に関する。
本方法は、診断アプリケーションを提供すること、オペレーティングシステム（ＯＳ）カーネルであって、診断アプリケーションが、コンピュータシステムにおいて当該ＯＳカーネルのもとで実行されるように構成され、当該ＯＳカーネルが、カーネルトラップ機構を有する、ＯＳカーネルを提供することとを含む。
また、本方法は、当該ＯＳカーネルと協調的に実行するように構成され、かつ、モニタトラップ機構を有する、診断モニタを提供することも含む。
その上、本方法は、診断アプリケーションの実行中に遭遇したトラップが、ＯＳカーネルによって処理されるのか、または、診断モニタによって処理されるのかを、診断モニタを使用して確認することを含む。
さらに、本方法は、トラップがＯＳカーネルによって処理される場合には、当該トラップをＯＳカーネルに渡して処理することを含む。
【０００９】
別の実施の形態では、本発明は、アプリケーションプログラムの実行中にコンピュータシステムの性能を診断する、コンピュータシステムの機構に関する。
このアプリケーションプログラムは、オペレーティングシステム（ＯＳ）カーネルのもとで実行される。
このＯＳカーネルと協調的に実行するように構成される診断モニタが含まれる。
ＯＳカーネルは、アプリケーションプログラムの実行中に生成されるトラップタイプのメッセージおよびインターラプトタイプのメッセージの少なくとも一方を処理するカーネルトラップ機構を有する。
診断モニタは、ＯＳカーネルがクラッシュした後も実行し続けることができる。
診断モニタは、トラップタイプのメッセージおよびインターラプトタイプのメッセージの少なくとも一方を処理するモニタトラップ機構を含む。
診断モニタは、アプリケーションプログラムの実行中に生成されるトラップを受信するように構成され、かつ、受信した所与のトラップについて、ＯＳカーネルがその受信したトラップを処理するのか、または、診断モニタがその受信したトラップを処理するのかを決定するように構成される。
【００１０】
さらに別の実施の形態では、本発明は、そこに組み込まれるコンピュータ読み取り可能コードを有するプログラム記憶媒体を構成する製品に関する。
このコンピュータ読み取り可能コードは、コンピュータシステムのエラーを処理するように構成される。
診断モニタを実施するコンピュータ読み取り可能コードが含まれる。
この診断モニタは、コンピュータシステムのオペレーティングシステム（ＯＳ）カーネルと協調的に実行するように構成される。
診断モニタは、コンピュータシステムで生成されるトラップを受け取るように構成されるモニタトラップ機構を含む。
ＯＳカーネルは、診断モニタから渡されたトラップを処理するように構成されるカーネルトラップ機構を有する。
また、システムの起動時に、ＯＳカーネルをロードする前に、診断モニタをロードするコンピュータ読み取り可能コードも含まれる。
【００１１】
本発明のこれらおよび他の特徴については、以下の発明を実施するための最良の形態において、添付図面と共に、より詳細に説明する。
【００１２】
本発明を、添付図面の図形に一例として図示するが、本発明を限定する目的で図示するものではない。
添付図面において、同じ参照符号は、同様の要素を参照する。
【発明を実施するための最良の形態】
【００１３】
次に、本発明について、添付図面に示すような本発明のいくつかの好ましい実施の形態を参照して詳細に説明する。
以下の説明では、本発明の十分な理解を提供するために、多数の具体的な詳細について説明する。
しかしながら、本発明は、これらの具体的な詳細のいくつかまたはすべてがなくても実践可能であることが、当業者には明らかであろう。
それ以外の場合には、本発明を不必要に分かりにくくしないように、既知のプロセスのステップおよび／または構造は、詳細に説明されていない。
【００１４】
本発明の一実施の形態によると、純粋なオフラインの診断アプローチによって提供される利点と、オンラインのＯＳベースの診断アプローチによって提供される利点とを組み合わせた診断機構および診断技法が提供される。
純粋なオフラインの診断アプローチによって提供される利点としては、例えば、コンピュータハードウェアへの広範なアクセスおよびコンピュータハードウェアの広範な制御と、エラー検出およびエラー分析の容易さとがある。
オンラインのＯＳベースの診断アプローチによって提供される利点としては、例えば、より十分に、かつ、コンピュータハードウェアが現場で経験するストレスをより良く表す方法で、ハードウェアにストレスを加えることができることである。
【００１５】
オフラインおよびオンラインという用語が本明細書で使用されるが、診断ツールがその診断タスクにＯＳを使用しない場合に、その診断ツールは、オフラインであると言われる。
オフライン診断ツールは、個々のハードウェアサブシステムへの広範なアクセスおよび／またはその制御を行うことができるが、それらの診断アプローチは、局所化された刺激応答に基づく傾向がある。
オフライン診断ツールに基づく刺激応答試験は、ある一定の一時的エラーを効率的に検出するのに適していないことが知られている。
【００１６】
さらに、オフライン診断ツールは、コンピュータシステムのハードウェアに、包括的な方法でストレスを加えず、また、コンピュータシステムが現場で経験するストレスを表す方法でコンピュータシステムのハードウェアにストレスを加えない。
したがって、試験を受けているサブシステムが現場でおそらく経験するシナリオのほとんどを、実行された試験が確実にカバーするには、多数の刺激（および刺激の多数の並べ替え）を使用する必要があった。
プラスの面として、オフライン診断ツールは、コンピュータシステムハードウェアの個々のサブシステムを、仲介としての役割を果たすＯＳのない状態で、刺激応答試験に基づいて試験する傾向があるので、ハードウェアの機能への広範なアクセスおよびハードウェアの機能の広範な制御が可能であり、エラーの分離および分析の複雑さが少なくなる傾向にある。
【００１７】
これと対照的に、診断ツールは、その診断タスクにＯＳを使用する場合に、オンラインであると言われる。
診断アプリケーションがＯＳのもとで実行される場合、ハードウェアの制御は、直接的な形式で行われることは少なくなり、ハードウェアへのアクセスは、はるかに多く制約される。
しかしながら、オンライン診断アプリケーションは、例えばマルチスレッド、高速Ｉ／ＯアクセスなどのＯＳに関連した特徴を使用して、コンピュータシステム全体に、より十分にストレスを加えることができる。
オンライン診断アプリケーションは、ＯＳのもとで実行されるので、コンピュータシステムは、現場で経験するストレスにより近い方法でストレスを受ける傾向にある。
さらに、オンライン診断ツールでは、起こり得る使用のシナリオおよび／または現実的な使用のシナリオへ試験をより近づけることができ、オフライン診断実行器でよく行われるように、さまざまな並べ替えをランダムに試験することが行われないので、試験に要する時間を短くすることができる。
なお、オンライン診断実行器で行われる並べ替えのいくつかは、非現実的なものであり得、かつ／または、コンピュータシステムが現場で決して経験しないものであり得る。
【００１８】
しかしながら、オンライン診断ツールの追加された能力は、柔軟性がなく、複雑であるという代償を払っている。
既存のＯＳベースの診断ツールは、製品ＯＳ（すなわち現場で使用されるＯＳ）のもとで実行される傾向があるので、セキュリティおよび性能への配慮から、既存のＯＳベースの診断ツールの診断能力および／または分析能力が厳しく制限される。
ＯＳおよび／またはＯＳカーネルの設計に依存して、ある一定のタイプの情報は、エラー検出および／またはエラー分析のための取り込みおよび／またはアクセスができないことがある。
ハードウェアへのアクセスおよび／またはハードウェアの制御は、厳しく制限され得る。
情報が取り込まれる場合であっても、カーネルダンプのような情報は、分析してエラー源を確認するのが困難な場合がある。
また、ＯＳベース診断ツールは、エラー源を簡単な方法で分離することも困難な傾向がある。
【００１９】
先に述べたように、本発明の診断実行器の実施の形態は、純粋なオフラインの診断アプローチによって提供される利点と、オンラインのＯＳベースの診断アプローチによって提供される利点とを組み合わせる。
ハードウェアシステムを十分に実行させて、コンピュータシステムが現場で使用される方法をより良く表す試験を使用してコンピュータシステムのより統制された試験を実現するために、診断実行器は、ＯＳを使用する。
しかしながら、使用されるＯＳは、診断カーネルに基づく非製品ＯＳである。
有利には、診断能力を向上させるように変更された非製品ＯＳおよびより具体的には非製品カーネルを使用することにより、本発明は、製品ＯＳの制限を回避することができる。
なお、この制限は、例えばセキュリティおよび／または性能の理由に基づいて課されるものである。
診断試験は、制御された非製品環境で実行されるので、現場で配慮されるセキュリティおよび性能の重要性は低くなる。
さらに、診断モニタは、非製品カーネルを監視し、かつ、非製品カーネルと協調的に動作するように設けられる。
この協調的という用語が本明細書で使用されるが、診断モニタは、非製品カーネルのもとで動作しないので、非製品カーネルと協調的に実行されると言われる。
本発明のある一定の実施の形態によると、理解しやすいように障害分析を提供するルールベースの機構が提供される。
本発明の技法は、たとえブート中または診断アプリケーションプログラムの実行中にカーネルがクラッシュしても、障害分析を容易にするために使用される。
【００２０】
好ましい実施の形態では、カーネルについての詳細な情報（すなわちデータ構造体、カーネルデータの位置など）を有する診断モニタが、ＯＳが使用しないメモリ領域にロードされる。
この診断モニタは、カーネルのロードおよびブートの前にロードされ、トラップベクタテーブルを制御する。
カーネルのブート中、または、カーネル（すなわちＯＳ）の実行中、発生するあらゆるトラップまたはインターラプトは、診断モニタによって検査されて、それらのトラップまたはインターラプトがどのように処理されるべきかが判断されることになる。
【００２１】
詳しく述べると、現代のコンピュータアーキテクチャのトラップ／インターラプトメカニズムでは、ある一定の状況が発生すると、特権コードを実行することができる。
特定のアーキテクチャに依存して、これらの状況には、ある一定のハードウェアイベントおよびあるソフトウェア生成イベントが含まれる。
このトラップ／インターラプトベースのメカニズムは、本発明の診断モニタによって利用されて、エラー検出を容易にすることに加えて、ある一定のエラーに関するデータ収集およびデータ分析を容易にする。
【００２２】
一般に、エラーでないすべてのトラップは、診断モニタによって通常のカーネルベクタテーブルに渡されることになる。
そうでない場合には、診断モニタは、メモリのカーネルデータ構造体から収集できるあらゆる情報と共に、トラップ情報を検査し、この情報をエラーの分離のために使用することになる。
カーネルパニックは、強制的なトラップを診断モニタに引き起こすことがある。
多くのアーキテクチャでは、タイムスライスイベントであるプロセスは、エラーでないトラップを引き起こすことがある。
これらのトラップは、診断モニタによって使用されて、実行時のハードウェアパラメータおよびカーネルパラメータの「監視」が可能になる。
例えば、ＣＰＵがタイムスライストラップを有する場合に、診断モニタは、そのＣＰＵ上で実行されているプロセスに関連したプロセスデータ構造体を検査することにより、そのＣＰＵが、アイドルであったかどうかを判断することができる。
ＣＰＵがアイドルである場合には、診断モニタは、ＣＰＵを使用してエラーをチェックすることができる。
チェックが完了すると、ＣＰＵは、そのアイドルループに戻ることになる。
このように、診断モニタは、カーネルに対するその性能の影響を小さくすることができる。
【００２３】
ほとんどの一般的なオペレーティングシステムでは、セマフォは、時限付きにはなっていない。
すなわち、カーネルスレッドがあるセマフォを捕らえようと試みると、そのカーネルスレッドは、そのセマフォを獲得するまで、永遠に捕らえようと試みることになる。
しかしながら、カーネルのセマフォルーチンが、ある時間の経過後、タイムアウトして、トラップを強制するように変更されると、診断モニタは、分析を行うために使用可能となる。
【００２４】
本発明の一実施の形態によると、ローダプログラム（ローダ）が最初に実行される。
このローダは、ロードされた後、ブートデバイス（例えばディスクなど）から診断モニタを見つけ出して、その診断モニタを起動する。
診断モニタは、初期化を行い、自身が実行されているコンピュータのモデルが何であるかを判断しようと試みる。
一般に、所与の診断モニタは、特定のマシンアーキテクチャ用にコンパイルされている。
その後、診断モニタは、自身が実行されているコンピュータのモデルに適切なライブラリモジュールをロードするようにローダに要求する。
このライブラリは、監視されるコンピュータについてのモデル特有の情報、例えば、さまざまなハードウェアエラーの検出ルーチンおよび分離ルーチンなどを有する。
さらに、ライブラリは、実行されるオペレーティングシステムについての詳細な情報を有する。
【００２５】
診断モニタは、一般に、例えばＯＳがロードされる、プロセスデータ構造体のレイアウトなどのＯＳのさまざまな詳細を知る必要がある。
また、カーネルのシンボルテーブルもロードされて、診断モニタによって使用され、これによって、診断モニタは、固定したカーネルデータ構造体の位置を知る。
実行時のほとんどのカーネル構造体の位置は、ある一定の固定した構造体の位置を知ることにより推定することができる。
あらゆる例外について、カーネルは、それらの位置を、ＯＳの初期化中または構造体作成時に診断モニタに渡すことができる。
加えて、診断モニタは、そのトラップベクタテーブルを使用されるものとしてインストールする。
その後、診断モニタは、ローダに制御を返す。
【００２６】
本発明の詳細および利点は、以下の図面および解説を参照することにより、より良く理解できる。
図１は、診断を受けるコンピュータハードウェア１０２と診断実行器１０４とを含む診断環境を、本発明の一実施の形態に従って示している。
【００２７】
診断実行器１０４は、ローダモジュール１０５を含む。
ローダモジュール１０５は、システム起動時に、診断実行器１０４の主要なコンポーネントをメモリにロードする役割を有する。
これらの主要なコンポーネントは、以下で解説する。
【００２８】
診断実行器１０４は、診断カーネル１０６を含む。
この診断カーネル１０６は、診断目的で使用される非製品ＯＳ（例えば、非製品Ｗｉｎｄｏｗｓ（商標）またはＬｉｎｕｘ  ＯＳ）のカーネルを表す。
複数のドライバ１０７ａ、１０７ｂ、１０７ｃが診断カーネル１０６に設けられる。
これらのドライバは、診断実行器１０４がＩ／Ｏデバイスに関する情報を取得できるようにするために設けられたドライバのいくつかを表す。
このように、Ｉ／Ｏデバイスが故障した場合、関連するドライバ上で計測を実行して、カード／デバイス電子機器から情報を収集することができ、それによって、診断実行器１０４は、そのエラーを分析することが可能になる。
【００２９】
一般的に言うと、コンピュータハードウェア１０２が現場で経験するストレスを表す方法でコンピュータハードウェア１０２にストレスを加えることを可能にするために、診断カーネル１０６と製品ＯＳのカーネルとの間の変更点は最小に維持することが好ましい。
しかしながら、診断モニタ（後述）が、カーネル１０６を監視する機能、エラー検出を監視する機能、およびエラー分析を監視する機能を実行できるようにするには、ある一定の変更が必要とされる。
一実施の形態では、カーネル１０６は、診断モニタおよびドライバの初期化を可能にし、診断アプリケーションの実行中に診断モニタと通信することを容易にし、かつ、追加された診断能力（例えばプロセッサ親和性、物理メモリの割り当てなど）を提供することが可能となるように変更される。
製品カーネルに対する他の可能な変更点については、以下にさらに解説する。
【００３０】
また、診断実行器１０４は、診断モニタ１０８も含む。
診断モニタ１０８は、エラーの検出および分析に伴う監視ソフトウェアを表す。
診断モニタ１０８は、カーネル１０６と通信し、カーネル１０６を監視するように設計される。
一実施の形態では、モニタ１０８およびカーネル１０６は、個別のバイナリファイルとして提供される。
それによって、モニタ１０８は、ＯＳから独立したものとされる（すなわち、モニタ１０８は、カーネル１０６のもとで実行されるのではなく、カーネル１０６と共に実行される）。
モニタ１０８は、カーネル１０６によって使用されないメモリ位置にロードされて、カーネル１０６によるモニタ１０８の意図されないあらゆる改変が回避されることが好ましい。
カーネル１０６にエラーが発生すると、モニタ１０８は、そのエラーの分析を試み、かつ、その問題を、ＦＲＵ（フィールド交換可能ユニット（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()関数（Mon_初期化（）関数）を呼び出して、その呼び出し側エントリポイントをモニタに渡すことができる。
また、この呼び出しは、危険なエラー用のデフォルトの「ファームウェア介入」方法を使用するのか、「バックドア（back door）」方法を使用するのかもモニタに通知する。
【０１１６】
Lib_Chksum()関数（Lib_チェックサム（）関数）は、ライブラリの全体を加算したチェックサムを求める。
この関数は、ライブラリがメモリに適切にロードされたことを保証するように設計される。
このチェックサムの結果はゼロになるべきである。
したがって、この関数の戻り値はゼロであるべきである。
【０１１７】
Mon_Chksum()関数（Mon_チェックサム（）関数）は、モニタがメモリに適切にロードされたことをモニタが保証することを可能にする点を除いて、Lib_Chksum()関数と同じである。
【０１１８】
Mon_ProcCnt()関数（Mon_プロセッサカウント（）関数）は、カーネルの初期化が完了すると、ライブラリによって呼び出すことができる。
この関数は、カーネルが検出したプロセッサの総数を返す。
カーネルがモニタを用いて初期化を行う前に、この関数が呼び出されるか、または、カーネルが初期化中に障害を起こすと、この関数は０を返す。
【０１１９】
エラー復旧関数
Mon_Grs(proc_id)関数（Mon_汎用レジスタ状態（プロセッサＩＤ）関数）は、指定されたプロセッサがモニタに最後に入った時、または、（モニタがエラー状況を検知した場合の）エラー時における、その指定されたプロセッサの汎用レジスタの状態を返す。
この関数は、引数としてプロセッサＩＤを受け取る。
プロセッサがモニタにいつ入っても、そのレジスタの状態は保存される。
プロセッサがモニタに再度入ると、保存されたレジスタの状態は上書きされる。
ライブラリルーチンは、この関数を使用して、最後に知られたプロセッサの状態を得ることができる。
エラー状況に対して、デフォルトのファームウェア介入方法が使用されている場合、このルーチンは、ファームウェアからレジスタの状態を得る。
「バックドア」ライブラリでは、モニタは、特別なLIB_GRs(proc_id)ルーチン（Lib_汎用レジスタ状態（プロセッサＩＤ）ルーチン）に依拠して、この情報を得る。
【０１２０】
Mon_Crs(proc_id)関数（Mon_制御レジスタ状態（プロセッサＩＤ）関数）は、Mon_Grsと同様であるが、アーキテクチャの制御レジスタの状態を返す。
【０１２１】
Mon_Shutdown()関数（Mon_シャットダウン（）関数）は、カーネルが実行を停止する前に、モニタがあらゆる必要なクリーンアップを行うことを可能にし、ローダに戻る。
この関数が起動されると、モニタは、ＮＶＲＡＭのあらゆる実行フラグをクリアする。
【０１２２】
Lib_Spec(index)関数（Lib_特殊（インデックス）関数）は、モニタが非標準のライブラリ関数を呼び出すことを可能にする。
【０１２３】
Lib_Rcv(trap_id)関数（Lib_復旧（トラップ識別子）関数）は、トラップが発生し、レジスタの状態が保存された時は常にモニタによって呼び出される。
このライブラリ関数は、プロセッサがその後も実行できるように、トラップを「復旧」する。
ＨＰＭＣおよびＬＰＭＣに対して、デフォルトの「ファームウェア介入」方法が使用される場合、この関数は何も行わない。
【０１２４】
デフォルトの「ファームウェア介入」方法が使用されない場合、このルーチンは、変更が予定されるあらゆるハードウェア特有のエラーレジスタを保存して退避させる。
ライブラリが危険と考えるトラップを除いたほとんどのトラップに対して、このルーチンは、有効に「ノーオペレーション（no-op）」になるが、このルーチンは、必要な保存および「クリーンアップ」を行う。
【０１２５】
Lib_Freeze()関数（Lib_フリーズ（）関数）は、モニタがすべてのカーネルプロセスを停止してカーネルの状態を記録したい場合に、モニタによって呼び出される。
これを行うことは、ボックスごとに変化し得るので、このルーチンは、詳細をモニタから抽象化することを可能にする。
デフォルトの場合には、ＨＰＭＣおよびＬＰＭＣ以外のどのエラーについても、この関数はＴＯＣを起動する。
【０１２６】
Lib_SwitchProc(proc_id)関数（Lib_プロセッサ切り換え（プロセッサＩＤ）関数）は、モニタが、指定されたプロセッサで実行を開始することを可能にする。
ある一定のエラー状況は、モニタが現在実行されているプロセッサを不安定にする場合がある。
このような場合、システムがマルチプロセッサシステムであると、モニタを、より安定したプロセッサに切り換えることが有利である。
【０１２７】
Lib_ProcID()関数（Lib_プロセッサＩＤ（）関数）は、モニタが、現在実行中のプロセッサのプロセッサＩＤを取得することを可能にする。
【０１２８】
エラー収集関数
Lib_Collct()関数（Lib_収集（）関数）は、現在実行中のプロセッサにエラー状況が発生したとモニタが判断すると、モニタによって呼び出される。
このルーチンは、すべてのレジスタの情報と、モニタがデフォルトの場合には収集しないそれ以外の情報とを収集する。
この関数により、モニタは、状態の収集が必要なあらゆる「ボックス」特有のレジスタについて知る必要がなくなる。
デフォルトの場合には、ＨＰＭＣおよびＬＰＭＣに対して、この関数は、ファームウェア呼び出しを行い、ある一定のエラー情報を取得する。
【０１２９】
障害分析
LIB_FaultAnal()関数（Lib_障害分析（）関数）は、障害分析に必要とされる中心となる関数である。
すべてのプロセスのすべての情報が収集されると、モニタは、この関数を呼び出す。
この関数は、障害のあるＦＲＵを判断するためにモニタが処理するルールリストを指し示す。
【０１３０】
Mon_Printf(…)関数（Mon_印刷（…）関数）は、モニタがコンソールに印刷することを可能にする。
この関数は、標準的なｐｒｉｎｔｆ呼び出しと同じパラメータのシグネチャを有する。
【０１３１】
Mon_KernelSym(address)関数（Mon_カーネルシンボル（アドレス）関数）は、指定されたアドレスを含むカーネル関数の名前を返す。
【０１３２】
カーネルインターフェース
モニタがそのジョブを行うことができるようにするために、標準的なカーネルに対して、以下のようないくつかの変更を行う必要がある。
【０１３３】
１）モニタ初期化
２）ハートビート機能
３）時限付きセマフォ
４）明示的なモニタ呼び出し
５）ドライバ変更
【０１３４】
これらのカーネルの変更は、モニタが存在しない場合には、モニタへの接触が試みられないように行う必要がある。
モニタが存在する場合、ローダがカーネルを起動すると、ローダは、モニタのトラップハンドラのアドレスをカーネルに渡す。
モニタが存在しない場合、ゼロがカーネルに渡される。
このように、カーネルは、モニタが利用可能かどうかを知る。
【０１３５】
モニタの初期化
Ｒａｇｅカーネルは、ブートを開始したときに、モニタの存在を検出すると、モニタを用いて初期化を行う必要がある。
初期化には、以下のような、ある一定のカーネルの仕様をモニタに指定することが含まれる。
【０１３６】
１）カーネルシンボルテーブル
ローダは、カーネルをロードする時に、カーネルシンボルテーブルもロードする。
モニタが、カーネルのグローバルアドレスのすべてにアクセスするように、このテーブルへのポインタがモニタに与えられる。
これにより、カーネルが立ち上がらない場合であっても、モニタは、カーネルを分析することができる。
【０１３７】
２）特定のタイプのトラップのカーネルルーチン
カーネルは、自身で処理したいすべてのトラップをモニタに指定する。
カーネルは、ある一定のトラップに遭遇した時に呼び出されるルーチンのアドレスを渡さなければならない。
モニタは、そのアドレスを保存し、その結果、トラップが発生した時、モニタは、予め割り当てられた適切なルーチンを呼び出す。
【０１３８】
３）フリーメモリのカーネルの開始
モニタは、フリーメモリのカーネルの開始を知ると、ある一定のエラーが、時間データ構造体または実行時に作成されたデータ構造体をコンパイルするのに関係するかどうかを判断することができる。
フリーメモリの開始に加えて、モニタが、ある一定の実行時の構造体（例えばページアロケータのマップ構造体）の位置を知ることが有益である。
【０１３９】
４）プロセッサの個数
モニタがプロセッサの個数を知る必要があることは明らかである。
これは、例えば、モニタがフリーズしている場合に重要である。
モニタは、プロセッサのすべてがいつチェックインしたかを知る必要がある。
また、モニタは、最初にトラップを発生したプロセッサのハードウェアの問題を回避するためにプロセッサを切り換えたい場合がある。
モニタは、障害発生時に実行されているすべてのプロセスの状態を知りたい。
あらゆるプロセッサがプロセスを実行している可能性があるので、実行中のすべてのプロセッサが判明しなければならない。
モニタは、それ自身でプロセッサの個数を求めることができる。
しかし、この判断は、カーネルによって行なわれる必要があるので、モニタのコードをなぜ複製するのか？  したがって、モニタは、この情報についてはカーネルに依拠する。
【０１４０】
ハートビート機能
ある一定のエラー状況によって、カーネルは、ある種の無限ループから抜け出せなくなる可能性がある。
通常のオペレーティングシステムでは、この種のエラーを診断することは困難である。
理想的には、モニタがハング状況を検出できるように、カーネルは、モニタで周期的に「チェックイン」することが有益である。
モニタの「ハートビート」機能は、まさにこの状況に対して設計される。
ハートビート機能の実施は、マルチプロセッサシステムよりユニプロセッサシステムのほうが難しい。
【０１４１】
ハートビート機能の周期的な性質のため、ハートビート機能の可能性のある候補としては、インターバルタイマインターラプトがある。
プロセッサがタイマインターラプトを発生するごとに、モニタが呼び出される。
モニタは、その時、前回のインターラプトから経過したインターバルタイマのチック数をチェックすることができる。
例えば４つ以上のタイムスライスが経過していると、モニタは、これを、エラー状況の可能性があるとみなす（エラーとみなされるタイムスライスの正確な個数は、カーネルの挙動に基づいてヒューリスティックに求められることに留意されたい）。
モニタは、（ライブラリからルールによって指定される）アドレスキューを調べて、カーネルが、前回のタイマインターラプトの期間中に存在したのと概ね同じ付近で実行されているかどうかを確かめる。
そうである場合には、これにより、モニタは、システムをフリーズさせ、カーネルハングを表示する。
モニタは、次に、このハングをさらに分析することを試みる（すなわち、どのルーチンがハングしているかなどを調べる）。
【０１４２】
マルチプロセッサシステムでは、すべてのプロセッサが同時にハングすることは、あまり起こらない。
したがって、遅かれ早かれ、あるプロセッサがモニタに入ることになる。
その時点で、モニタは、タイマインターラプトを発生したそのプロセッサと共に、他のプロセッサもチェックすることができる。
すべてのプロセッサのインターバルタイマが同期している場合（これは、診断命令を介して実行可能である）、モニタは、他のあるプロセッサが、あまりに長い時間を要したことからモニタで「チェックイン」できなかったかどうかを判断することができる。
モニタの受動的な性質のために、ユニプロセッサシステムは、ハングしても、モニタによって検出されない可能性がある。
カーネルが陥る無限ループが、インターバルタイマインターラプトをオフにし、かつ、他のタイプのトラップもループ内で発生しない場合には、モニタが呼び出されることはない。
【０１４３】
時限付きセマフォ
セマフォ機能は、カーネルがハングし得る、インターラプトのない主要なコード例である。
ユニプロセッサシステムでは、モニタが決して呼び出されないので、このようなハングは特に危険である。
この可能性を削減するには、カーネルのすべてのセマフォ機能が、時限付きになるべきである。
換言すると、すべてのセマフォ機能は、一定の時間の間だけセマフォにアクセスを試みるべきである。
その時間が経過すると、セマフォ機能はモニタを呼び出すべきである。
【０１４４】
明示的なモニタ呼び出し
カーネルは、明示的なモニタ呼び出しを使用してモニタを直接呼び出すことができる。
前述したように、カーネルは、初期化中、モニタを呼び出す。
しかしながら、カーネルが、ある情報をモニタにトレースしてほしい多くの状況が存在し得る。
例えば、どのプロセッサが所与の時刻に特定のセマフォを得たかをモニタが知ることは有益である。
その場合、他のあるプロセッサがそのセマフォでタイムアウトすると、モニタは、どのプロセッサがそのセマフォを得たかを知る。
また、特定のアプリケーションがプロセッサによっていつ実行されているかを、モニタが知ることも有益である。
そのプロセッサがモニタにトラップを発生した場合に、モニタは、分析を行うために、カーネルではなく、アプリケーションシンボルテーブルを使用することを知ることができる。
【０１４５】
カーネルに明示的なモニタ呼び出しを「装備する」ことは、重要な意味を持つ。
これらの明示的な呼び出しにより、カーネルは、モニタが障害分析に使用することができる情報をモニタに渡すことが可能になる。
これは、強力な特徴である。
最も平凡なカーネルは、性能を重視するために、このようには装備されていない。
しかしながら、ＲＡＧＥカーネルは、性能重視を、デバッグを行うためにカーネルの活動をトレースする機能と交換する。
ライブラリのルールは、このトレースを行う特徴を他の特徴と共に使用して、障害分析を行う。
これらの他の特徴には、ＥＬＦフォーマットのシンボルテーブルを使用してルーチンの名前を見つけること、呼び出し時に慣習的に行われる特徴を使用すること、などが含まれる。
この呼び出し時の慣習的に行われる特徴は、サブルーチン呼び出しが、常に、戻りアドレスを有するｇｒ２を使用して行われるという特徴である。
【０１４６】
ドライバの変更
より高速なカーネルブートを容易にするには、カーネルのドライバの多くを変更しなければならない場合がある。
多くのＩ／Ｏカードを有する大規模システムでは、すべてのＩ／Ｏデバイスの初期化を必要とすることから、カーネルのブートは長くなることがある。
これまでのカーネルは、ユーザがコンソールと対話できる前に、すべてのＩ／Ｏデバイスを確実に初期化する。
しかしながら、ＲＡＧＥでは、Ｉ／Ｏの初期化が遅れても構わない。
コアの不可欠なものを除くすべてのドライバは、ＬＩＮＵＸモジュールにすることができる。
したがって、それらの初期化が遅れても、ユーザは、コンソールにアクセスすることができ、初期化されていないＩ／Ｏを必要としないＲＡＧＥアプリケーションを起動することができる。
それらのモジュールが初期化されると、ＲＡＧＥアプリケーションを起動して、それらのモジュールに関連したＩ／Ｏにストレスを加えることができる。
ＲＡＧＥ  Ｉ／Ｏを詳細にすることは、第２のＲＡＧＥ開発段階の一部である。
ＲＡＧＥ  Ｉ／Ｏの検討が完了すると、関連した検討報告により、ＲＡＧＥ  Ｉ／Ｏのより詳細な内容が与えられることになる。
【０１４７】
＜性能の考慮＞
モニタの介入は、カーネルの性能をある程度低下させるが、ＲＡＧＥアプリケーションのストレスの影響を削減するほど大幅にカーネルを劣化させるべきではない。
【０１４８】
＜モジュールの詳細＞
エラー状況が発生し、エラー情報が収集されると、モニタは、障害分析を開始する必要がある。
これを行うために、モニタは、ルールベースのエキスパートシステムの方法論を使用する。
そのルールは、ライブラリモジュールに配置される。
概念的には、各ルールは、以下のように見える。
【０１４９】
ＩＦ（条件０）（条件１）…（条件Ｎ）  ＴＨＥＮ（動作０）（動作１）…（動作Ｎ）
【０１５０】
ライブラリモジュールには、このようなルールのセットが存在する。
ルールは、ルールの処理を高速にするように順序付けられる。
換言すると、先にトリガされる可能性の高いルールは、ルールリストの開始に近い箇所に配置される。
障害分析を開始するために、ルールリストの各ルールが、順次、評価される。
ルールの「ＩＦ」部の条件は、実際には、関数ポインタである。
指し示される各関数は、０または非ゼロの値のいずれかを返す。
ゼロは、「ＦＡＬＳＥ（偽）」の条件を表す。
ルールが評価されている際、条件が非ゼロであると、その条件は関数ポインタである。
次に、その関数が実行され、その結果がチェックされる。
関数の戻り値がゼロである場合、そのルールの別の条件はもはや評価されない。
この場合、そのルールは、ＮＯＴ−ＴＲＩＧＧＥＲＥＤ（トリガされない）と言われる。
さらに、条件のいずれかがゼロである（すなわち、その関数ポインタが「ＮＵＬＬ（ヌル）」である）場合、その条件は、ＦＡＬＳＥとみなされる。
したがって、そのルールも、ＮＯＴ−ＴＲＩＧＧＥＲＥＤである。
【０１５１】
あるルールのすべての条件が非ゼロの値を返す場合、そのルールは、ＴＲＩＧＧＥＲＥＤ（トリガされる）と言われる。
モニタは、ＴＲＩＧＧＥＲＥＤのルールに到達するまで、ルールリストの各ルールの評価を続ける。
ルールのいずれもがＴＲＩＧＧＥＲＥＤでない場合、モニタは、この状況を表示して停止する。
そうでない場合、モニタは、ＴＲＩＧＧＥＲＥＤルールによって指定された動作のそれぞれを実行することを試みる。
あるルールがＴＲＧＧＥＲＥＤされると、モニタは、ルールリストの他のどのルールも評価しない。
また、トリガされたルールは、再びＴＲＩＧＧＥＲＥＤできないように無効にされる。
この特徴は、ルール処理を高速化するために意図されたものである。
【０１５２】
ルールの動作も、関数ポインタである。
モニタは、ＴＲＲＩＧＧＥＲＥＤされたルールの各動作の関数を呼び出す。
各動作関数は、最初のものから順次、呼び出される。
動作関数のすべてが呼び出されると、モニタは、そのルールを無効にし、次に、ルールリストの最初から開始して、次のＴＲＩＧＧＥＲＥＤルールを探す。
ルールがどのように見えるかの例についての上記データ構造の節を参照されたい。
【０１５３】
各ルールは、基本的には、そのルールが行おうとすることを記述した短いテキスト文字列を有するべきである。
この特徴により、モニタは、分析中、どのようにしてその結論を出したかを初心者のユーザに英語で表示することが可能になる。
【０１５４】
モニタが障害のあるＦＲＵを判断するために利用できる、いくつかのデバッグの特徴として、以下のものがある。
【０１５５】
カーネルシンボルテーブル
カーネルは、ＥＬＦ−６４バイナリである。
したがって、カーネルには、そのシンボルテーブルがバイナリで組み込まれている。
ライブラリのルールは、この特徴を使用して、カーネル内のエラー発生箇所を判断することができる。
また、アプリケーションも、ＥＬＦ−６４フォーマットにコンパイルされる。
したがって、同じ技法を使用することができる。
例えば、シンボルテーブルは、バイナリで含まれた関数の全開始アドレスを含むので、特定のプロセッサが障害を起こしたアドレスが判明すると、そのプロセッサがその時に実行していた関数をシンボルテーブルから判断することができる。
【０１５６】
プロシージャスタックの巻き戻し
モニタは、スタックの巻き戻しを利用して、プロシージャを過去に遡ってトレースすることができる。
【０１５７】
説明したように、上記例示的な実施態様は、本発明の原理による診断モニタの実施態様の１つの特定の例にすぎない。
したがって、この発明について、いくつかの好ましい実施の形態によって説明してきたが、この発明の範囲内に入る変更、並べ替え、および均等物が存在する。
また、本発明の方法および装置を実施する多くの別の方法が存在することにも留意すべきである。
したがって、添付された特許請求項は、本発明の真の精神および範囲内に入るようなすべての変更、並べ替え、および均等物を含むものとして解釈されることが意図されている。
【図面の簡単な説明】
【０１５８】
【図１】本発明の一実施の形態による、診断を受けるコンピュータハードウェアと診断実行器とを含む診断環境を示す図である。
【図２】本発明の一実施の形態による診断モニタをより詳細に示す図である。
【図３Ａ】本発明の一実施の形態による初期化におけるロードシーケンスを示す図である。
【図３Ｂ】本発明の一実施の形態による初期化におけるロードシーケンスを示す図である。
【図４Ａ】本発明の一実施の形態による、診断モニタによりコンピュータシステムの性能を診断する論理フローを示す図である。
【図４Ｂ】本発明の一実施の形態による、診断モニタによりコンピュータシステムの性能を診断する論理フローを示す図である。
【図５】本発明の一実施の形態による、カーネルパニックを処理するステップを示す図である。
【図６】本発明の一実施の形態による、診断アプリケーションによりモニタ呼び出しを処理するステップを示す図である。
【図７】本発明の一実施の形態による、診断アプリケーションによりエラー呼び出しを処理するステップを示す図である。
【図８】本発明の例示的な一実施態様による、ＲＡＧＥ実行器プラットフォームを構成する基本モジュールを示す図である。
【図９】本発明の例示的な一実施態様による、ローダの基本機能を示す図である。
【図１０】本発明の例示的な一実施態様による、モニタの主要なコンポーネントを示す図である。
【符号の説明】
【０１５９】
１０２・・・コンピュータハードウェア、
１０４・・・診断実行器、
１０５・・・ローダ、
１０６・・・診断カーネル、
１１０・・・モニタロジック、
１１２・・・モニタライブラリ、
１１４・・モニタトラップテーブル、
１３０・・・ＣＰＵアプリケーション、
１３２・・・メモリアプリケーション、
１３４・・・Ｉ／Ｏアプリケーション、
１３６・・・他のアプリケーション、
１１０・・・モニタロジック、
１１２・・・モニタライブラリ、
１１４・・・モニタトラップテーブル、
２１０・・・アーキテクチャルーチン、
２１２・・・ルールエンジン、
２１４・・・モニタコード、
２２０・・・ルール、
２２２・・・ハードウェア特有ルーチン、
２２４・・・ライブラリコード、
【図１】
2004259258.tif 000003
【図２】
2004259258.tif 000004
【図３Ａ】
2004259258.tif 000005
【図３Ｂ】
2004259258.tif 000006
【図４Ａ】
2004259258.tif 000007
【図４Ｂ】
2004259258.tif 000008
【図５】
2004259258.tif 000009
【図６】
2004259258.tif 000010
【図７】
2004259258.tif 000011
【図８】
2004259258.tif 000012
【図９】
2004259258.tif 000013
【図１０】
2004259258.tif 000014