(57)【要約】【課題】  コンピュータシステムが製品ＯＳを使用してユーザアプリケーションを実行する際に、コンピュータシステムを監視する。【解決手段】  この方法は、診断モニタを設けることであって、たとえＯＳカーネルが実行できない場合であっても実行することができるように構成され、かつ、モニタトラップ装置を有する、診断モニタを設けることを含む。ユーザアプリケーションの実行中にトラップが発生した場合に、この方法は、当前記トラップがＯＳカーネルによってハンドリングされるべきか、または診断モニタによってハンドリングされるべきかを、診断モニタを使用して確認することを含む。トラップが、ＯＳカーネルによってハンドリングされるべきである場合に、この方法は、トラップをＯＳカーネルに渡すことであって、それによって、ハンドリングさせる、トラップをＯＳカーネルに渡すことを含む。【選択図】図８
2005032247.tif 000002
【特許請求の範囲】
【請求項１】
コンピュータシステム（８０２）が、カーネルトラップ装置を備えたＯＳカーネル（８０６）を有する製品オペレーティングシステム（ＯＳ）を使用してユーザアプリケーション（８３０）を実行する際に、前記コンピュータシステム（８０２）を監視するコンピュータ実施される方法であって、
前記ＯＳカーネル（８０６）が実行できない場合であっても実行することができるように構成され、モニタトラップ装置（８１４）を有する診断モニタ（８０８）を設けることと、
前記ユーザアプリケーションの実行中にトラップが発生した（encounter）場合に、前記トラップが前記ＯＳカーネル（８０６）によってハンドリングされるべきか、前記診断モニタ（８０８）によってハンドリングされるべきかを、前記診断モニタを使用して確認する（１００２）ことと、
前記トラップが前記ＯＳカーネルによってハンドリングされるべきである場合に、前記トラップを前記ＯＳカーネルに渡す（１００４）してハンドリングさせることと
を含む方法。
【請求項２】
前記ＯＳカーネル（８０６）は、前記ユーザアプリケーション（８３０）を実行するように構成された製品カーネルである
請求項１に記載のコンピュータ実施される方法。
【請求項３】
前記ＯＳカーネル（８０６）は、前記ＯＳカーネルをロードする（３０８）前に前記診断モニタを初期化する（３３２）ことを可能にするように構成される
請求項２に記載のコンピュータ実施される方法。
【請求項４】
前記トラップが前記診断モニタ（８０８）によってハンドリングされるべきである場合に、前記トラップが前記ＯＳカーネルによるモニタ呼び出しを表しているかどうかを、前記診断モニタを使用して確認する（１００６）ことと、
前記トラップが前記ＯＳカーネルよる前記モニタ呼び出しを表している場合に、前記診断モニタを使用し（１０４０）、前記モニタ呼び出しをハンドリングすることと
をさらに含む請求項１に記載のコンピュータ実施される方法。
【請求項５】
前記トラップが前記モニタ呼び出しを表していない場合に、前記診断モニタを使用することであって、
ａ）前記コンピュータシステムの他のあらゆるプロセッサにフリーズ信号を送出する（１０１０）ことと、
ｂ）状態情報を収集する（１０１２）ことと、
ｃ）前記状態情報の分析を実行する（１０１４）ことと
を行うこと
をさらに含む請求項４に記載のコンピュータ実施される方法。
【請求項６】
前記トラップが前記モニタ呼び出しを表していない場合に、前記診断モニタを使用することであって、
ｄ）前記分析の結果をシェルに表示する（１０１６）ことと、
ｅ）前記シェルからのユーザ入力がある場合には、前記ユーザ入力を受け取る（１０１８）ことと
を行うこと、
をさらに含む請求項５に記載のコンピュータ実施される方法。
【請求項７】
前記ＯＳカーネル（８０６）を使用して、パニック呼び出しをモニタ呼び出しに変換することと、
前記モニタ呼び出しが前記診断モニタ（８０８）によって受け取られると、前記モニタ呼び出しが、前記パニック呼び出しを表しているのかどうかを、前記診断モニタ（８０８）を使用して確認することと、
前記モニタ呼び出しが前記パニック呼び出しを表している場合に、前記診断モニタを使用することであって、
ａ）前記コンピュータシステムの他のあらゆるプロセッサにフリーズ信号を送出する（１１０２）ことと、
ｂ）状態情報を収集する（１１０４）ことと、
ｃ）前記状態情報の分析を実行する（１０１６）ことと
を行うことと
をさらに含む請求項１に記載のコンピュータ実施される方法。
【請求項８】
前記モニタ呼び出しが、前記パニック呼び出しを表している場合に、前記診断モニタを使用することであって、
ｄ）前記分析の結果をシェルに表示する（１１０８）ことと、
ｅ）前記シェルからのユーザ入力がある場合には、前記ユーザ入力を受け取る（１１１０）ことと
を行うこと
をさらに含む請求項７に記載のコンピュータ実施される方法。
【発明の詳細な説明】
【技術分野】
【０００１】
［関連出願］
本出願は、本発明の譲受人に譲渡された同時係属中の、発明者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）の設定または訂正可能エラー情報を返すこと）を実行するように要求中である。
次いで、モニタは、この機能を実行し、アプリケーションに戻る。
【０２１５】
上述したように、深刻なエラーのみが、製品カーネルと協働して実行されている診断モニタによってハンドリングされることが好ましい。
ＨＰＭＣ（ＰＡＲＩＳＣ（商標））またはＭＣＡ（ＩＰＦ（商標））は、明示的なタイプのトラップを引き起こす深刻なエラーの例を表す。
深刻であるが、トラップを引き起こさないタイプのエラーの例としては、例えば、セマフォのタイムアウトがある。
セマフォのタイムアウトでは、或るプロセッサが、或る一定の閾値よりも長い時間の間、セマフォを捕らえており、この状況は、ハングが差し迫っていることを示す。
この場合、セマフォは、例えばタイムアウトすることができ、その結果、モニタへの呼び出しが行われる。
一般的に言うと、診断モニタは、カーネルパニックを取り扱うのと同じ方法で深刻なエラーモニタ呼び出しを取り扱う。
カーネルパニックをハンドリングするステップは、本出願の図１１と共に説明する。
【０２１６】
トラップが明示的なモニタ呼び出しでない場合（ブロック１００６において判断）、そのトラップは、深刻なエラーとみなされる。
一例として、カーネルブートの失敗は、深刻なエラーである。
上述したように、深刻なハードウェアエラーは、診断モニタがハンドリングする深刻なエラーの１つの分類である。
ＩＰＦ（商標）では、例えば、マシンチェックアボート（ＭＣＡ）の状況の発生は、通常、深刻なエラーとみなされる。
ＰＡＲＩＳＣ（商標）では、例えば、高優先度マシンチェック（ＨＰＭＣ）状況の発生は、通常、深刻なエラーとみなされる。
一般的に言うと、各アーキテクチャは、深刻なエラーを表すそれ自身の方法を有する。
しかしながら、エラーの詳細は、ボックスのタイプが異なると変化し得る。
例えば、エラーが深刻なものである場合に、プロセッサの所与のハードウェアレジスタの１ビットがセットされることがある。
一般的に言うと、エラーの詳細は、ルールを使用して確認することができる。
【０２１７】
深刻なエラーの場合、診断モニタは、インターラプト信号を他のすべてのプロセッサ（複数のプロセッサが存在すると仮定する）に送出することにより、カーネルの実行を停止する。
例えば、或るプロセッサが深刻なエラー（例えばＰＡＲＩＳＣ（商標）の場合のＨＰＭＣ）を受ける可能性があるが、コンピュータシステムの他のプロセッサは、同じ深刻なエラーを受けないことがある。
外部インターラプト信号によってそれらのプロセッサをフリーズさせることにより、それらのプロセッサの状態をブロック１０１２において収集して、ブロック１０１４における分析を容易にすることができる。
もちろん、システムに１つのプロセッサしか存在しない場合には、存在しない他のプロセッサにインターラプト信号を送出する必要はなく、この場合には、ブロック１０１０は必要ない。
【０２１８】
ブロック１０１４では、例えば、モニタライブラリの特定ハードウェア向けルーチン（図８の８２２）を使用して、エラー分析を行うことができる。
特定ハードウェア向けルーチンは、プロセッサのさまざまなレジスタ、Ｉ／Ｏレジスタ、カーネルの一定のデータ構造体等を検査して、エラーおよび／またはエラーの原因を確認することができ、そのエラーを１つまたは２つ以上のＦＲＵ（フィールド交換可能ユニット）に絞り込むことができることが好ましい。
例えば、分析は、特定のＣＰＵが、不具合を有し、交換の必要があることを正確に示すことができる。
その分析結果は、ブロック１０１６において表示される。
一実施の形態では、その結果は、ＯＳのシェルとは別のモニタシェルに表示することができる。
モニタシェルは、一定の診断に関連した入力および出力を可能にし、ＯＳがクラッシュした場合であっても動作し続けることができる。
例えば、モニタシェルを使用して、一定のカーネルデータ構造体およびルーチンを指定することができ、検査用にそれらを表示するように指定できる。
このことは、図１０のブロック１０１８に表されている。
【０２１９】
モニタのルールおよびルールエンジンによって、モニタは、関連する（場合によっては特定ボックス向けの）レジスタと、カーネルのデータ構造体（必要ならば）とを分析することが可能になり、その問題を、例えば、障害のあるＦＲＵに絞り込むことが可能になることに留意されたい。
これは、標準的なＯＳを使用する従来技術の状況とは著しく異なる。
従来技術の状況では、経験豊富なユーザまたはエキスパートが、カーネルによってダンプされたデータを手動で分析しなければならないことになる。
【０２２０】
さらに、モニタは、すべてのシステムおよびカーネルデータにアクセスすることができる。
それによって、モニタは、エラー検出タスクおよびエラー分析タスクを正確に実行するために必要なあらゆる情報を確実に取得することができる。
例えば、一実施の形態では、カーネルのマップファイルは、グローバルなカーネル変数のアドレスおよびカーネル関数アドレスを含むことができ、これらのすべてが、モニタによってアクセス可能である。
これと異なり、カーネルによってダンプされたデータは、場合によっては、エラー分析に必要なすべてのデータを含まないことがある。
【０２２１】
カーネルパニックがトラップなしで発生するときがある。
例えば、カーネルは、リソース（例えばメモリ）の外部で実行されたり、解決できない問題（例えば解決不能なページフォルト）に直面したりする或る違法な状況に遭遇していることがある。
この場合、カーネルは、パニック呼び出しを行っていることがある。
このパニック呼び出しは、変更された製品カーネルによってモニタ呼び出しに変換され、それによって、診断モニタが関与することが可能になる。
一方、カーネルパニックに関係したモニタ呼び出しは、そのモニタ呼び出しを、カーネルパニックの結果により発生したものと特定する情報を含む。
パニックに関係したモニタ呼び出しが受け取られると、このモニタ呼び出しは、図１１のブロック１１０２〜１１１０においてハンドリングされる。
ブロック１１０２〜１１１０は、図１０Ｂのブロック１０１０〜１０１８によって実行されるのと類似の形式でエラーハンドリングを実行する。
【０２２２】
上記から分かるように、独立したバイナリとして動作する本発明の診断モニタを製品カーネルと協働して使用することにより、本発明の診断モニタは、カーネルクラッシュの場合またはカーネルがロードされない場合であっても、エラー分析を行うことができる。
【０２２３】
モニタが深刻なエラーのケースにのみ必要とされ、通常の実行中に発生する深刻でないエラー（例えば、ページフォルト、訂正可能な単一ビットのメモリエラー）のハンドリングに使用されないことから、システムの性能に対する負の影響も削減される。
通常の実行の期間中は、説明される３つのケース（例えば、深刻なハードウェアエラー、カーネルパニック、タイムアウトしたセマフォ）のいずれも発生せず、したがって、システムの性能に対するモニタの影響は最小限に抑えられる。
【０２２４】
上述したように、上記例示の実施態様は、本発明の原理による診断モニタの実施態様の一具体例にすぎない。
したがって、この発明について、いくつかの好ましい実施の形態の観点から説明してきたが、この発明の範囲内に入る変更、並べ替え、および均等物が存在する。
また、本発明の方法および装置を実施する多くの代替的な方法が存在することにも留意すべきである。
したがって、添付した特許請求の範囲は、本発明の真の精神および範囲内に入るすべての変更、並べ替え、および均等物を含むものとして解釈されることが意図されている。
【図面の簡単な説明】
【０２２５】
【図１】診断を受けるコンピュータハードウェアと診断実行装置とを含む診断環境を、本発明の一実施の形態に従って示す図である。
【図２】診断モニタを、本発明の一実施の形態に従ってより詳細に示す図である。
【図３Ａ】初期化におけるロードシーケンスを、本発明の一実施の形態に従って示す図である。
【図３Ｂ】初期化におけるロードシーケンスを、本発明の一実施の形態に従って示す図である。
【図４Ａ】診断モニタによってコンピュータシステムの性能を診断する論理フローを、本発明の一実施の形態に従って示す図である。
【図４Ｂ】診断モニタによってコンピュータシステムの性能を診断する論理フローを、本発明の一実施の形態に従って示す図である。
【図５】カーネルパニックをハンドリングするステップを、本発明の一実施の形態に従って示す図である。
【図６】診断アプリケーションによってモニタ呼び出しをハンドリングするステップを、本発明の一実施の形態に従って示す図である。
【図７】診断アプリケーションによってエラー呼び出しをハンドリングするステップを、本発明の一実施の形態に従って示す図である。
【図８】製品ＯＳと共に本発明の診断モニタを使用する診断装置を、本発明の一実施の形態に従って示す図である。
【図９】図８の診断モニタを、本発明の一実施の形態に従ってより詳細に示す図である。
【図１０Ａ】診断モニタによるエラーハンドリングステップを、本発明の一実施の形態に従って示す図である。
【図１０Ｂ】診断モニタによるエラーハンドリングステップを、本発明の一実施の形態に従って示す図である。
【図１１】パニックに関係したモニタ呼び出しをハンドリングするステップを、本発明の一実施の形態に従って示す図である。
【図Ａ１】ＲＡＧＥ実行装置プラットフォームを構成する基本モジュールを、本発明の例示の一実施態様に従って示す図である。
【図Ａ２】ローダの基本機能を、本発明の例示の一実施態様に従って示す図である。
【図Ａ３】モニタの主要なコンポーネントを、本発明の例示の一実施態様に従って示す図である。
【符号の説明】
【０２２６】
１０２・・・コンピュータハードウェア、
１０４・・・診断実行装置、
１０５・・・ローダ、
１０６・・・診断カーネル、
１１０・・・モニタロジック、
１１２・・・モニタライブラリ、
１１４・・・モニタトラップテーブル、
１３０・・・ＣＰＵアプリケーション、
１３２・・・メモリアプリケーション、
１３４・・・Ｉ／Ｏアプリケーション、
１３６・・・他のアプリケーション、
２１０・・・アーキテクチャルーチン、
２１２・・・ルールエンジン、
２１４・・・モニタコード、
２２０・・・ルール、
２２２・・・特定ハードウェア向けルーチン、
２２４・・・ライブラリコード、
８０２・・・コンピュータハードウェア、
８０５・・・ローダ、
８０６・・・製品カーネル、
８１０・・・モニタロジック、
８１２・・・モニタライブラリ、
８１４・・・モニタトラップテーブル、
８３０，８３２，８３４，８３６・・・ユーザアプリケーション、
９１０・・・アーキテクチャルーチン、
９１２・・・ルールエンジン、
９１４・・・モニタコード、
９２０・・・ルール、
９２２・・・特定ハードウェア向けルーチン、
９２４・・・ライブラリコード、
【図１】
2005032247.tif 000003
【図２】
2005032247.tif 000004
【図３Ａ】
2005032247.tif 000005
【図３Ｂ】
2005032247.tif 000006
【図４Ａ】
2005032247.tif 000007
【図４Ｂ】
2005032247.tif 000008
【図５】
2005032247.tif 000009
【図６】
2005032247.tif 000010
【図７】
2005032247.tif 000011
【図８】
2005032247.tif 000012
【図９】
2005032247.tif 000013
【図１０Ａ】
2005032247.tif 000014
【図１０Ｂ】
2005032247.tif 000015
【図１１】
2005032247.tif 000016
【図Ａ１】
2005032247.tif 000017
【図Ａ２】
2005032247.tif 000018
【図Ａ３】
2005032247.tif 000019
【外国語明細書】
IMPROVED DIAGNOSTIC MONITOR FOR USE WITH AN OPERATING SYSTEM AND METHODS THEREFOR By Inventor John W. Curry 
Related Applications The present application claims priority under 35 USC 120 to a co-pending, commonly-assigned US Application No. 10/376,436 entitled "IMPROVED DIAGNOSTIC EXERCISER AND METHODS THEREFOR" filed February 27, 2003 by inventor John W. Curry.
BACKGROUND OF THE INVENTION
As computers and operating systems become more complex, failure and performance analysis become more difficult. For reliability reasons, it is highly desirable to exhaustively test computer systems prior to introducing them into service. Generally speaking, it is possible to create codes to test specific portions of the computer system hardware. However, such narrowly focused tests do not stress the entire computer system as a whole, and do not reflect the way in which the computer system tends to be used in the field.
Another approach involves employing diagnostic tools, such as diagnostic
exercisers, that execute under operating systems to detect errors. Nowadays, diagnostic exercisers are typically designed to execute under a production operating system ("OS"), e.g., Linux, HPUXTM (Hewlett-Packard Company, Palo Alto, CA) or
Windows (Microsoft Corporation, Redmond, WA), and the like. By employing specifically designed applications that use special drivers and/or operating system calls, diagnostic exercisers executing under a production OS can stress the computer system in specific ways and detect certain errors when they occur. Because these diagnostic exercisers employ the OS, their applications can stress the hardware more fully and in ways that are more similar to the way the computer system would be used in the field, e.g., involving features such as multi-threading, rapid disk I/O operations, and the like.
In general, the amount of stress experienced by the computer system can vary depending on which diagnostic exerciser applications are being executed. When a given diagnostic exerciser executes under a production operating system, such diagnostic exerciser is however restricted in capabilities by the operating system. For example, due to competitive reasons, production operating systems tend to be optimized for performance in the field and not for extensive diagnostic capabilities.
Thus, a diagnostic exerciser executing under such a production OS tends to be restricted in its diagnostic capability. Analogously, other features useful for data gathering, error detection, and error analysis may not be available in a production OS since the provision of such features would unduly hamper OS performance and/or compromise the security of the computer system in the field.
Furthermore, most diagnostic exercisers executing under a production OS tend to run as privileged processes and/or drivers. This fact tends to limit their usefulness in a kernel crash situation. For example, if the kernel crashes during kernel booting, the common diagnostic monitor of the prior art diagnostic exerciser would not have been started, thereby being of little value for the detection and analysis of kernel boot failures.
Additionally, when the kernel crashes, most common diagnostic techniques involve obtaining a kernel dump and analyzing the kernel dump data. However, such diagnostic techniques are inherently limited by the information saved in the kernel dump file. If the programmer who originally designed the kernel dump program decided not to save certain information, such information will not be available in the kernel dump file for analysis. Furthermore, the content and format of the information available in the kernel dump file may vary depending on the discretion of the programmer who originally designed the kernel dump. Accordingly, the kernel dump information may be difficult to decipher, and it may be necessary to find the programmer who originally designed the kernel to obtain assistance in analyzing the kernel dump file. If a long period of time has elapsed between the time the OS is produced and the time a particular error occurs that results in the kernel dump, the programmer may no longer be available to assist, and the use of kernel experts maybe required to sift through the kernel dump data.
SUMMARY OF THE INVENTION
The invention relates, in one embodiment, to a computer-implemented method for monitoring a computer system when the computer system executes a user
application using a production operating system (OS). The OS has a OS kernel with a kernel trap arrangement. The method includes providing a diagnostic monitor, the diagnostic monitor being configured to be capable of executing even if the OS kernel fails to execute, the diagnostic monitor having a monitor trap arrangement. If a trap is encountered during execution of the user application, the method includes ascertaining using the diagnostic monitor whether the trap is to be handled by the OS kernel or the diagnostic monitor. If the trap is to be handled by the OS kernel, the method includes passing the trap to the OS kernel for handling. 
In another embodiment, the invention relates to an arrangement, in a computer system,for diagnosing a computer system while executing a user application program.
The user application program is executed under a production operating system (OS) kernel. The arrangement includes a diagnostic monitor configured to execute cooperatively with the OS kernel, the OS kernel having a kernel trap arrangement for handling at least one of a trap-type message and an interrupt-type message generated during the execution of the application program, the diagnostic monitor being capable of continuing to execute even if the OS kernel fails to execute. The diagnostic monitor includes a monitor trap arrangement for handling at least one of the trap-type message and the interrupt-type message. The diagnostic monitor is configured to receive traps generated during the execution of the application program and decide, for a given trap received, whether the OS kernel would handle the trap received or whether the diagnostic monitor would handle the trap received.
In yet another embodiment, the invention relates to an article of manufacture comprising a program storage medium having computer readable code embodied
therein, the computer readable code being configured to handle errors in a computer system. The article of manufacture includes computer readable code implementing a diagnostic monitor. The diagnostic monitor is configured to execute cooperatively with a production operating system (OS) kernel in the computer system and configured to be able to execute even if the OS kernel fails to execute. The diagnostic monitor includes a monitor trap arrangement configured to receive traps generated in the computer system. The OS kernel has a kernel trap arrangement configured to handle traps passed from the diagnostic monitor. The article of manufacture includes computer readable code for loading the diagnostic monitor at system startup prior to loading the OS kernel.
These and other features of the present invention will be described in more detail below in the detailed description of the invention and in conjunction with the following figures.
BRIEF DESCRIPTION OF THE DRAWINGS
The present invention is illustrated by way of example, and not by way of limitation, in the figures of the accompanying drawings and in which like reference numerals refer to similar elements and in which:
Fig. 1 illustrates, in accordance with one embodiment of the present invention, a diagnostic environment that includes computer hardware under diagnostic, and a diagnostic exerciser.
Fig. 2 illustrates the diagnostic monitor in greater detail in accordance with one embodiment of the present invention.
Fig. 3 illustrates, in accordance with one embodiment of the present invention, the loading sequence upon initialization.
Figs. 4A and 4B illustrate, in accordance with one embodiment of the present invention, the logic flow for diagnosing the performance of a computer system by the diagnostic monitor.
Fig. 5 illustrates, in accordance with one embodiment of the present invention, the steps for handling a kernel panic.
Fig. 6 illustrates, in accordance with one embodiment of the present invention, the steps for handling a monitor call by a diagnostic application.
Fig. 7 illustrates, in accordance with one embodiment of the present invention, the steps for handling an error call by a diagnostic application.
Fig. 8 depicts, in accordance with one embodiment of the present invention, a diagnostic arrangement that employs the inventive diagnostic monitor in conjunction with a production OS.
Fig. 9 illustrates the diagnostic monitor of Fig. 8 in greater detail inaccordance with one embodiment of the present invention.
Figs. 10A and 10B illustrate, in accordance with one embodiment of the present invention, the error handling steps by the diagnostic monitor.
Fig. 11 illustrates, in accordance with one embodiment of the present invention, the steps for handling a panic-related monitor call.
Fig. A1 shows, in accordance with one exemplary implementation of the present invention, the basic modules that make up the RAGE exerciser platform.
Fig. A2 shows, in accordance with one exemplary implementation of the present invention, the basic functionality of the loader.
Fig. A3 shows, in accordance with one exemplary implementation of the
present invention, the major components of the Monitor.
DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS
The present invention will now be described in detail with reference to a few preferred embodiments thereof as illustrated in the accompanying drawings. In the following description, numerous specific details are set forth in order to provide a thorough understanding of the present invention. It will be apparent, however, to one skilled in the art, that the present invention may be practiced without some or all of these specific details. In other instances, well known process steps and/or structures have not been described in detail in order to not unnecessarily obscure the present invention.
In accordance with one embodiment of the present invention, there are provided diagnostic arrangements and techniques that combine the advantages offered by the pure off-line diagnostic approach, e.g., extensive access to and control of the computer hardware and ease of error detection and analysis, with the advantages offered by the on-line OS-based diagnostic approach, e.g., the ability to stress the hardware more fully and in ways that are more representative of the stress experienced by the computer hardware in the field.
As the terms are employed herein, a diagnostic tool is said to be off-line if it does not employ a production OS in its diagnostic tasks. Off-line diagnostic tools can have extensive access to and/or control of the individual hardware subsystems but their diagnostic approach tends to be based on localized stimulus-responses.
Stimulus-response tests based on off-line diagnostic tools have been known to be unsuitable for efficiently detecting certain transient errors.
Further, the off-line diagnostic tools do not stress the computer system hardware in a comprehensive way nor do they stress the computer system hardware in ways that are representative of the stress experienced by the computer hardware in the field. Accordingly, it has been necessary to employ a large number of stimuli (and a large number of permutations thereof) in order ensure that tests performed cover most of the scenarios that the subsystems under test would likely experience in the field.
On the positive side, since off-line diagnostic tools tend to test individual subsystems of the computer system hardware based on stimulus-response tests and without having the OS acting as the intermediary, extensive access to and/or control of the hardware functionality is possible and error isolation and analysis tend to be less complex.
In contrast, a diagnostic tool is said to be on-line if it employs the production OS in its diagnostic task. When the diagnostic applications execute under the OS, control of the hardware is achieved in a less direct manner and access to hardware is much more restricted. However, the on-line diagnostic applications can more fully stress the computer system as a whole, employing OS-related features such as multithreading, rapid I/O accesses, and the like. Because the on-line diagnostic applications execute under the OS, the computer system tends to be stressed in ways that are more similar to those experienced by the computer hardware in the field.
Furthermore, the time spent in testing can be shorter with an on-line diagnostic tool since the tests can be more directed toward the likely and/or realistic usage scenarios instead of, as in the case with the off-line diagnostic exerciser, randomly testing various permutations, some of which may be unrealistic and/or may never be experienced by the computer system in the field.
The additional capabilities of on-line diagnostic tools, however, come at the cost of inflexibility and complexity. Since existing OS-based diagnostic tools tend to execute under a production OS (i.e., the OS employed in the field), security and performance considerations severely limit the diagnostic and/or analytical capabilities of the existing OS-based diagnostic tools. Depending on the design of the OS and/or the OS kernel, certain types of information may not be captured and/or be accessible for error detection and/or error analysis. Access to and/or control of the hardware may be severely restricted. Even if the information is captured, information such as kernel dump may be difficult to analyze to ascertain the source of error. OS-based diagnostic tools also tend to be difficult to isolate, in a concise way, the source of the error.
As mentioned earlier, embodiments of the inventive diagnostic exerciser combine the advantages offered by a pure off-line diagnostic approach with the advantages offered by the on-line OS-based diagnostic approach. To fully exercise the hardware system and achieve more directed testing of the computer system using tests that are more representative of the way the computer system is employed in the field, the diagnostic exerciser employs the OS. However, the OS employed is a nonproduction OS based on a diagnostic kernel. The use of a non-production OS and more particularly a non-production kernel modified to enhance diagnostic capabilities advantageously allows the invention to avoid the limitations of the production OS, which limitations are imposed based on, for example, security and/or performance reasons. Since diagnostic testing is performed in a controlled, non-production environment, security and performance in the field considerations are less important.
Furthermore, a diagnostic monitor is provided to monitor and to work cooperatively with the non-production kernel. As the term is employed herein, the diagnostic monitor is said to execute cooperatively with the non-production kernel since it does not operate under the non-production kernel. There are furnished, in accordance with certain embodiments of the invention, rule-based facilities to provide failure analysis in an easy to understand manner. Inventive techniques are employed to facilitate failure analysis even if the kernel crashes during booting or during execution of the diagnostic application programs.
In a preferred embodiment, a diagnostic monitor having detailed information about the kernel (i.e. data structures, kernel data locations, etc) is loaded into a memory area that is not used by the OS. The diagnostic monitor is loaded prior to kernel loading and booting and has control of the trap vector table. During the kernel boot, or while the kernel (i.e. OS) is running, any traps or interrupts that occur would be examined by the diagnostic monitor to determine how the traps or interrupts should be handled.
To elaborate, the trap/interrupt mechanism of modern computer architectures allows privileged code to run when certain conditions occur. Depending on the
particular architecture, these conditions include certain hardware events and some software generated events. The trap/interrupt-based mechanism is exploited by the inventive diagnostic monitor to facilitate error detection as well as data collection and analysis pertaining to certain errors.
In general, all non-error traps would be passed by the diagnostic monitor to the normal kernel vector table. Otherwise, the diagnostic monitor would examine the trap information, along with any information it can gather from the kernel data structures in memory, and use this information for error isolation. Kernel panics may cause forced traps to the diagnostic monitor. For many architectures, process, timeslice events may cause non-error traps. These can be used by the diagnostic monitor to "monitor" hardware and kernel parameters at run-time. For example, if a CPU has a time-slice trap, the diagnostic monitor can determine whether or not that CPU was idle by examining the process data structure associated with the process being run on that CPU. If the CPU is idle, the diagnostic monitor can use it to check for errors.
Once the checking is done, the CPU would be returned to its idle loop. In this way, the diagnostic monitor can lower its performance impact on the kernel.
In most common operating systems, semaphores are not timed. That is to say, if a kernel thread attempts to grab some semaphore, it will do so forever until it obtains the semaphore. However, if the kernel semaphore routines are altered so that they time out after a period of time, and force a trap, the diagnostic monitor can be used for analysis.
In accordance with one embodiment of the present invention, a loader program (the loader) is running initially. The loader then finds the diagnostic monitor from the boot device (such as a disk) and launches the diagnostic monitor. The diagnostic monitor initializes, and tries to determine what model of computer it is running on. In general, a given diagnostic monitor is compiled for particular machine architecture. The diagnostic monitor then requests that the loader to load the appropriate library module for the model of computer the diagnostic monitor is running on. The library has model-specific information about the computer being monitored, such as, the detection and isolation routines of various hardware errors.
Furthermore, the library has detailed information about the operating system to be run.
The diagnostic monitor generally needs to know various OS details such as the layout of process data structures, where the OS will be loaded, etc. The symbol table of the kernel is also loaded and used by the diagnostic monitor so that the diagnostic monitor knows the locations of the fixed kernel data structures. The locations of most run-time kernel structures can be deduced by knowing the locations of certain fixed structures. For any exceptions, the kernel may pass the locations to the diagnostic monitor during OS initialization, or at the structure creation time. Additionally, the diagnostic monitor installs its trap vector table as the one to be used. It then returns control to the loader.
The details and advantages of the invention may be better understood with reference to the drawings and discussions that follow. Fig. 1 illustrates, in accordance with one embodiment of the present invention, a diagnostic environment that includes computer hardware 102 under diagnostic, and a diagnostic exerciser 104.
Diagnostic exerciser 104 includes a loader module 105, which is responsible for loading major components of diagnostic exerciser 104 into memory upon system initiation. These major components are discussed hereinbelow.
Diagnostic exerciser 104 includes a diagnostic kernel 106, representing the kernel of the non-production OS (e.g., a non-production WindowsTM or Linux OS) employed for diagnostic purposes. There are provided with diagnostic kernel 106 a plurality of drivers 107a, 107b, 107c, representing some of the drivers provided to allow the diagnostic exerciser 104 to obtain information pertaining to I/O devices.
Thus, when an I/O device fails, instrumentation may be performed on the associated driver to gather information from the card/device electronics to allow diagnostic exerciser 104 to analyze the error.
Generally speaking, it is preferable to keep the changes between diagnostic kernel 106 and the kernel of the production OS minimal in order to allow computer hardware 102 to be stressed in ways that are representative of the stress experienced by computer hardware 102 in the field. However, certain modifications will be required to allow the diagnostic monitor (discussed below) to perform its functions of monitoring kernel 106, error detection, and error analysis. In one embodiment, kernel 106 is modified to allow the initialization of the diagnostic monitor and the drivers, to facilitate communication with the diagnostic monitor during execution of the diagnostic applications, and to provide for additional diagnostic capabilities (such as processor affinity, physical memory allocation, and the like). Other possible changes to the production kernel are discussed further hereinbelow.
Diagnostic exerciser 104 also includes a diagnostic monitor 108, representing the monitoring software that is involved in detecting and analyzing errors. Diagnostic monitor 108 is designed to communicate with and to monitor kernel 106. In one embodiment, monitor 108 and kernel 106 are furnished as separate binary files, thereby rendering monitor 108 independent of the OS (i.e., monitor 108 runs with rather than runs under kernel 106). Monitor 108 is preferably loaded into a memory location that is unused by kernel 106 to avoid any unintended alteration of monitor 108 by kernel 106. When an error occurs with kernel 106, monitor 108 will attempt to analyze the error and isolate the problem to a FRU (field replaceable unit) or a list of potential offending FRUs. In this sense, the inventive diagnostic exerciser provides the error isolation granularity typically associated with off-line diagnostic tools.
As shown in Fig. 1, diagnostic monitor 108 includes three main modules:
monitor logic 110, monitor library 112, and monitor trap table 114. Monitor logic 110 is architecture-dependent (e.g., PARISCTM, ItaniumTM, etc.). Depending on the specific architecture and the type of box of computer hardware 102 (the information pertaining to which may be obtained via link 116), the appropriate monitor library 112 would be loaded. Monitor library 112 is thus both architecture-specific and boxspecific in one embodiment.
Monitor trap table 114 represents the trap table that is in control during execution of the diagnostic applications. As will be discussed later herein, one of the major functions of diagnostic monitor 108 is to control the trap handler. Any trap encountered by kernel 106 would be examined by monitor 108, which will decide whether it will handle the trap itself or will pass the trap on to the kernel for handling.
The kernel also has a trap table, but the kernel's trap table is granted control only if diagnostic monitor 108 decides that it wants the kernel to handle a particular trap. In such case, control will pass to the appropriate offset in the trap table of the kernel to handle the trap. Thus, as far as the kernel is concerned, its own trap table gets the traps that the kernel needs to handle in a transparent manner. Other traps are retained by and handled by monitor trap table 114.
Applications 130, 132, 134, and 136 represent some diagnostic applications that may be executed under kernel 106 to stress specific portions of computer hardware 102. Thus CPU application 130 is designed to emphasize testing of the CPU; memory application 132 is designed to emphasize testing of the memory; and I/O application 134 is designed to emphasize testing of the I/O subsystems. Other applications may be provided to test other subsystems and/or aspects of computer hardware 102 and/or the OS and are represented generically by application 136 in Fig. 1.
Fig. 2 illustrates the diagnostic monitor 108 in greater detail in accordance with one embodiment of the present invention. As can be seen, monitor logic 110 includes, in addition to core monitor codes 214, architecture routines 210 and rules engines 212. Although architecture routines 210 and rules engines 212 are shown separate from monitor logic 110 in Fig. 2 to facilitate discussion, they are in fact part of monitor logic 110. Architecture routines 210 represent routines that may perform standard tasks based on a given architectural level. For instance, the contents of all general registers may need to be saved. This would be done by an architectural routine. The size and number of general registers depends on the particular architecture under consideration (e.g. PARISC 2.0 has 64 bit width registers, while PARISC 1.0 has 32 bit width registers). In one embodiment, although the core monitor is dependent on the architecture, different monitor libraries are provided to accommodate different boxes, thereby enabling the core monitor to be employed for all boxes pertaining to a given architecture.
Monitor trap table 114 is designed to be the functional trap handler during execution. Thus, any trap/interrupt by kernel 106 (see Fig. 1), expected or not, will force it to enter diagnostic monitor 108. This feature allows diagnostic monitor 108 to be made aware of any error traps right away, at which point diagnostic monitor 108 may stop all other processors, and collect any state information. For non-error traps, for example, diagnostic monitor 108 may collect certain statistics (if desired) and then continue on with the basic function of the trap, eventually returning to the kernel.
Diagnostic monitor 108's trap handler is organized in such a way that kernel 106 can specify (for non-error traps) what routine diagnostic monitor 108 should run.
This specification should occur during kernel initialization, once the kernel knows there is a diagnostic monitor 108. Otherwise, the kernel may use its default trap handler.
Certain error traps may need to be handled in a special way. For example, for severe hardware errors, significant software errors, and hardware resets, the hardware may automatically branch to firmware routines. In the context of PARISCTM machines, for example, HPMCs (High Priority Machine Checks), LPMCs (Low Priority Machine Checks), and TOCs (Transfer of Controls) may cause the hardware to automatically branch to firmware routines. The firmware may then save the register state of the processor and clear any error conditions. If the appropriate trap handler routine in diagnostic monitor 108 is setup properly, the firmware routine may branch to diagnostic monitor 108's handler. At this point, diagnostic monitor 108 can then begin analysis.
Rules engine 212 of monitor logic 110 includes a set of routines to interrogate monitor library 112 in order to determine how to find the FRU for some error condition. Rules engine 212 is employed to interpret rules 220 (described below), and may also include functionality such as which rules will be employed for error analysis and when error analysis is completed. There may be a library for each type of "box" for a given architecture. The library may contain (among other things) rule functions that may analyze collected data in order to figure out what went wrong. The interface to the rules may be the same across different architectures. 
Monitor library 112 includes, in addition to core library codes 224, rules 220 and hardware-specific routines 222. Rules 220 represent rules specific to the architecture under consideration and are employed for error analysis. Rules 220 has the inferences for various error conditions and can resolve the error to the failing FRU. Hardware-specific routines 222 include routines specific to a particular box to facilitate, for example, the gathering of any necessary information from the specific box.
Upon initialization of the computer system, loader module 105 loads the
components of diagnostic exerciser 104 in a particular sequence. Fig. 3 illustrates, in accordance with one embodiment of the present invention, the loading sequence upon initialization. In block 302, the loader ascertains whether a diagnostic monitor (such as a binary image of diagnostic monitor 108) is present on the boot device, e.g., a hard disk, a CDROM, or even a particular storage location in a network. If the diagnostic monitor is not present on the boot device, the loader ascertains in block 304 whether the kernel (such as kernel 106) is present on the boot device. If there is no kernel on the boot device, the loading process indicates failure in block 306.
On the other hand, if there is a kernel on the boot device (as ascertained in block 304), the kernel is loaded, and control is passed to the kernel in block 308. In this case, there is no monitor (as determined earlier in block 302) and thus in block 310, the kernel would ascertain that there is no diagnostic monitor present. Note that this check for the presence of a diagnostic monitor is part of the modifications made to the production OS. With no diagnostic monitor present, the kernel executes normally, with the kernel's trap table in control.
If there is a diagnostic monitor on the boot device (as ascertained in block 302), the loader then loads, in block 330, monitor logic 110 of diagnostic monitor 108 into memory. Thereafter, monitor logic 110 is initialized in block 332 to, for example, ascertain the box information for the hardware being tested using the associated architectural routines (such as architectural routines 210 of Fig. 2). The box information is then passed to the loader to enable the loader to ascertain, in block 334, whether the requisite monitor library is present on the boot device or another device. If the required monitor library is not present, the process of loading the monitor fails. In that case, the method returns to block 304 to begin loading the kernel, i.e., treating the situation from that point on as if the monitor was not present on the boot device.
On the other hand, if the required monitor library is found (as ascertained in block 334), the required monitor library is loaded in block 336. After the required monitor library is loaded and synchronized for communication with monitor logic 110 (using, for example, dynamic linking technologies), control is passed back to the loader, which then ascertains in block 338 whether the kernel is on the boot device.
Note that at this point, the diagnostic monitor is already loaded and initialized.
Accordingly, if the kernel is not found (block 338) or if the kernel fails to boot or if there is another problem with the kernel, diagnostic monitor can detect, analyze, and report the error. This is unlike the situation with existing diagnostic tools which run under production OS's. In the case where an existing diagnostic tool runs under a production OS, if the OS fails to get loaded, the diagnostic tool would not have been initialized and would therefore have been of no value in detecting, analyzing, and/or reporting the error.
If the kernel is not found in block 338, the loading process reports failure in block 306 since there can be no application execution under the OS if the kernel cannot be found. On the other hand, if the kernel is found, the kernel symbol table is loaded in block 340. Generally speaking, the symbol table provides addresses of important elements (such as data structures and subroutines) of the kernel. The diagnostic monitor relies on the kernel symbol table, which is embedded in a nonstripped version of the kernel binaries. Thus, in one embodiment, the loader obtains the symbol table from the kernel ELF binary and loads the symbol table into memory.
Once the symbol table is loaded in block 340, the kernel is loaded in block 308. The kernel is preferably loaded into a fixed address in memory. In block 310, the kernel ascertains whether the monitor is present. In one embodiment, the information regarding the presence of the monitor is passed from the loader to the kernel. If the diagnostic monitor is not deemed present for whatever reason (as ascertained in block 310) the kernel executes normally in block 312 with its trap table in control. On the other hand, the diagnostic monitor is present (as ascertained in block 310), the kernel may optionally call upon the diagnostic monitor (in block 314) to, for example, ascertain which traps are handled by the diagnostic monitor's trap table and which traps are handled by the kernel's trap table. Of course the decision pertaining to which traps are handled the kernel and which traps are handled by the diagnostic monitor may be worked out in advance and hard-coded. In such a case, optional step 314 may be omitted.
Once the kernel completes initialization with the diagnostic monitor, the kernel runs with the diagnostic monitor, and the monitor trap table in control (block 316).
Fig. 4 illustrates, in accordance with one embodiment of the present invention, the error handling steps by the diagnostic monitor. Because a trap could be a result of normal operation or it could represent a problem, the diagnostic monitor needs to examine traps and make certain decisions regarding how the traps are handled. In block 402, the diagnostic monitor ascertains whether the trap is to be handled by the kernel or by the diagnostic monitor itself. In one embodiment, the decision is made using a bit masking technique for looking at the bit in a particular position of the variable. Other techniques may also be employed, including the use of arrays.
If the trap is a result of normal operation, such as a page miss, such trap may be handled by the OS's kernel. In that case, the method proceeds to block 404 wherein it branches to the appropriate OS trap table offset using the symbol table loaded earlier (e.g., in block 340 of Fig. 3) and/or the information obtained during diagnostic initialization call by the kernel (e.g., in block 314).
For example, in the PARISCTM implementation, branching can be performed by, for example, using a relative branch instruction (e.g., branch to five instructions away) or by giving the actual address to branch to in the branch instruction.
Alternatively, branching may be accomplished by reference to a general register, which contains the address.
However, for Itanium-based systems, if a branch instruction employs a branch register, there is a potential for inadvertently overwriting the content of a branch register that is in use by the kernel since the kernel also employs branch registers. It is possible to force the kernel to temporarily store and restore the values of these registers but that may involve certain additional modifications to the production kernel.
To keep the number of changes to the kernel low, there is provided, in accordance with one embodiment of the present invention, a long branch table within the diagnostic monitor. With reference to the IPFTM implementation, for example, the branch table is initially setup so that all branches jump to themselves. During initialization, the monitor can dynamically calculate the address of the long branch instructions and can alter all the branches of the branch table to branch to the appropriate offset in the kernel trap table. This is possible because the kernel trap table resides at a fixed address.
To clarify, a long branch is a type of relative branch that allows one to branch to a long offset, typically longer than normally performed using a normal relative branch. Using long branches allows the monitor to be positioned at any desired location in memory, and still be able to get to the kernel trap handler. Otherwise, the monitor would have to reside near the kernel's trap handler in memory. Furthermore, the monitor long branch table renders it possible to avoid using the branch registers, which are utilized by the kernel. Thus, it is not necessary to keep track of the contents of the branch registers, which would require more kernel modification. For implementations that do not involve branch registers, for example PARISCTM, general registers may be employed instead.
Returning to Fig. 4, if the trap is to be handled by the diagnostic monitor (as ascertained in block 402), a decision is made in block 406 whereby the diagnostic monitor ascertains whether the trap is an explicit monitor call by the kernel. By way of example, the immediate values associated with break trap instructions, which are employed to monitor calls, may be specified to allow the diagnostic monitor to ascertain whether a trap is an explicit monitor call by the kernel. If the trap is an explicit monitor call, it is handled in block 440, which is discussed in connection with Fig. 6 hereinbelow.
If the trap is not an explicit monitor call (as determined in block 406), the hardware-triggered error is assessed in block 408 of Fig. 4B to determine whether the error is severe. As an example, the failure of kernel boot is a severe error. In IPFTM, for example, the occurrence of a Machine Check Abort (MCA) condition is typically regarded as a severe error. In PARISCTM, for example, the occurrence of a High Priority Machine Check (HPMC) condition is typically regarded as a severe error.
Generally speaking, each architecture has its own way of representing a severe error.
However, details on the error can vary between different box types. For example, there may be one bit in a given hardware register in the processor which will be set if the error is severe. The fact that the diagnostic monitor has direct access to the computer hardware facilitates the assessment in block 408. Generally speaking, the error details may be ascertained using the rules.
If the error is deemed severe (as ascertained in block 408), the diagnostic monitor then stops the kernel from running by sending an interrupt signal to all other processors (assuming there are multiple processors). It is possible, for example, for one processor to experience a severe error (e.g., a HPMC in the case of PARISCTM) but other processors of the computer system may not have experienced the same severe error. Freezing the processors by an external interrupt signal allows the state of the processors to be collected in block 412 to facilitate analysis in block 414. Of course if there is only one processor in the system, there is no need to send the interrupt signal to the non-existent other processors, in which case block 410 is not necessary.
In block 414, the error analysis may be accomplished using, for example, the hardware-specific routines (222 in Fig. 2) of the monitor library. The hardwarespecific routines may examine various registers of the processors, the I/O registers, certain data structures in the kernel, and the like, to ascertain the error and/or the cause thereof. The analysis result is displayed in block 416. In one embodiment, the result may be displayed in a monitor shell that is separate from the OS's shell. The monitor shell permits certain diagnostic-related inputs and outputs and can continue to run even if the OS crashes. For example, one can employ the monitor shell to specify certain kernel data structures and routines and causing those to be displayed for examination. This is represented in block 418 of Fig. 4.
On the other hand, if the error is not deemed severe (by block 408), the state information pertaining to the error can be collected in block 430. In block 432, analysis is performed using the rules and hardware-specific routines of the library to narrow the error down to one or more FRUs (Field Replaceable Unit). For example, if a single bit error is encountered, block 432 may attempt to narrow the error down to a single DIMM and/or a single memory slot.
Note that the rules and rules engine of the monitor allow it to analyze the relevant (box specific, in some cases) registers and data structures of the kernel (if necessary) and to narrow the problem to, for example, the failing FRU. This is in contrast to the prior art situation employing a standard OS, wherein an experienced user or expert would have to manually analyze the data dumped by the kernel.
Furthermore, the monitor has access to all system and kernel data, thereby ensuring that the monitor can obtain any required information in order to accurately perform the error detection and error analysis tasks. In contrast, the data dump by the kernel may not, in some cases, contain all the required data for error analysis.
The information pertaining to the error is logged in block 434. The logged
errors may be retrieved by an application program at a later point in time (e.g., for further analysis or display) using a monitor call. In block 436, since the error is nonsevere, the method preferably continues with the next instruction and returns to the caller to allow execution to continue.
There are times when kernel panics occur without traps. For example, the kernel may have encountered some illegal situation where it runs out of resources
(e.g., memory) or experiences a problem that it cannot resolve (e.g., an unresolvable page fault). In this case, the kernel may have made a panic call, which is converted into a monitor call by the non-production kernel to allow the diagnostic monitor to become involved. The kernel panic-related monitor call however contains information identifying the monitor call as one that results from a kernel panic. Once the panic-related monitor call is received, it is handled in blocks 502-510 of Fig. 5.
Blocks 502-510 perform error handling in an analogous fashion to that performed by blocks 410-418 of Fig. 4.
Fig. 6 shows, in accordance with one embodiment of the present invention, block 440 of Fig. 4 in greater detail. In this case, the monitor call is neither
occasioned by the hardware nor caused by a kernel panic. Rather, an application has made a monitor call to report an error or, for example, to inquire about errors. Thus, in block 602, the diagnostic monitor determines whether the monitor call is simply a normal monitor call or a monitor error call, i.e., the application has already determined that there is an error. An error monitor call may be made if, for example, the application has determined that the ECC (Error Correcting Code) circuitry is defective. If the monitor call is an error monitor call, the method proceeds to block 604 wherein the error monitor call is handled in a subsequent Fig. 7, which is discussed later herein.
On the other hand, if the monitor call is not an error monitor call, the method proceeds to block 606 wherein the diagnostic monitor ascertains the nature of nonerror monitor call received. In one embodiment, this is accomplished by consulting the call index in a table. An example of such a non-error monitor call made by the application may involve a call to determine the number of processors in the system, or a call to determine if any correctable errors had occurred.
Once the diagnostic monitor ascertains the nature of the non-error monitor call received, the action requested in the non-error monitor call is performed in block 608.
In block 610, the information requested in the non-error monitor call, if any, is returned to the calling application.
Fig. 7 shows, in accordance with one embodiment of the present invention, block 604 of Fig. 6 in greater detail. In Fig. 7, an error monitor call has been received, which is different from the hardware generated trap handled by Fig. 4. In this case, the application has determined that there is an error with the hardware, and the diagnostic monitor proceeds to collect data and perform error analysis to validate the reported error monitor call. Thus, in block 702 the diagnostic monitor will log the received error monitor call, along with any data furnished by the application. In block 703, the error monitor call is analyzed using, for example, the rule-based analysis. In block 704, the diagnostic monitor will ascertain whether the error monitor call relates to a severe error. A HPMC (PARISCTM) or a MCA (IPFTM) represents an example of a severe error that causes explicit types of traps. An example of a severe, nontrapping
type of error may be, for example, a semaphore timeout. In a semaphore timeout, some processor has grabbed the semaphore for longer than some certain threshold, which situation indicates an imminent hang. In this case, the semaphore may timeout, for example, and result in a call to the monitor.
If the error monitor call is deemed severe in block 704, the diagnostic monitor would treat the severe error monitor call in the same manner that it treats kernel panics. Thus, the method proceeds to block 708 wherein the severe error monitor call is handled in the manner discussed earlier in connection with Fig. 5.
On the other hand, if the error monitor call relates to a non-severe error, the method proceeds to block 706 to return to the calling routine (since the error monitor call has already been logged in block 702) to continue execution.
As can be appreciated from the foregoing, the inventive diagnostic exerciser combines the best of the off-line diagnostic exerciser approach with the best of the on-line diagnostic exerciser approach. By using a non-production kernel, limitations imposed by production OS are effectively removed, allowing the inventive diagnostic exerciser to have more direct access to the computer hardware and information that would have been otherwise unobtainable from a production kernel. This enhanced access to the computer hardware and kernel data structures and subroutines enhances the error detection and error analysis capabilities of the inventive diagnostic exerciser.
However, the use of a non-production OS that has minimal difference from the production OS (with the difference being those made to accommodate the diagnostic monitor), the inventive diagnostic exerciser can stress the computer hardware more fully, accommodate more directed tests with appropriately designed applications (which can substantially reduce the required diagnostic testing time) as well as accommodate tests that are more reflective of the way the computer hardware may be used in the field.
Furthermore, the provision of a diagnostic monitor that runs in cooperation with, instead of under, the non-production OS enables the diagnostic monitor to be able to monitor the kernel failure and to capture information pertaining to kernel failures for analysis. Since the diagnostic monitor is loaded before the loading of the non-production kernel, diagnosing is possible even if the kernel fails during loading.
If an error occurs, the provision of a rule-based analysis system facilitates the analysis and display of error and/or source thereof in an easy-to-understand manner. 
Exemplary Implementation.
In the example discussed below, an exemplary implementation of a diagnostic exerciser based on the Linux operating system is discussed. It should be kept in mind that the exemplary implementation of Appendix A is but one implementation of the invention, and design choices, assumptions, and limitations suggested for this particular implementation should not be construed in a blanket manner to be limitations of the invention, which are clearly defined by the claims herein.
In the exemplary implementation below, Rage is the name given for nonproduction kernel and Ragemon is the name given for the diagnostic monitor.
INTRODUCTION
FUNCTIONALITY/FEATURES
RAGE is offline exerciser based on LINUX. It is designed, to be instrumented in such a way as to allow it to be monitored by a separate executable. The applications that run under RAGE are designed to stress the hardware, as well as perform some diagnostic capabilities. RAGEMON is the executable designed to monitor RAGE. Both RAGE and the Monitor are loaded into memory by a loader ELILO. Which is a modified version of the standard LINUX loader.
Rage intends to implement the following features:
To extend the coverage of our traditional "point to point" tests.
To better capture transient errors by generating more stress patterns.
To have the ability to detect and recover from hardware errors (i.e. MCAs).
To have the ability to isolate hardware errors to a FRU or at least a small list of FRUs.
The target platform is Orca
The following list of features would also be desirable to have in the Offline exerciser:
Test suites that cover all the major hardware elements.
The ability to add "point to point" tests directed at a specific hardware target. Platform portability.
The ability to specify what stress tests suites should run and on what targets.
Fast loading with a small initial footprint.
Monitor is still alive if kernel crashes.
DEPENDENCIES
In general RAGE has the following dependencies:
The most obvious dependency is of course the LINUX kernel itself.
EFI Runtime services
Firmware, PAL & SAL calls
Appropriate compilers
ASSUMPTIONS
It is assumed that the LINUX kernel will have support for Orca (can boot, and run, etc.)
DESIGN OVERVIEW
DESIGN CONTEXT
Initially, RAGE can be used in the offline environment after running the ODE based diagnostics. After RAGE is tuned, it can eventually replace many of the
standard offline diagnostics, just leaving a core set of ODE based tests. This small core set of tests would primarily focus on the CPU for cache pattern tests and TLB functionality. Then, RAGE can be launched to stress test the rest of the system.
Eventually, RAGE should be able to replace the standard online testing as well. The final desired scenario would be: 1) core ODE tests; 2) RAGE tests.
OVERVIEW OF OPERATION
The diagram of Fig. A1 shows the basic modules that make up the RAGE
exerciser platform.
As the diagram illustrates, RAGE is made up of 3 components: the Kernel, the Monitor, and the RAGE applications. Note that the kernel and Monitor are at the same level. The RAGE Monitor does not run under the kernel, but rather with the kernel. The RAGE applications run under the kernel, as one would expect. And they actually perform the hardware stress. The applications are analogous to the ODE diagnostics under the ODE platform.
MAJOR MODULES
The following sections give a more detailed explanation of the Major RAGE modules.
LOADER
The basic functionality of the loader is shown in the diagram of Fig. A2.
The kernel loader will be responsible for loading all the Rage modules into memory. The first module it will load will be the Monitor. Once loaded, the Monitor will do some initialization (number 1 in Fig. A2), and then determine what hardware it is running on. Based on that information, the Monitor will inform the loader which Library to load.
The library is a "box version" specific module that contains specialized information, such as how to grab the contents of certain diagnose registers. The Monitor itself, is only architecturally specific. The Libraries should be viewed as a collection of special routines for the particular type of box we are running on. Once the proper library is loaded, it will initialize with the Monitor (number 2 in Fig. A2).
Initialization would include such things as, letting the Monitor know where the library entry point is.
Once the Library is loaded, the Loader will load the RAGE kernel. The loader will pass the address of the Monitor's trap handler to the kernel. If there is no Monitor present on the. boot device, the loader will pass zero as the address of the RAGE Monitor's trap handler. In this way, the kernel will know whether to use its own internal trap handler, or the Monitor's. If the Monitor's trap handler address is nonzero, the kernel will assume that a Monitor is present (see number 3 in Fig. A2).
MONITOR
RAGEMON's job is to determine what went wrong with the kernel when an error occurs, and to attempt to isolate the problem to a FRU (or at least an ordered list of FRUs) for replacement. To do this, RAGEMON will have information from the kernel. For example, RAGEMON will want to know what range of memory is actually occupied by the kernel, as opposed to memory being available to processes.
When the kernel first comes up and detects that a Monitor is present, it will initialize with the Monitor to pass certain important information. RAGEMON (if available) will be present while the kernel is running, and even while the kernel is booting. The kernel will always be loaded at a fixed address (pre-determined).
As can be seen from the figure of Fig. A3, the Monitor has several major areas that it is composed of. Architecture routines are routines that will perform standard tasks based on a given architectural level. For instance, the contents of all general registers will need to be saved. This will be done by an architectural routine. The size and number of general registers depends on the particular architecture one is using (e.g. PARISC 2.0 has 64 bit width registers, while PARISC 1.0 has 32 bit width registers). Note that the Monitor itself is also architecturally dependent. Thus, the Monitor for a PARISC 2.0 machine, will be different than one for an IA-64 machine.
However, the basic functionality of the routines within each Monitor would be the same.
The trap handler within the Monitor is designed to be the functional trap handler while the RAGE kernel is running. Thus, any trap/interrupt by the kernel, expected or not, will force it to enter the Monitor. This feature allows the Monitor to be made aware of any error traps right away. At which point, the Monitor can stop all other processors, and collect any state information. For non-error traps, the Monitor could collect certain statistics (if desired) and then, continue on, with the basic function of the trap, eventually returning to the kernel. The Monitor will know the location of the kernel's trap handler from the kernel symbol table, so that it can branch to the appropriate offset in the kernel trap table. Otherwise, the kernel will use its' default trap handler. Certain error traps need to be handled in a special way. For MCAs, and CMCs, the hardware will automatically branch to firmware routines. The firmware will then save the register state of the processor and clear any error conditions. If the appropriate trap handler routine in the Monitor is setup properly, and if the firmware deems the error not severe enough to require a reboot, the firmware routine will branch to the Monitor's handler. At this point, the Monitor can then begin analysis.
The rules engine of the Monitor is basically a set of routines that allows it to interrogate the Library in order to determine how to find the FRU for some error condition. There will be a library for each type of "box" for a given architecture. The library will contain (among other things) rule functions that will analyze collected data in order to figure out what wrong. The interface to the rules will be the same regardless of architecture.
The Monitor will have its own separate shell. The primary purpose of this shell is to display the Monitor's analysis to the user, and to allow the user to view certain state information. Thus, the Monitor's shell will be very simple, without many of the features found in the kernel's shell. It is expected that a novice user would simply look at the Monitor's FRU or FRU list, and act accordingly, without any Monitor shell interaction. But, expert users may wish to view more detailed information about the failure state, and perhaps the Monitors decision process.
KERNEL
The kernel will have to be modified primarily to allow the applications to do a better job at diagnosing. The goal, however, is to minimize the modifications as much as possible. The following list shows the areas of the kernel that will need to be modified:
Initialization (for the Monitor)
Initialization (for Drivers)
Monitor interface changes (see kernel interfaces section below)
New diagnostic capability
Processor Affinity (if it does not already exist)
Physical Memory Allocation
MAJOR INTERFACES
There are 2 groups of interfaces that are to be considered in this document:
External Monitor interfaces (Monitor/Kernel and Monitor/Application)
Internal Monitor interfaces
Kernel/Application interfaces
EXTERNAL MONITOR INTERFACES
There will be four basic ways in which the Monitor, (RAGEMON) can be accessed from the kernel:
1) Traps/Interrupts
2) Kernel Panics
3) Explicit Monitor calls
4) Explicit Monitor error calls.
The following sections give more detail on each one of the access methods.
Note, that for all the methods, the Monitor will be in real mode, with most traps, disabled.
TRAPS/INTERRUPTS
At various times, while the kernel is running, it may encounter a trap, fault, interrupt, or check. Not all of these conditions indicate an error condition. However, any such condition will cause the kernel to enter the Monitor. This is because the kernel's trap handler will point to the Monitor's handler. This will ensure that the Monitor will capture any of these significant trapping conditions. In the case of multiple processors, the Monitor will either, have to provide a separate handler for each processor, or use semaphores to keep the processors from overwriting any critical pieces of Monitor code. In both cases, the Monitor will have to know how many processors there are.
During initialization, the kernel will have to inform the Monitor of the addresses of the routines, which handle the non-error cases. When one of these nonerror traps occurs the Monitor will then branch to the appropriate routine, in such a way as to not alter the register state for the kernel.
KERNEL PANICS
Kernel panics generally occur when the kernel encounters some illegal situation, or when it cannot resolve some problem (e.g. page fault that can't be resolved). Kernel panics could result from software errors or hardware errors. The Monitor needs to know when they occur, so that it can make the distinction. All "Panic" calls in the kernel will be implemented using a variant of the break instruction (e.g. break 2). This will force the kernel into the Monitor, where the Monitor can determine the appropriate action for the panic.
MONITOR CALLS
During initialization, the kernel will need to pass information to, and perhaps get information from the Monitor. This type of kernel/Monitor communication is not related to errors. For these types of calls, the Monitor will not need to determine error conditions or try to freeze the kernel. Since the Monitor will be entered for any trapping condition, we can use another break instruction variant for a standard monitor call (e.g. break 3).
MONITOR ERROR CALLS
There will be cases where an application detects a hardware error condition directly. The application can use a system call to inform the kernel. The kernel, in turn, can let the Monitor know via a Monitor error call. Unlike a standard Monitor call, the error call would indicate that the Monitor should freeze the kernel, collect error information, and begin fault analysis. Again, the use of a break variant would be convenient (e.g. break 3) in keeping a consistent interface to the Monitor. It may be better to allow applications to directly invoke these calls, so that the Monitor can gather "fresh" information about the error. Break instructions allow the Monitor to have the closest "snap-shot" of the register state, of an error event. Note that the break instruction takes an immediate field. This field will be use to distinguish between different types of Monitor calls.
MONITOR FREEZE CALLS
When the Monitor has been informed of an error condition, it will need to "freeze" the kernel. "Freezing" essentially means stopping all kernel processes. This feature is useful to fault analysis, for the case where one process interfered with another. The process that was interfered with could cause a trap. In which case, it would be useful to have information about the process that interfered with the trapping one. The more information one could get about the interfering process, at the time the trap occurred, the more useful that information would be. 
On a single processor system, the kernel is essentially "frozen" when a process traps to the Monitor. This is because no other processes can run, since there's only one CPU, hence one thread. But, for multiple processor systems (MP systems), the other processors will have to be stopped. To accomplish this, the Monitor could issue a "Transfer Of Control" (TOC or reset command), to force all processors to a known place. The TOC would effectively "freeze" the kernel.
The Freeze call would be the only call, describe so far, where the Monitor is initiating communication to the kernel, rather than the other way around. For MP systems, it would be useful if the Monitor could switch to a non-trapping processor, in case the trapping one was severely mal-functional.
By default, if an MCA, or CMC is encountered, firmware will take over before returning to the Monitor. Firmware will then force all processors to collect state, and "rendezvous", before returning to the Monitor on the PD Monarch processor. For other errors, where no firmware intervention is involved, the Monitor will have to issue a special external interrupt itself (via library routines) to "freeze" the other processors.
INTERNAL MONITOR INTERFACES
Unlike the Monitor/kernel interface, communication between the Library and the Monitor will occur through procedure calls. And, since the Library and Monitor are separate executables, there has to be some sort of stubbing mechanism between the two, in order for communication to occur. Recall that the Library is a "box" specific module that can change when RAGE is run on different boxes. Therefore, there will need to be some sort of standard interface between the Monitor and the library, so that the Monitor will not have to know which library is present. There will be a standard set of calls that the Monitor can make to the library, which will allow the Monitor to get the information it needs regardless of which "box" the library is written for.
The library has several functions that it has to perform for the Monitor. These functions can be broken down into several areas: Initialization, Error recovery, Error collection, and Fault analysis. On start-up, the loader (Rageldr) will load the Monitor first. Then, the appropriate library module will be loaded. The loader will pass the library module the address of the Monitor's caller entry point. The loader will pass control to the library module so it can initialize with the Monitor. Once that initialization is completed, control will pass back to the loader so that it can load the kernel.
The Monitor and the Library will communicate via a "stub" interface. There will be a standard set of index numbers that represent calls. The library will have stubs that specify the index of the desired call. The Monitor will have similar stubs so that the library and Monitor can communicate with each other, with either as the initiator.
Note, all Monitor functions will start with the prefix "Mon_", while all library functions will start with the prefix "Lib_".
INITIATILIZATION FUNCTIONS
When the loader first loads the library, and temporarily passes control to it, the library will need to pass its caller entry point address to the Monitor. The loader will have passed the Monitor's caller entry point to the library. Thus, the library can call the Mon_Init()function to pass its caller entry point to the Monitor. This call will also informed the Monitor weather to use the default "firmware intervention" method for severe errors, or the "back door" method.
171 The Lib_Chksum function does an additive checksum over the entire body of the library. This function is design to ensure that the library has been loaded into memory properly. The checksum result should be zero. Thus, the return of this function should be zero.
The Mon_Chksum()function is similar to the Lib_Chksum() function, except it allows the Monitor to ensure that it was loaded into memory properly.
The Mon_ProcCnt()function can be called by the library once kernel initialization is completed. This function will return the total number of processors detected by the kernel. If this function is called before the kernel initializes with the Monitor, or if the kernel fails during initialization, this function will return 0.
ERROR RECOVERY FUNCTIONS
The Mon_Grs(proc_id)function will return the general register state of the specified processor, at the time it last entered the Monitor, or at the time of the error (if the Monitor sensed an error condition). This function takes the processor ID as an argument. Whenever a processor enters the Monitor, its register state will be saved.
When a processor re-enters the Monitor, the saved register state will be overwritten.
The library routines can use this function to get the last known state of a processor.
For error conditions, this routine will get the register state from firmware, if the default firmware intervention method is being used. For "back door" libraries, the Monitor will rely on a special LIB_GRs(proc_id) routine to get this information.
The Mon_Crs(proc_id) function is similar to Mon_Grs , but it returns the architectured control register state.
The Mon_Shutdown() function allow the Monitor to do any necessary clean up before the kernel stops running, and returns to the loader. The Monitor will clear any run flags in NVRAM when this function is invoked.
The Lib_Spec(index) function allows the Monitor to call non-standard library functions.
The Lib_Rcv(trap_id) function is called by the Monitor whenever a trap has occurred, and the register state has been saved. This library function will "recover" the trap so that the processor can still run. For HPMCs and LPMCs, if the default "firmware intervention" method is used, this function will do nothing.
Otherwise, this routine will save away any hardware specific error registers that it plans to alter. For most traps, this routine will effectively be a "no-op", but for traps deemed severe by the library, this routine will do the necessary saving and "clean-up".
The Lib_Freeze()function is called by the Monitor when the Monitor wants to stop all kernel processes and record the kernel state. Since doing this could vary from box to box, this routine allows details to be abstracted from the Monitor. By default, for nay error other than HPMCs and LPMCs, this function will invoke a TOC.
The Lib_SwitchProc(proc_id) function allows the Monitor to start executing on the specified processor. Certain error conditions might make the processor, that the Monitor is currently running on, unstable. In such cases, if the system is a multiprocessor system, it would be advantageous to have the Monitor switch to a more stable processor.
The Lib_ProcID()function allows the Monitor to obtain the processor ID of
the currently running processor.
ERROR COLLECTION FUNCTIONS
The Lib_Collct()function is called by the Monitor once it determines that an error condition has occurred on the currently running processor. This routine will collect all register and other information that the Monitor does not collect by default.
This function masks the Monitor from having to know about any "box" specific registers whose state needs collecting. By default, for HPMCs and LPMCs, this
function will make firmware calls to obtain certain error information.
FAULT ANALYSIS
The LIB_FaultAnal() function is the central function involved in fault
analysis. The Monitor will call this function once all the information is collected for all processes. This function points to the rules list that the Monitor will process to determine the failing FRU.
The Mon_Printf(…) function allows the Monitor to print to the console. It has the same parameter signature as a standard printf call.
The Mon_KernelSym(address) function will return the name of the kernel function that contains the specified address.
KERNEL INTERFACES
There are several changes to the standard kernel that will have to be made, in order to allow the Monitor to do its job:
1) Monitor Initialization
2) Heartbeat Functionality
3) Timed Semaphores
4) Explicit Monitor calls
5) Driver Modification
These kernel modifications will need to be made in such a way so that if the Monitor is not present, no Monitor contact will be attempted. When the loader
launches the kernel, it will pass the Monitor's trap handler address, if the Monitor is present. Otherwise, a zero will be passed. In this way, the Kernel will know whether the Monitor is available.
MONITOR INITIALIZATION
When the Rage kernel begins to boot, if it detects the Monitor's presence, it will need to initialize with the Monitor. Initialization involves specifying to the Monitor certain kernel specifics, such as the following:
1) The kernel symbol table
When the loader loads the kernel, it will also load the kernel symbol table. A pointer to this table will be given to the Monitor so that the Monitor will have access to all of the kernel's global addresses. This allows the Monitor to analyze the kernel, even when it fails to come up.
2) The kernel routines for specific types of traps
The kernel will specify to the Monitor all the traps it wants to handle itself.
The kernel will have to pass the address of the routines its whishes called upon encountering certain traps. The Monitor will save the addresses, so that when a trap occurs, the Monitor will call the appropriate, pre-assigned routine.
3) The kernel start of free memory
If the Monitor knows the kernel's start of free memory, it can determine whether certain errors are related to compile time data structures or data structures that were created at run-time. In addition to the start of free memory, it would be useful for the Monitor to know the location of certain run-time structures (e.g. the map structures of the page allocator).
4) The number of processors
The Monitor obviously needs to know the number of processors. This is important, for instance, when the Monitor is freezing. It will need to know when all of the processors have checked in. Also, there are cases where the Monitor may want to switch processors to avoid hardware problems on the first trapping processors. The Monitor would like to know the state of all processes that were running at the time the failure occurred. Since every processor can be running a process, all running processors must be known. The Monitor could determine the number of processors itself, but since this has to be done by the kernel, why duplicate the code in the MonitorTM Therefore, the Monitor will rely on the kernel for this information.
HEARTBEAT FUNCTIONALITY
Certain error conditions could cause the kernel to get stuck in some kind of infinite loop. On normal operating systems, these kinds of errors are difficult to diagnose. Ideally, it would be useful for the kernel to periodically "check-in" with the Monitor so that the Monitor can detect a hanging condition. The "Heartbeat" functionality of the Monitor is designed for precisely this situation. The implementation of the heartbeat functionality is more difficult on a uni-processor system than a multi-processor one.
Due to the periodic nature of the heartbeat function, the interval timer
interrupt is the likely candidate for the "heartbeat" function. Every time a processor has a timer interrupt, the Monitor will be called. The Monitor can then check how many interval timer ticks have passed since the last interrupt. If more than, say three, time slices have passed, the Monitor would consider this a potential error condition (Note, that the exact number of time slices to be considered as an error will be determined heuristically, based on the kernel behavior). The Monitor would look at the address queues (as directed by the rules from the library) to see if the kernel was executing in the same general vicinity as it was during the last timer interrupt. If so, this would cause the Monitor to freeze the system and indicate a kernel hang. The Monitor would then try to further analyze the hang (i.e. find out what routine was hanging, etc.).
On a multi-processor system, it is unlikely that all the processors will hang at the same time. Therefore, some processor will enter the Monitor, sooner or later. At that point, the Monitor can check on the processor that had the timer interrupt, as well as the other processors. If the interval timers of all processors have been synchronized (this can be done via diagnose instructions) then, the Monitor can determine whether some other processor has taken too long to "check-in" with the Monitor. Due to the passive nature of the Monitor, a uni-processor system could hang and be undetected by the Monitor. If the infinite loop that the kernel is in, has the interval timer interrupt turned off, and no other types of traps occur within the loop, the Monitor will not be called!
TIMED SEMAPHORES
Semaphore functions are prime examples of code where the kernel could hang, without any interrupts. Such a hang would be especially dangerous on a uni-processor system since the Monitor would never be called! In order to reduce this possibility, all semaphore functions in the kernel should be timed. In other words, the all semaphore functions should only try to access a semaphore for a fixed amount of time. Once that time elapses, the semaphore function should call the Monitor.
EXPLICIT MONITOR CALLS
The kernel can call the Monitor directly using an explicit Monitor call. As previously mentioned, the kernel will call the Monitor during initialization. However, there are many situations where the kernel may want the Monitor to track some information. For example, it would be useful for the Monitor to know which processor had a particular semaphore at any given time. That way, if some other processor timed out on that semaphore, the Monitor would know who had it. Also, it would be useful for the Monitor to know when a particular application is being run by a processor. If that processor trapped out to the Monitor, the Monitor could then know to use the applications symbol table, rather than the kernels, for analysis.
Explicit Monitor calls lie at the heart of what is meant by "instrumenting" the kernel. These explicit calls allow the kernel to pass information to the Monitor that the Monitor can use in fault analysis. This is a powerful feature. Most ordinary kernels would not be instrumented in this way because of the hit to performance that would be encountered. The RAGE kernel, however, trades off the performance hit, for the ability to track the kernels activities for debugging. The rules in the library will use this tracking feature along with other features, to do fault analysis. The other features would include things like: Using the symbol tables in the ELF format to find the names of routines; Using a feature of the calling convention where calls to subroutines are always made using gr2 has the return address.
DRIVER MODIFICATION
In order to facilitate faster kernel boot, many of the kernel drivers may have to be modified. On large systems with many I/O cards, kernel boots could be long due to the initialization required for all the I/O devices. Traditionally, the kernel will ensure all I/O devices are initialized before the user can interact with the console. For RAGE however, a delayed I/O initialization could suffice. All drivers, except the core essentials, could be made into LINUX modules. So that, their initialization could be delayed, allowing the user to have console access and the ability to launch RAGE applications that don't require the un-initialized I/O. Once the modules are initialized, RAGE apps can be launched to stress the I/O associated with them. The details of RAGE I/O are a part of the second RAGE development phase. Once the RAGE I/O investigation has been completed, the associated investigation report will give more details on RAGE I/O.
PERFORMANCE CONSIDERATION
Though the Monitor intervention will slowdown the Kernel performance to some degree, it should not so severely degrade the Kernel as to reduce the stress impact of the RAGE applications.
MODULE DETAILS
Once an error condition has occurred and the error information has been collected, the Monitor will need to begin Fault analysis. To do this, the Monitor will use a rules-based expert system methodology. The rules will be located in the library module. Conceptually, each rule will look something like:
IF (condition0) (condition1) ................(conditionN) THEN (action0)
(action1).........................(actionN)
There will be a set of such rules in the library module. The rules will be ordered in such a way as to speed up rules processing. In other words, rules that are more likely to be triggered early, will be placed near the start of the rules list. To start Fault analysis, each rule in the rules list will be evaluated sequentially. The conditions in the "IF" part of a rule will actually be function pointers. Each function pointed to will either return 0, or a non-zero value. Zero will represent a "FALSE" condition.
When a rule is being evaluated, if the condition is non-zero, it will be a function pointer. That function will then be executed, and the result checked. If the return value of the function is zero, no further conditions of the rule will be evaluated. The rule is then said to be NOT-TRIGGERED. Furthermore, if any of the conditions are zero (i.e. the function pointer is "NULL"), that condition is considered to be FASLE.
And, therefore, the rule would also be NOT_TRIGGERED.
If all the conditions of a rule return non-zero, that rule is said to be TRIGGERED. The Monitor will keep evaluating each rule in the rules list, until it
gets to a rule that is TRIGGERED. If none of the rules are triggered, the Monitor will indicate this condition and halt. Otherwise, the Monitor will attempt to execute each of the actions specified by the TRIGGERED rule. Once a rule has been TRIGGERED, the Monitor will not evaluate any further rules in the rules list. Also, any trigger rule will be disabled so that it cannot be TRIGGERD again. This feature is intended to speed up rules processing.
The actions of a rule are also function pointers. The Monitor will call the function of each action in a TRIGGERED rule. Each action function will be called sequentially, starting with the first. Once all of the action functions have been called, the Monitor will disable the rule and then start from the beginning of the rules list, looking for the next TRIGGERED rule. See the Data Structure section above for an example of what a rule would look like.
Each rule should have a short text string that basically describes what the rule is trying to due. This feature allows the Monitor to display, in English, to the novice user how it came to its conclusion, during analysis.
There are several debugging features that the Monitor can take advantage of in order to determine the failing FRU:
Kernel Symbol Table
The Kernel will be an ELF-64 binary. As such, it has its symbol table embedded in the binary. The library rules can use this feature to determine where, in the kernel, an error occurred. Applications will also be compiled into ELF-64 formats.
Thus, the same technique can be used. For instance, if the address, at which a particular processor failed, is known, the function that it was executing at the time can be determined from the symbol table. Since the symbol table contains all the starting address of the functions contained in the binary.
Procedure stack unwind
The Monitor can take advantage of un-winding the stack to trace procedures backwards thru time.
IMPLEMENTATION WITH A PRODUCTION OS
In the discussion above, the inventive diagnostic monitor is configured to operate with a non-production OS. As discussed, a production OS is typically optimized for performance and/or security and perhaps compatibility, not diagnostic. Accordingly, diagnostic exercisers operating under a production OS are typically severely restricted in their ability to gather data, to detect errors, and to perform error analysis.
With the inventive diagnostic monitor, it is contemplated by the inventor herein that there may be situations wherein it is highly desirable to have an independent diagnostic binary operating cooperatively with the production kernel of a production OS. Unlike the prior art diagnostic routines which tend to run as
privileged processes or drivers under the production kernel, the inventive diagnostic monitor is preferably configured such that it is loaded even before the kernel is loaded. In this manner, the inventive diagnostic monitor can provide error analysis data even if the kernel could not be loaded.
Furthermore, even though the inventive diagnostic exerciser operates cooperatively with the production kernel, the inventive diagnostic monitor executes independently of the kernel and thus can perform error analysis in the event of a kernel crash. Thus, the time-consuming process of dumping the kernel and the laborintensive process of sorting through the kernel dump data to analyze the error that causes the kernel to crash are advantageously avoided.
In accordance with one embodiment of the present invention, the production OS is minimally modified to accommodate the inventive diagnostic monitor. In particular, it is desirable to minimize the effort and/or degree of modification to the production OS, both to minimize the amount of work involved in the modification and also to minimize affecting the performance and/or security features of the production OS. While the monitor is clearly capable of handling more routine errors, the performance tradeoff needs to be taken into consideration. Thus, it is contemplated by the inventors herein that the monitor is involved, in various embodiments herein, only in situations that involve severe kernel errors, i.e., kernel errors that can cause the kernel to hang or crash. These severe kernel errors include, for example, severe hardware errors, kernel panics, and timed-out semaphores.
Fig. 8 depicts, in accordance with one embodiment of the present invention, a diagnostic arrangement that employs the inventive diagnostic monitor in conjunction with a production OS. The arrangement 804 includes a loader module 805, which is responsible for loading major components of diagnostic monitor 808 into memory upon system initiation. These major components are discussed hereinbelow.
Arrangement 804 includes a production kernel 806, representing the kernel of the production OS (e.g., a production WindowsTM, Unix, or Linux OS) employed in the field. There are provided with production kernel 806 a plurality of drivers 807a, 807b, 807c, representing some of the I/O drivers provided with kernel 806.
Diagnostic monitor 808 is designed to communicate with and to monitor production kernel 806. In one embodiment, monitor 808 and kernel 806 are furnished as separate binary files, thereby rendering monitor 808 independent of the OS (i.e., monitor 808 runs with rather than runs under kernel 806). Monitor 808 is preferably loaded into a memory location that is unused by kernel 806 to avoid any unintended alteration of monitor 808 by kernel 806. When a severe error occurs, monitor 808 will attempt to analyze the error and isolate the problem to a FRU (field replaceable unit) or a list of potential offending FRUs. In this sense, the inventive arrangement provides the error isolation granularity typically associated with off-line diagnostic tools.
As shown in Fig. 8, diagnostic monitor 808 includes three main modules:
monitor logic 810, monitor library 812, and monitor trap table 814. Monitor logic 810 is architecture-dependent (e.g., PARISCTM, ItaniumTM, etc.). Depending on the specific architecture and the type of box of computer hardware 802 (the information pertaining to which may be obtained via link 816), the appropriate monitor library 812 would be loaded. Monitor library 812 is thus both architecture-specific and boxspecific in one embodiment.
Monitor trap table 814 represents the trap table that is in control during execution of the diagnostic applications. As will be discussed later herein, one of the major functions of diagnostic monitor 808 is to control the trap handler. Any trap encountered by kernel 806 would be examined by monitor 808, which will decide whether it will handle the trap itself or will pass the trap on to the kernel for handling.
Preferably, this examination process is optimized such that only severe errors (e.g., kernel panics, severe hardware error, or timed-out semaphores) are handled by the diagnostic monitors and other traps and/or errors are quickly ascertained and handled by the kernel's own trap table..
The kernel has a trap table, and the kernel's trap table is granted control if diagnostic monitor 808 decides that it wants the kernel to handle a particular trap. In such case, control will pass to the appropriate offset in the trap table of the kernel to handle the trap. Thus, as far as the kernel is concerned, its own trap table gets the traps that the kernel needs to handle in a transparent manner. Other traps, e.g., those related to severe errors, are retained by and handled by monitor trap table 814.
Applications 830, 832, 834, and 836 represent some user applications that may be executed under kernel 806 during the course of normal execution. In contrast with the diagnostic applications discussed earlier, these user applications represent applications executed by users in the normal course of employing the computer system. These user applications may include, for example, database applications, spreadsheet programs, graphics programs, web-related programs, and the like.
Fig. 9 illustrates the diagnostic monitor 808 in greater detail in accordance with one embodiment of the present invention. As can be seen, monitor logic 810 includes, in addition to core monitor codes 914, architecture routines 910 and rules engines 912. Although architecture routines 910 and rules engines 912 are shown separate from monitor logic 810 in Fig. 9 to facilitate discussion, they are in fact part of monitor logic 810. Architecture routines 910 represent routines that may perform standard tasks based on a given architectural level. For instance, the contents of all general registers may need to be saved. This would be done by an architectural routine. The size and number of general registers depends on the particular architecture under consideration (e.g. PARISC 1.1 has 32 bit width registers, while PARISC 2.0 has 64 bit width registers). In one embodiment, although the core monitor is dependent on the architecture, different monitor libraries are provided to accommodate different boxes, thereby enabling the core monitor to be employed for all boxes pertaining to a given architecture.
Monitor trap table 814 is designed to be the functional trap handler during execution. Thus, any trap/interrupt by kernel 806 (see Fig. 8), expected or not, will force it to enter diagnostic monitor 808. While routine traps and errors are returned to the kernel's trap table for handling, severe traps/errors are handled by the diagnostic monitor itself. For example, for severe hardware errors, significant software errors, and hardware resets, the hardware may automatically branch to firmware routines. In the context of PARISCTM machines, for example, HPMCs (High Priority Machine Checks), LPMCs (Low Priority Machine Checks), and TOCs (Transfer of Controls) may cause the hardware to automatically branch to firmware routines. The firmware may then save the register state of the processor and clear any error conditions. If the appropriate trap handler routine in diagnostic monitor 808 is setup properly, the firmware routine may branch to diagnostic monitor 808's handler. At this point, diagnostic monitor 808 can then begin analysis.
Rules engine 912 of monitor logic 810 includes a set of routines to interrogate monitor library 812 in order to determine how to find the FRU for the error condition.
Rules engine 912 is employed to interpret rules 920 (described below), and may also include functionality such as which rules will be employed for error analysis and when error analysis is completed. There may be a library for each type of "box" for a given architecture. The library may contain (among other things) rule functions that may analyze collected data in order to figure out what went wrong. The interface to the rules may be the same across different architectures.
Monitor library 812 includes, in addition to core library codes 924, rules 920 and hardware-specific routines 922. Rules 920 represent rules specific to the box and architecture under consideration and are employed for error analysis. Rules 920 has the inferences for various error conditions and can resolve the error to the failing FRU. Hardware-specific routines 922 include routines specific to a particular box to facilitate, for example, the gathering of any necessary information from the specific box.
Upon initialization of the computer system, loader module 805 loads the components of diagnostic monitor 808 and production kernel 806 in a particular sequence. The sequence is analogous to that described in Figs 3A and 3B and will not be redundantly repeated here. As will be apparent to those skilled in the art, it is necessary to modify the production kernel so that the diagnostic monitor, if present, can be loaded first. Furthermore, it is preferable that the production kernel does not automatically take control of the trap table upon system initialization. In one embodiment, the modification involves storing the base address of the diagnostic monitor's trap table (instead of the base address of the kernel's own trap table) in the register that is designated for storing such data.
Figs. 10A and 10B illustrate, in accordance with one embodiment of the present invention, the error handling steps by the diagnostic monitor. Because a trap could be a result of normal operation or it could represent a problem, the diagnostic monitor needs to examine traps and make certain decisions regarding how the traps are handled. In block 1002, the diagnostic monitor ascertains whether the trap is to be handled by the kernel or by the diagnostic monitor itself. In one embodiment, the decision is made using a bit masking technique for looking at the bit in a particular position of the variable. However, optimizations may be made to minimize impact on the performance of the production OS. By way of example, the traps to be handled by the monitor can be enumerated so that the code can branch to the appropriate address and offset in the monitor's trap table automatically. Alternatively or additionally, the traps to be handled by the kernel's own trap table can be enumerated so that the code
can branch to the appropriate address and offset in the kernel's trap table
automatically.
If the trap is a result of normal operation, such as a page miss, such trap may be handled by the OS's kernel. In that case, the method proceeds to block 1004 wherein it branches to the appropriate OS trap table offset using the symbol table loaded earlier (e.g., in block 340 of Fig. 3) and/or the information obtained during diagnostic initialization call by the kernel (e.g., in block 314) and/or via hard-coded branching instructions.
For example, in the PARISCTM implementation, branching can be performed by, for example, using a relative branch instruction (e.g., branch to five instructions away) or by giving the actual address to branch to in the branch instruction.
Alternatively, branching may be accomplished by reference to a general register, which contains the address.
However, for Itanium-based systems, if a branch instruction employs a branch register, there is a potential for inadvertently overwriting the content of a branch register that is in use by the kernel since the kernel also employs branch registers. It is possible to force the kernel to temporarily store and restore the values of these registers but that may involve certain additional modifications to the production kernel.
There is provided, in accordance with one embodiment of the present invention, a branch table within the diagnostic monitor. With reference to the IPFTM implementation, for example, the branch table is initially setup so that all branches jump to themselves. During initialization, the monitor can dynamically calculate the address of the long branch instructions and can alter all the branches of the branch table to branch to the appropriate offset in the kernel trap table. This is possible because the kernel trap table resides at a fixed address.
To clarify, a long branch is a type of relative branch that allows one to branch to a long offset, typically longer than normally performed using a normal relative branch. Using long branches allows the monitor to be positioned at any desired location in memory, and still be able to get to the kernel trap handler. Otherwise, the monitor would have to reside near the kernels trap handler in memory. Furthermore, the monitor long branch table renders it possible to avoid using the branch registers, which are utilized by the kernel. Thus, it is not necessary to keep track of the contents of the branch registers, which would require more kernel modification. For implementations that do not involve branch registers, for example PARISCTM, general registers may be employed instead.
Returning to Fig. 10A, if the trap is to be handled by the diagnostic monitor (as ascertained in block 1002), a decision is made in block 1006 whereby the diagnostic monitor ascertains whether the trap is an explicit monitor call by the kernel. By way of example, the immediate values associated with break trap instructions, which are employed to monitor calls, may be specified to allow the diagnostic monitor to ascertain whether a trap is an explicit monitor call by the kernel.
If the trap is an explicit monitor call, it is handled in block 1040. In this case, an explicit monitor call has been received. The application is requesting that the monitor perform some function (e.g., set the error logging threshold or return correctable error information). The monitor will then perform the function and return to the application.
As mentioned, only severe errors are preferably handled by the diagnostic monitor executing in cooperation with a production kernel. A HPMC (PARISCTM) or a MCA (IPFTM) represents an example of a severe error that causes explicit types of traps. An example of a severe, non-trapping type of error may be, for example, a semaphore timeout. In a semaphore timeout, some processor has grabbed the semaphore for longer than some certain threshold, which situation indicates an imminent hang. In this case, the semaphore may timeout, for example, and result in a call to the monitor. Generally speaking, the diagnostic monitor would treat the severe error monitor call in the same manner that it treats kernel panics. The steps to handle kernel panics is discussed in connection with Fig. 11 herein.
If the trap is not an explicit monitor call (as determined in block 1006), it is deemed a severe error. As an example, the failure of kernel boot is a severe error. As mentioned before, severe hardware errors are one class of sever errors to be handled by the diagnostic monitor. In IPFTM, for example, the occurrence of a Machine Check Abort (MCA) condition is typically regarded as a severe error. In PARISCTM, for example, the occurrence of a High Priority Machine Check (HPMC) condition is typically regarded as a severe error. Generally speaking, each architecture has its own way of representing a severe error. However, details on the error can vary between different box types. For example, there may be one bit in a given hardware register in the processor which will be set if the error is severe. Generally speaking, the error details may be ascertained using the rules.
With a severe error, the diagnostic monitor then stops the kernel from running by sending an interrupt signal to all other processors (assuming there are multiple processors). It is possible, for example, for one processor to experience a severe error (e.g., a HPMC in the case of PARISCTM) but other processors of the computer system may not have experienced the same severe error. Freezing the processors by an external interrupt signal allows the state of the processors to be collected in block 1012 to facilitate analysis in block 1014. Of course if there is only one processor in the system, there is no need to send the interrupt signal to the non-existent other processors, in which case block 1010 is not necessary.
In block 1014, the error analysis may be accomplished using, for example, the hardware-specific routines (822 in Fig. 8) of the monitor library. The hardwarespecific routines may examine various registers of the processors, the I/O registers, certain data structures in the kernel, and the like, to ascertain the error and/or the cause thereof and preferably to narrow the error down to one or more FRUs (Field Replaceable Unit). For example, analysis may pinpoint that a particular CPU is defective and needs to be replaced. The analysis result is displayed in block 1016. In one embodiment, the result may be displayed in a monitor shell that is separate from the OS's shell. The monitor shell permits certain diagnostic-related inputs and outputs and can continue to run even if the OS crashes. For example, one can employ the monitor shell to specify certain kernel data structures and routines and causing those to be displayed for examination. This is represented in block 1018 of Fig. 10.
Note that the rules and rules engine of the monitor allow it to analyze the relevant (box specific, in some cases) registers and data structures of the kernel (if necessary) and to narrow the problem to, for example, the failing FRU. This is in contrast to the prior art situation employing a standard OS, wherein an experienced user or expert would have to manually analyze the data dumped by the kernel.
Furthermore, the monitor has access to all system and kernel data, thereby ensuring that the monitor can obtain any required information in order to accurately perform the error detection and error analysis tasks. For example, in one embodiment, the map file of the kernel may contain the addresses of the global kernel variables and kernel function addresses, all of which may be accessible by the monitor. In contrast, the data dump by the kernel may not, in some cases, contain all the required data for error analysis.
There are times when kernel panics occur without traps. For example, the kernel may have encountered some illegal situation where it runs out of resources
(e.g., memory) or experiences a problem that it cannot resolve (e.g., an unresolvable page fault). In this case, the kernel may have made a panic call, which is converted into a monitor call by the modified production kernel to allow the diagnostic monitor to become involved. The kernel panic-related monitor call however contains information identifying the monitor call as one that results from a kernel panic. Once the panic-related monitor call is received, it is handled in blocks 1102-1110 of Fig. 11. Blocks 1102-1110 perform error handling in an analogous fashion to that performed by blocks 1010-1018 of Fig. 10B.
As can be appreciated from the foregoing, the use of the inventive diagnostic monitor that operates as an independent binary in cooperation with the production kernel enables the inventive diagnostic monitor to perform error analysis even in the event of a kernel crash or in the event that the kernel fails to load.
The fact that the monitor is involved only in severe error cases, and not employed to handle non-severe errors that occur during normal execution (e.g., page fault, correctable single-bit memory errors) also reduces the negative impact on system performance. During normal execution, none of the three cases that are discussed (e.g., severe hardware errors, kernel panics, time-out semaphores) would be encountered, and thus the impact of the monitor on system performance is minimal.
As mentioned, the above exemplary implantation is only one specific example of diagnostic monitor implementation in accordance with principles of the present invention. Thus while this invention has been described in terms of several preferred embodiments, there are alterations, permutations, and equivalents which fall within the scope of this invention. It should also be noted that there are many alternative ways of implementing the methods and apparatuses of the present invention. It is therefore intended that the following appended claims be interpreted as including all such alterations, permutations, and equivalents as fall within the true spirit and scope of the present invention.
1. A computer-implemented method for monitoring a computer system (802) when said computer system executes a user application (830) using a production operating system (OS), said OS having a OS kernel (806) with a kernel trap arrangement, said method comprising:
providing a diagnostic monitor (808), said diagnostic monitor being configured to be capable of executing even if said OS kernel (806) fails to execute, said diagnostic monitor having a monitor trap arrangement (814); and
if a trap is encountered during execution of said user application, ascertaining (1002) using said diagnostic monitor whether said trap is to be handled by said OS kernel (806) or said diagnostic monitor (808); and
if said trap is to be handled by said OS kernel, passing said trap to said OS kernel for handling (1004).
2. The computer-implemented method of claim 1 wherein said OS kernel (806) is a production kernel configured to execute said user application (830).
3. The computer-implemented method of claim 2 wherein said OS kernel (806) is configured to permit said diagnostic monitor to be initialized (332) prior to loading (308) said OS kernel.
4. The computer-implemented method of claim 1 further comprising:
ascertaining (1006), using said diagnostic monitor, if said trap is to handled by said diagnostic monitor (808), whether said trap represents a monitor call by said OS kernel; and
if said trap represents said monitor call by said OS kernel, using said diagnostic monitor for handling said monitor call (1040).
5. The computer-implemented method of claim 4 further comprising:
if said trap does not represent said monitor call, using said diagnostic monitor for performing 
a) sending a freeze signal (1010) to any other processor in said computer system, 
b) collecting state information (1012), and 
c) performing analysis (1014) on said state information.
6. The computer-implemented method of claim 5 further comprising using said diagnostic monitor for performing, if said trap does not represent said monitor call, 
d) displaying a result of said analysis in a shell (1016), and 
e) receiving user input (1018), if any, from said shell.
7. The computer-implemented method of claim 1 further comprising:
converting, using said OS kernel (806), a panic call into a monitor call;
ascertaining, using said diagnostic monitor (808), whether said monitor call represents said panic call when said monitor call is received by said diagnostic monitor (808);
if said monitor call represents said panic call, using said diagnostic monitor for performing 
a) sending a freeze signal (1102) to any other processor in said computer
system, 
b) collecting state information (1104), and c) performing analysis on said state information (1106).
8. The computer-implemented method of claim 7 further comprising using said diagnostic monitor for performing, if said monitor call represents said panic call, 
d) displaying a result of said analysis in a shell (1108), and e) receiving user input, if any, from said shell (1110).
A computer-implemented method for monitoring a computer system (802) when the computer system executes a user application (830) using a production operating system (OS) is disclosed. The method includes providing a diagnostic monitor (808), the diagnostic monitor being configured to be capable of executing even if the OS kernel (806) fails to execute, the diagnostic monitor having a monitor trap arrangement (814). If a trap is encountered during execution of the user application, the method includes ascertaining (1002) using the diagnostic monitor whether the trap is to be handled by the OS kernel (806) or the diagnostic monitor (808). If the trap is to be handled by the OS kernel, the method includes passing the trap to the OS kernel for handling (1004).
2005032247.tif 000020
2005032247.tif 000021
2005032247.tif 000022
2005032247.tif 000023
2005032247.tif 000024
2005032247.tif 000025
2005032247.tif 000026
2005032247.tif 000027
2005032247.tif 000028
2005032247.tif 000029
2005032247.tif 000030
2005032247.tif 000031
2005032247.tif 000032
2005032247.tif 000033
2005032247.tif 000034
2005032247.tif 000035
2005032247.tif 000036