(57)【要約】【課題】  障害発生時のパニックダンプによるメモリデータ採取処理を確実に行なうことを可能にする。【解決手段】  ブートファームウェアがオペレーティングシステムに通知するメインメモリ５の構成情報において、システム運用モードのオペレーティングシステムの起動時とダンプ運用モード時のオペレーティングシステムの起動とで異なった領域（第１のメインメモリ領域、第２のメインメモリ領域）を設定し、障害発生時には、障害発生時のメモリ情報を保存したまま、ダンプ運用モードで再起動してダンプ処理を行なう。【選択図】図１
2006072931.tif 000002
【特許請求の範囲】
【請求項１】
情報処理装置の動作を制御する運用モード指定情報に応じて、前記情報処理装置が備える記憶手段の領域をオペレーティングシステムに使用していた第１の領域以外の第２の領域に画する第２の領域定義情報を記憶した領域定義情報手段から、該第２の領域定義情報を取得する領域定義情報取得処理と、
該第２の領域定義情報に基づく領域にオペレーティングシステムを格納するオペレーティングシステム格納処理と、
前記第２の領域定義情報に基づく領域における所定の領域に対応する前記第１の領域における所定の領域をダンプ対象領域として算出するダンプ対象領域算出処理と、
該ダンプ対象領域に格納されている情報を読み出して出力するダンプ処理と、
を備えるパニックダンプ採取処理をコンピュータに実行させるためのプログラム。
【請求項２】
情報処理装置が動作するために必要な構成要素に障害が発生したことを検出して通知する障害通知処理と、
該障害通知処理による通知に応じて、前記情報処理装置の動作を制御する運用モード指定情報を運用モード指定情報記憶手段に記憶する運用モード指定情報記憶処理と、
前記障害発生時に使用されていた領域の状態を保持したまま、前記情報処理装置を再起動する再起動処理と、
前記運用モード指定情報に応じて、前記情報処理装置が備える記憶手段の領域をオペレーティングシステムに使用していた第１の領域以外の第２の領域に画する第２の領域定義情報を記憶した領域定義情報手段から、該第２の領域定義情報を取得する領域定義情報取得処理と、
該第２の領域定義情報に基づく領域にオペレーティングシステムを格納するオペレーティングシステム格納処理と、
前記第２の領域定義情報に基づく領域における所定の領域に対応する前記第１の領域における所定の領域をダンプ対象領域として算出するダンプ対象領域算出処理と、
該ダンプ対象領域に格納されている情報を読み出して出力するダンプ処理と、
を備えるパニックダンプ採取処理をコンピュータに実行させるためのプログラム。
【請求項３】
前記ダンプ対象領域算出処理は、前記ダンプ対象領域を、前記第１の領域の先頭位置と前記第２の領域の先頭位置とのオフセットと、前記第２の領域における所定の領域と、の差によって算出する処理であることを特徴とする請求項１又は２に記載のパニックダンプ採取を行なうためのプログラム。
【請求項４】
情報処理装置の動作を制御する運用モード指定情報に応じて、前記情報処理装置が備える記憶手段の領域を、オペレーティングシステムに使用していた第１の領域以外の第２の領域に画する第２の領域定義情報を記憶した領域定義情報手段から、該第２の領域定義情報を取得する領域定義情報取得処理と、
該第２の領域定義情報に基づく領域にオペレーティングシステムを格納するオペレーティングシステム格納処理と、
前記第２の領域定義情報に基づく領域における所定の領域に対応する前記第１の領域における所定の領域をダンプ対象領域として算出するダンプ対象領域算出処理と、
該ダンプ対象領域に格納されている情報を読み出して出力するダンプ処理と、
を行なうパニックダンプ採取方法。
【請求項５】
情報処理装置の動作を制御する運用モード指定情報に応じて、前記情報処理装置が備える記憶手段の領域をオペレーティングシステムに使用していた第１の領域以外の第２の領域に画する第２の領域定義情報を記憶した領域定義情報手段から、該第２の領域定義情報を取得する領域定義情報取得手段と、
該第２の領域定義情報に基づく領域にオペレーティングシステムを格納するオペレーティングシステム格納手段と、
前記第２の領域定義情報に基づく領域における所定の領域に対応する前記第１の領域における所定の領域をダンプ対象領域として算出するダンプ対象領域算出手段と、
該ダンプ対象領域に格納されている情報を読み出して出力するダンプ手段と、
を備えるパニックダンプ採取機構。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、障害発生時のパニックダンプ採取のためのプログラム、方法、及び機構に関する。
【背景技術】
【０００２】
情報通信技術が普及するに従って、情報処理装置、特に基幹システムで運用されるサーバシステムには高い信頼性が要求される。そのため、システム運用中に障害が発生した場合には、すみやかに情報を収集し、運用を継続させることが不可欠である。
【０００３】
一般に、致命的な障害の発生によりシステムの運用を継続できなくなった場合には、情報採取の手段として、障害発生時のメモリデータをダンプする、いわゆるパニックダンプ機能が用いられている。
【０００４】
パニックダンプは、システム運用中に、システムを継続動作させることが不可能な異常を検出した場合に、その時点でのメモリ内容を保存するものであり、通常はＯＳ（Ｏｐｅｒａｔｉｎｇ  Ｓｙｓｔｅｍ）又は、カーネル内で動作するプログラムがダンプ処理を行っている。
【０００５】
例えば、ＣＰＵがカーネル内のプログラムを動作させている場合に、異常検出の割り込み信号を受け付けると、ＣＰＵはカーネルに組み込まれているメモリダンププログラムに制御を移行し、メモリダンプ採取を行う。
【０００６】
メモリダンププログラムは、カーネルに組み込まれているので、カーネル内のシステムテーブルを解析して障害解析に必要な情報を最適のダンプサイズでダンプ可能である。
しかし、異常の原因が、例えば、カーネル内で動作するプログラム自体、制御データの不整合、カーネル（プログラム）が格納されているメモリの破壊、ハードウェアの異常等であった場合には、ダンプ処理において異常の原因となった資源（例えば、破壊されたメモリ）を必要とする可能性がある。そのような場合、ダンプ処理の実行中に再度異常が発生するためダンプ処理に失敗する結果となる。
【０００７】
また、異常の種類によってはシステムがハングアップし、パニックダンプ処理まで処理が進めないためメモリデータをダンプすることができない場合もある。
このような問題を解決するための手段として、メモリデータを保存したままシステムにリセットをかけ、ダンプしたいメモリデータ以外のハード資源を再設定してダンプ処理プログラムを起動しなおし、その環境でメモリデータをダンプするスタンドアロンダンプが知られている。
【０００８】
例えば、上述のようにカーネルに組み込まれたメモリダンププログラムよるメモリダンプ採取に失敗し、システムがハングした場合、メモリに格納されているデータを保存した状態のままシステムにリセットをかけ、カーネルに組み込まれたメモリダンププログラムとは別の専用のメモリダンププログラム（スタンドアロンダンププログラム）を起動してメモリダンプを採取する。
【０００９】
スタンドアロンダンプによって、異常が発生した環境（カーネルの制御データの不整合やメモリ破壊など）とは無関係にダンプ採取が行え、一時的なハードウェアの異常である場合には、一旦ハードウェアをリセットすることにより、正常に動作できる可能性が高まる。また、恒常的なハードウェアの異常である場合には、リセットによるシステムの再起動時に実行されるＰＯＳＴ（Ｐｏｗｅｒ  Ｏｎ  Ｓｅｌｆ  Ｔｅｓｔ）診断やハードウェアの初期化処理で異常を検出できる可能性が高まる。
【特許文献１】特開平０８−０９５８３４号公報
【発明の開示】
【発明が解決しようとする課題】
【００１０】
しかし、従来のスタンドアロンダンプでは以下のような問題点があった。
１）システムにリセットをかけ、スタンドアロンダンプをダウンロードするため、スタンドアロンダンプが上書きするメモリ領域のデータをあらかじめ保存しておく必要がある。これは、スタンドアロンダンプをロード（格納）する前にＯＳをブートするためのブートファームウェアで行う必要がある。
【００１１】
そのため、ブートファームウェア側でメモリデータを一時待避させるだけのハードウェア資源を持つか、またはディスクなどにブートファームウェアが制御可能な専用パーティションを確保し、そこにファイルとして保存する必要がある。
【００１２】
専用ハードウェア資源を持つ場合にはコスト的に不利である。また、専用パーティションを持つ場合には、接続ディスクに必ずメモリデータの一時待避のための専用パーティションが存在することを保証しなければならないが、接続ディスクに専用パーティションが確保されているかいないかはブートファームウェアからは制御できないため、ディスクのパーティション管理が複雑になるという問題がある。
２）障害発生時のメモリデータを保存した状態でスタンドアロンダンプをブートするため、メモリ上のブートファームウェアやＯＳローダ（ＯＳをメモリにロードするためのプログラム）のデータは、システムのブート処理で完全に上書きされてしまう。
【００１３】
そのため、カーネルとこれらブートファームウェアやＯＳローダの間で異常が発生した場合には、ファームウェアのデータはダンプデータとして採取できないため調査が困難となってしまう問題がある。
３）サーバシステムは通常、数ＧＢ又は数十ＧＢ以上のメインメモリを搭載しているため、パニックダンプで全メモリのデータを採取することは現実的ではない。そのため、通常は調査に必要なオペレーティングシステムのカーネルテキスト、カーネルデータなどの領域だけを採取する。この領域の情報を取得するためにはカーネル内のテーブルを検索し解析する必要があるが、これらの情報はカーネルの版数によって異なっているため、オペレーティングシステムと別プログラムであるスタンドアロンダンプを使用する場合にはオペレーティングシステムの版数に対応したスタンドアロンダンププログラムを用意する必要がある。そのため、スタンドアロンダンプの版数は対応するオペレーティングシステムの版数と合っている必要がある。もし、合っていない場合には、カーネル内のテーブルを検索することができないため、ダンプに失敗するか、実装する全メモリデータをダンプしなくてはいけなくなってしまう。
【００１４】
特許文献１には、これらの問題点の１）および２）を解決するために、システムの主記憶メモリ領域に、通常稼働時には使用されないシステムダンプ採取プログラム使用領域を、オペレーティングシステムが使用するオペレーティングシステム使用領域とは別に設け、ハングアップ等によりシステムダンプが採取できないときに、計算機システムをリセットした後、オペレーティングシステムをオペレーティングシステム使用領域に再ロードする前に、外部記憶装置からシステムダンプ採取プログラムをシステムダンプ採取プログラム使用領域にロードして実行することによりオペレーティングシステム使用領域のシステムダンプを採取することを特徴とするシステムについて開示されている。
【００１５】
しかし、オペレーティングシステムとは別のスタンドアロンダンプシステムでは、上記３）で指摘した問題点を解決することができない。すなわち、特許文献１で開示されているシステムにおいても、静的または動的にアロケーションされた主記憶装置上の領域を管理するテーブル情報からシステムダンプを取得すべき領域のリストを予め作成しておくことにより、このリストに示された領域のみシステムダンプを採取するようにしているので、対象とする領域のリストを予め用意しておかなければならない。
【００１６】
このリストの情報を作成するための情報は通常オペレーティングシステムの版数に強く依存しているため、オペレーティングシステムの版数管理とリストの版数管理が複雑となる問題が解決できない。
【００１７】
さらに、システムダンプを取得すべき領域のリストは予め作成しておかなければいけないので、オペレーティングシステムが動作中に動的に割り当てた領域をきめ細かく予測できず、システム構成が複雑な大規模サーバシステムの場合には必要な情報を効率よく採取することが難しいという問題がある。また、もし、パッチにより版数合わせに失敗した場合、必要な領域が採取不可能となってしまう問題がある。
【００１８】
本発明は、上述した問題に鑑みてなされたものであり、その解決しようとする問題は、障害発生時のパニックダンプによるメモリデータ採取処理を確実に行なうことを可能にするパニックダンプ採取のためのプログラム、方法、及び機構を提供することである。
【課題を解決するための手段】
【００１９】
請求項１に記載の発明は、情報処理装置の動作を制御する運用モード指定情報に応じて、前記情報処理装置が備える記憶手段の領域をオペレーティングシステムに使用していた第１の領域以外の第２の領域に画する第２の領域定義情報を記憶した領域定義情報手段から、該第２の領域定義情報を取得する領域定義情報取得処理と、該第２の領域定義情報に基づく領域にオペレーティングシステムを格納するオペレーティングシステム格納処理と、前記第２の領域定義情報に基づく領域における所定の領域に対応する前記第１の領域における所定の領域をダンプ対象領域として算出するダンプ対象領域算出処理と、該ダンプ対象領域に格納されている情報を読み出して出力するダンプ処理と、を備えるパニックダンプ採取処理をコンピュータに実行させるためのプログラムである。
【００２０】
請求項１に記載の発明によると、前記ダンプ対象領域算出処理によって、前記領域定義情報取得処理によって取得した前記第２の領域における所定の領域に対応する前記第１の領域（障害発生時に使用されていた領域）における所定の領域を算出して、該算出されたダンプ対象領域のデータを出力するので、障害発生時に使用していた領域のデータを確実に取得することが可能となる。
【００２１】
また、前記第１の領域、すなわち、障害発生時に使用されていた領域で動作していたオペレーティングシステムと、前記第２の領域で動作するオペレーティングシステムは、同一の領域管理（例えば、メモリ管理テーブルによって、オペレーティングシステム等が動作するために必要なプログラムを含むデータのメモリアドレスを管理する場合など）を行なうので、前記ダンプ対象領域算出処理によって、前記領域定義情報取得処理によって取得した前記第２の領域における所定の領域に対応する前記第１の領域における所定の領域を容易に算出することが可能となる。
【００２２】
請求項２に記載の発明は、情報処理装置が動作するために必要な構成要素に障害が発生したことを検出して通知する障害通知処理と、該障害通知処理による通知に応じて、前記情報処理装置の動作を制御する運用モード指定情報を運用モード指定情報記憶手段に記憶する運用モード指定情報記憶処理と、前記障害発生時に使用されていた領域の状態を保持したまま、前記情報処理装置を再起動する再起動処理と、前記運用モード指定情報に応じて、前記情報処理装置が備える記憶手段の領域をオペレーティングシステムに使用していた第１の領域以外の第２の領域に画する第２の領域定義情報を記憶した領域定義情報手段から、該第２の領域定義情報を取得する領域定義情報取得処理と、該第２の領域定義情報に基づく領域にオペレーティングシステムを格納するオペレーティングシステム格納処理と、前記第２の領域定義情報に基づく領域における所定の領域に対応する前記第１の領域における所定の領域をダンプ対象領域として算出するダンプ対象領域算出処理と、該ダンプ対象領域に格納されている情報を読み出して出力するダンプ処理と、を備えるパニックダンプ採取処理をコンピュータに実行させるためのプログラムである。
【００２３】
請求項２に記載の発明によると、請求項１に記載の発明の効果に加えて、障害が発生すると、再起動処理によって、情報処理装置（又は、情報処理装置を構成する構成要素、及びそれらを制御するためのプログラム）が再起動し、前記領域定義情報取得処理によって前記情報処理装置が備える記憶手段の領域を複数の領域に画するための領域定義情報を記憶した領域定義情報手段から、オペレーティングシステムに使用していた第１の領域以外の第２の領域についての領域定義情報を取得し、該取得した前記領域定義情報に基づく領域にオペレーティングシステムがローディングされるので、前記障害発生時に使用されていた領域を保持したままリセット処理を行なうことが可能となる。
【００２４】
請求項３に記載の発明は、前記ダンプ対象領域算出処理は、前記ダンプ対象領域を、前記第１の領域の先頭位置と前記第２の領域の先頭位置とのオフセットと、前記第２の領域における所定の領域と、の差によって算出する処理であることを特徴とする請求項１又は２に記載のパニックダンプ採取を行なうためのプログラムである。
【００２５】
請求項３に記載の発明によると、前記第１の領域の先頭位置と前記第２の領域の先頭位置とのオフセットと、前記第２の領域における所定の領域と、の差によって、前記第２の領域における所定の領域に対応する前記第１の領域を、算出することによって、ダンプ対象領域を容易に算出して取得することが可能となる。
【００２６】
請求項４に記載の発明は、情報処理装置の動作を制御する運用モード指定情報に応じて、前記情報処理装置が備える記憶手段の領域を、オペレーティングシステムに使用していた第１の領域以外の第２の領域に画する第２の領域定義情報を記憶した領域定義情報手段から、該第２の領域定義情報を取得する領域定義情報取得処理と、該第２の領域定義情報に基づく領域にオペレーティングシステムを格納するオペレーティングシステム格納処理と、前記第２の領域定義情報に基づく領域における所定の領域に対応する前記第１の領域における所定の領域をダンプ対象領域として算出するダンプ対象領域算出処理と、該ダンプ対象領域に格納されている情報を読み出して出力するダンプ処理と、を行なうパニックダンプ採取方法である。
【００２７】
請求項５に記載の発明は、情報処理装置の動作を制御する運用モード指定情報に応じて、前記情報処理装置が備える記憶手段の領域をオペレーティングシステムに使用していた第１の領域以外の第２の領域に画する第２の領域定義情報を記憶した領域定義情報手段から、該第２の領域定義情報を取得する領域定義情報取得手段と、該第２の領域定義情報に基づく領域にオペレーティングシステムを格納するオペレーティングシステム格納手段と、前記第２の領域定義情報に基づく領域における所定の領域に対応する前記第１の領域における所定の領域をダンプ対象領域として算出するダンプ対象領域算出手段と、該ダンプ対象領域に格納されている情報を読み出して出力するダンプ手段と、を備えるパニックダンプ採取機構である。
【００２８】
請求項４及び請求項５に記載の発明によっても、請求項１と同様に、障害が発生すると、前記ダンプ対象領域算出処理（又は、前記ダンプ対象領域算出手段）によって、前記領域定義情報取得処理によって取得した前記第２の領域における所定の領域に対応する前記第１の領域（障害発生時に使用されていた領域）における所定の領域を算出して、該算出されたダンプ対象領域のデータを出力するので、障害発生時に使用していた領域のデータを確実に取得することが可能となる。
【００２９】
また、前記第１の領域、すなわち、障害発生時に使用されていた領域で動作していたオペレーティングシステムと、前記第２の領域で動作するオペレーティングシステムは、同一の領域管理を行なうので、前記ダンプ対象領域算出処理（又は、前記ダンプ対象領域算出手段）によって、前記領域定義情報取得処理によって取得した前記第２の領域における所定の領域に対応する前記第１の領域における所定の領域を容易に算出することが可能となる。
【発明の効果】
【００３０】
以上のように、本発明によると、障害発生時のパニックダンプによるメモリデータ採取処理を確実に行なうことを可能にするパニックダンプ採取のためのプログラム、方法、及び機構を提供することができる。
【発明を実施するための最良の形態】
【００３１】
以下、本発明の実施形態について図１から図８に基づいて説明する。
図１は、本発明の実施例に係る構成の主要部の例を示す図である。
同図に示す情報処理装置１は、情報処理装置の各構成要素を制御し本実施例に係るプログラムに応じて処理を行なう図示しないＣＰＵ２と、本実施例に係るＲＯＭファームウェア及びブートファームウェア等を格納するＲＯＭ（Ｒｅａｄ  Ｏｎｌｙ  Ｍｅｍｏｒｙ）３と、ＲＯＭファームウェアが使用する環境変数及びブートファームウェアが使用する環境変数（例えば、ＲＯＭファームウェア運用モード指定フラグやブートファームウェア運用モード指定フラグ等）などを格納するＮＶＲＡＭ（Ｎｏｎ  Ｖｏｌａｔｉｌｅ  ＲＡＭ）やＦｌａｓｈ  Ｍｅｍｏｒｙ等で構成される不揮発性メモリ４と、ブートファームウェアやＯＳローダ、ＯＳカーネル等を格納するメインメモリ５と、を少なくとも備える情報処理装置である。
【００３２】
また、本実施例に係る情報処理装置１は、ＯＳローダ及びＯＳカーネルを記憶する外部記録装置６（例えば、磁気ディスク装置）と接続される。なお、同図に示す外部記録装置６は、情報処理装置１外部に接続されているが内部にあってもよい。
【００３３】
本体装置の電源が投入されると、ＲＯＭ３に格納されたＲＯＭファームウェアが起動し、ハードウェアの初期化と診断を実行し、ハードウェアの構成認識処理を行う。構成認識処理では、実装ＣＰＵ２の数や実装メモリ（実装されているメインメモリ５）の構成などの認識を行い、構成情報をＲＯＭファームウェア環境変数格納領域に格納する。
【００３４】
ＲＯＭファームウェアは、ＲＯＭ３の所定のアドレスからブートファームウェアデータを読み出しメインメモリ５に格納し、メインメモリ５上に実行可能なブートファームウェアとして展開して、ブートファームウェアに制御を渡す。
【００３５】
ここで、ＲＯＭファームウェアはブートファームウェアに制御を渡す時に構成認識処理で認識したハードウェアのメモリ構成情報を渡すか、または、メモリの構成情報を通知するメソッドを提供する。
【００３６】
ブートファームウェアは、システム全体のメモリの実装状態を認識するとともに、ＯＳローダ、及びＯＳをこのメモリ実装環境下で動作させる。
また、ＯＳ起動後も一部のプログラムは、メインメモリ５上に常駐し、ＯＳローダやＯＳに対して各種のサービスを提供する。
【００３７】
したがって、ＯＳローダやＯＳカーネルは、ハードウェアの情報を直接見ることなく、抽象化された構成情報（例えば、現実に実装されたメモリの構成情報ではなく、ブートファームウェアによって通知されたメモリの構成情報）を見ることによって、個々のハードウェアの仕様に依存しないで汎用性を高めるようになっている。
【００３８】
また、第１のメインメモリ領域と第２のメインメモリ領域は、ＲＯＭファームウェアからブートファームウェアに通知されるメモリの構成情報に基づいて決定される。
以上に説明した本実施例に係るメインメモリ５は、第１のメインメモリ領域７と第２のメインメモリ領域８とで構成されるが、論理的に２つのメモリ領域に分割されていればよく、物理的には１つメモリで構成されてもよい。また、複数の（物理的に分割された）メモリで構成されてもよい。また、論理的に２以上のメモリ領域（例えば、第１のメモリ領域、第２のメインメモリ領域、及び第３のメインメモリ領域）に分割してもよい。
【００３９】
図２Ａから図４に、情報処理装置１に電源が投入された場合、及び再起動の場合（ＯＳがパニックを起こした場合の再起動処理）について処理のフローチャートを示し、図面に基づいて処理を説明する。
【００４０】
図２Ａは、本発明の実施例に係るＲＯＭファームウェアの処理を示すフローチャートである。
情報処理装置１が電源投入、又は再起動されると（ステップＳ２０１）、情報処理装置１に備わるＣＰＵ２は、ＲＯＭ３の所定のアドレスに格納されているＲＯＭファームウェアを参照し、命令に従ってハードウェアの初期化処理を行なう（ステップＳ２０２）。例えば、メインメモリ５や外部記録装置６等のハードウェアの初期化を行なう。
【００４１】
ステップＳ２０２においてハードウェアの初期化処理が完了すると、ＣＰＵ２は、例えば、電源制御を行なうファームウェアから通知されるリセット要因（ここでは、ＲＯＭファームウェア運用モード指定フラグに係る運用モード情報ではなく、例えば、電源スイッチによって電源が投入されたのか、或は、再起動によって電源が投入されたのか等の情報のことを示す）が電源投入に因るものか、又は再起動に因るものかを判別する（ステップＳ２０３）。
【００４２】
リセット要因が電源投入に因る場合は、ＣＰＵ２は、処理をステップＳ２０４に移行し、ＲＯＭ３内の所定のアドレスに格納されているＲＯＭファームウェア運用モード指定フラグをシステム運用モードに初期化する。そして、ＲＯＭファームウェア運用モード指定フラグの初期化が完了すると、処理をステップＳ２０５に移行する。
【００４３】
また、ステップＳ２０３において、リセット要因が電源投入でない場合（再起動である場合）は、ＣＰＵ２は、ＲＯＭファームウェア運用モード指定フラグの初期化を行なわずに処理をステップＳ２０５に移行する。
【００４４】
ステップＳ２０５において、ＣＰＵ２は、情報処理装置１を構成する構成要素に関する実装情報等（以下、単に構成情報という）の認識処理を行なう。
例えば、情報処理装置１に備わりステップＳ２０２において正常に初期化処理が完了したＣＰＵ２やメモリ等の構成情報（例えば、ＣＰＵ２の実装数やメモリの実装容量など）を各構成要素に備わるレジスタを読み出すことによって、構成情報を取得する。
【００４５】
ＣＰＵ２やメモリ等の構成情報の認識処理が完了すると、ＣＰＵ２は、処理をステップＳ２０６に移行し、実装されているＣＰＵ２及びメモリ情報をＲＯＭ３内のＲＯＭファームウェア環境変数格納領域に格納する。
【００４６】
さらに、ステップＳ２０８において、ＣＰＵ２は、ＲＯＭ３内の所定のアドレスに格納されているＲＯＭファームウェア運用モード指定フラグを読出し、システム運用モードであるかを判別する処理を行なう。
【００４７】
本実施例では、ＲＯＭファームウェア運用モード指定フラグは１バイトのデータを使用し、当該フラグが０ｘＦＦの場合にダンプ運用モードと判別している。また、当該フラグが０ｘＦＦ以外である場合には、システム運用モードであると判別している。ただし、当該フラグは、上述の場合に限定するものではなく、ダンプ運用モードとシステム運用モードとが判別できるように当該フラグを予め決めた値を使用すればよい。
【００４８】
ステップＳ２０８において、ＣＰＵ２が、システム運用モードでないと判断した場合には、処理をステップＳ２０９に移行し、ステップＳ２０５の処理で取得した実装メモリ情報からダンプ運用モードで使用するメモリ情報テーブル、すなわち、第２のメインメモリ領域を定義したメモリ情報テーブルを作成し、ブートファームウェアにシステムメモリテーブルとして渡す。
【００４９】
ここで、システムメモリテーブルとは、ブートファームウェア、ＯＳローダ、及びＯＳカーネル（又は、ＯＳカーネルを含むＯＳ）がアクセス可能なメモリ領域（又は、メモリ構成）を定義するテーブルである。
【００５０】
したがって、以降に説明する処理（図２Ａから図４に示す処理）において、ダンプ運用モードで動作している場合には、第２のメインメモリ領域に対する処理となる（例えば、ステップＳ２１３のブートファームウェアを展開する領域や、図３のステップＳ３０５のＯＳローダを展開する領域、図４のステップＳ４０１のＯＳカーネルを展開する領域など）
ステップＳ２０９によって、ＲＯＭファームウェアは、例えば、図２Ｂに示すテーブルを作成する。
【００５１】
図２Ｂに示すメモリ情報テーブルは、ＲＯＭファームウェアがダンプ運用モード時に、０ｘ００００００Ｃ０００００００００から始まる５１２ＭＢの連続領域だけがブートファームウェア、ＯＳカーネル、及びＯＳカーネルによって使用可能な領域として定義した場合の例である。
【００５２】
同図に示すメモリ情報テーブルでは、例えば、最初の１２８ＭＢの領域をブートファームウェアが使用し、次の３５８ＭＢの領域をＯＳローダ及びＯＳカーネルが使用する。
また、ステップＳ２０８において、ＣＰＵ２が、システム運用モードであると判断した場合には、処理をステップＳ２１０に移行し、ステップＳ２０５の処理で取得した実装メモリ情報からシステム運用で使用するメモリ情報テーブル、すなわち、第１のメインメモリ領域を定義したメモリ情報テーブルを作成し、ブートファームウェアにシステムメモリテーブルとして渡す。
【００５３】
したがって、以降に説明する処理（図２Ａから図４に示す処理）において、システム運用モードで動作している場合には、第１のメインメモリ領域に対する処理となる（例えば、ステップＳ２１３のブートファームウェアを展開する領域や、図３のステップＳ３０５のＯＳローダを展開する領域、図４のステップＳ４０１のＯＳカーネルを展開する領域など）。
【００５４】
ステップＳ２１０によって、ＲＯＭファームウェアは、例えば、図２Ｃ又は図２Ｄに示すテーブルを作成する。
図２Ｃに示すメモリ情報テーブルは、４つの２５６ＧＢごとの空間の先頭に４ＧＢの連続領域があり、アドレス０ｘ００００００００Ｆ８００００００からの１２８ＭＢの領域をブートファームウェアが使用し、その他の領域をブートファームウェア、ＯＳローダ、及びＯＳカーネルが使用する場合のテーブルを示している。
【００５５】
すなわち、ＲＯＭファームウェアが、システム運用モード時には、メインメモリ５全てを第１のメインメモリ領域として定義した場合の例である（したがって、この場合には、ダンプ運用モード時のみ、第１のメインメモリ領域と第２のメインメモリ領域とを定義することになる）。
【００５６】
また、図２Ｄに示すメモリ情報テーブルは、４つの２５６ＧＢごとの空間の先頭に４ＧＢの連続領域があり、０ｘ００００００００Ｆ８００００００から１２８ＭＢをブートファームウェアが使用し、０ｘ００００００Ｃ０００００００００から始まる連続領域は最後の５１２ＭＢが隠されており、ＯＳカーネル等からは、連続領域としては４ＧＢ−５１２ＭＢしかアクセスできない場合のテーブルを示している。
【００５７】
すなわち、ＲＯＭファームウェアが、０ｘ００００００Ｃ０００００００００から始まる連続領域は最後の５１２ＭＢを第２のメインメモリ領域と定義し、それ以外の領域を第１のメインメモリ領域として定義した場合の例である。したがって、システム運用モード時においては、ブートファームウェア、ＯＳローダ、及びＯＳカーネルからは、上記第１のメインメモリ領域のみアクセス可能な状態である。
【００５８】
メモリ情報テーブルの作成が完了すると、ＣＰＵ２は、処理をステップＳ２１１に移行し、ブートファームウェアに渡すシステムメモリテーブルに設定されているメモリ領域について、メモリの初期化処理及び診断処理を実行する。
【００５９】
例えば、メモリ初期化処理は、メモリのデータに所定のパターン（例えば、オール０）を書き込むことによって行なわれる。また、メモリ診断処理は、所定のパターンについて書き込み読出しを行い、書き込んだパターンと読み出したパターンとの比較を行ない一致するかで異常を判断することによって行なうことができる。
【００６０】
また、本実施例においては、システムメモリテーブルに設定されている使用可能なメモリ領域の全領域をメモリ診断の対象としている。すなわち、システム運用モードの場合には、システム運用時に使用するメモリ領域の全領域をメモリ診断の対象とし、同様に、ダンプ運用モードの場合には、ダンプ運用時に使用するメモリ領域の全領域をメモリ診断の対象としている。
【００６１】
ステップＳ２１１において、メモリの初期化処理及び診断処理が完了すると、ＣＰＵ２は、処理をステップＳ２１２に移行し、システムメモリテーブルで管理するメモリ領域からブートファームウェアを格納するメモリのアドレスを決定する。
【００６２】
例えば、システムメモリテーブルで定義されているメモリ領域のブートファームウェアを格納する開始アドレス（当該メモリ領域からのオフセットアドレス）を、ＲＯＭ３のＲＯＭファームウェア環境変数格納領域の所定のアドレスから読み出す。
【００６３】
ブートファームウェアを格納するメモリのアドレスが決定すると、ＣＰＵ２は、処理をステップＳ２１３に移行し、ＲＯＭ３内の所定のアドレスに格納されているブートファームウェアを読出して、当該アドレスに読み出したブートファームウェアを展開する。
【００６４】
ステップＳ２１３において、ブートファームウェアのメインメモリ５への展開処理が完了すると、ＣＰＵ２は、処理をステップＳ２１４に移行し、システムメモリテーブルへのポインタとＲＯＭファームウェア運用モード指定フラグの値（設定値）をパラメータとしてブートファームウェアに制御を渡すこととなる。
【００６５】
ここで、システムメモリテーブルへのポインタとＲＯＭファームウェア運用モード指定フラグの値をパラメータとしてブートファームウェアに制御を渡す処理は、例えば、ブートファームウェアがアクセス可能なメモリ領域の所定のアドレスに、システムメモリテーブルへのポインタとＲＯＭファームウェア運用モード指定フラグとを格納し、さらに、ブートファームウェアが展開されているメインメモリ５の命令開始アドレスを読み出してＰＣ（Ｐｒｏｇｒａｍ  Ｃｏｕｎｔｅｒ）にセットすればよい。
【００６６】
以上に説明した処理によって、メインメモリ５上にブートファームウェアが展開され、以後はブートファームウェアの命令に従ってＣＰＵ２が動作することとなる。
図３は、本発明の実施例に係るブートファームウェアの処理を示すフローチャートである。
【００６７】
図２Ａに示したステップＳ２１４において、ＣＰＵ２の制御が、ＲＯＭファームウェアからブートファームウェアに移行すると、ＣＰＵ２は、ステップＳ３０１に処理を移行し、ＲＯＭファームウェアからシステムメモリテーブルへのポインタとＲＯＭファームウェア運用モード指定フラグの値をパラメータとして取得する。
【００６８】
ここで、例えば、図２Ａに示したステップＳ２１４において、ＲＯＭファームウェアによって、ブートファームウェアがアクセス可能なメモリ領域の所定のアドレスに、システムメモリテーブルへのポインタとＲＯＭファームウェア運用モード指定フラグとを格納した場合には、当該所定のアドレスをＣＰＵ２が参照することによって、ＲＯＭファームウェアが設定したシステムメモリテーブルへのポインタとＲＯＭファームウェア運用モード指定フラグとをパラメータとして取得することが可能である。
【００６９】
システムメモリテーブルのポインタとＲＯＭファームウェア運用モード指定フラグを取得すると、ＣＰＵ２は、ステップＳ３０２に処理を移行し、取得したシステムメモリテーブルのポインタとＲＯＭファームウェア運用モード指定フラグを、不揮発性メモリ４のブートファームウェア環境変数を格納する領域におけるシステムメモリテーブルのポインタを格納する領域とブートファームウェア運用モード指定フラグを格納する領域に格納する。
【００７０】
そして、ステップＳ３０３において、パラメータとして受け取ったシステムメモリテーブルからブートファームウェアのメモリを管理するためのメモリ管理テーブルを作成する。
【００７１】
ブートファームウェアのメモリ管理テーブルが作成されると、ＣＰＵ２は、制御をステップＳ３０４に移行し、ブートファームウェア用ドライバ（例えば、ＯＳローダやＯＳカーネルが格納されている外部記録装置６にアクセスするためのドライバ（ＳＣＳＩドライバなど）やネットワーク装置を動作させてネットワーク通信を可能にするためのドライバなど）のローディング及処理び初期化処理を行なう。
【００７２】
そして、外部記録装置６からＯＳローダを読出してメインメモリ５に展開し（ステップＳ３０６）、ＣＰＵ２の制御をブートファームウェアからＯＳローダに渡すこととなる（ステップＳ３０６）。
【００７３】
この場合も、図２ＡのステップＳＳ２１４の処理と同様に、ＯＳローダが展開されているメインメモリ５の命令開始アドレスを読み出してＰＣにセットすればよい。
以上に説明した処理によって、メインメモリ５上にＯＳローダが展開され、以後は、ＯＳローダの命令に従ってＣＰＵ２が動作することとなる。
【００７４】
図４は、本発明の実施例に係るＯＳローダ及びＯＳの処理を示すフローチャートである。
図３に示したステップＳ３０６において、ＣＰＵ２の制御が、ブートファームウェアからＯＳローダに移行すると、ＣＰＵ２は、ステップＳ４０１に処理を移行し、外部記録装置６からＯＳカーネルデータを読み出して、メインメモリ５に展開（格納）する。
【００７５】
ＯＳカーネルデータをメインメモリ５に展開する処理が完了すると、ＣＰＵ２は、処理をステップＳ４０２に移行し、メインメモリ５に展開したＯＳカーネルデータを実行可能な形式に配置し、ＯＳカーネルに制御を移行する（例えば、ＣＰＵ２がＯＳカーネルの命令の先頭アドレスから実行される）こととなる。
【００７６】
ＣＰＵ２の制御がＯＳカーネルに移行すると、処理をステップＳ４０３に移行し、ＯＳカーネルの初期化処理が行なわれる。
ＯＳカーネルの初期化処理が完了すると、ＣＰＵ２は、ブートファームウェアのサービスルーチンを呼び出し、不揮発性メモリ４のブートファームウェア環境変数が格納されている領域の所定のアドレスからブートファームウェア運用モード指定フラグを取得する（ステップＳ４０４）。
【００７７】
ここで、ブートファームウェアのサービスルーチンとは、ブートファームウェアとＯＳカーネルとのインターフェースであって、ブートファームウェアの機能をＯＳカーネルから利用可能とするプログラムのことである。
【００７８】
ステップＳ４０５において、ブートファームウェア運用モード指定フラグがダンプ運用モードでない場合には、処理をステップＳ４０６に移行し、システム運用モードとして通常の運用処理を行なう。
【００７９】
また、ステップＳ４０５において、ブートファームウェア運用モード指定フラグがダンプ運用モードである場合には、処理をステップＳ４０７に移行し、ブートファームウェアのサービスルーチンを呼び出して、ダンプ対象のメインメモリ領域の物理アドレス情報を取得する。
【００８０】
そして、ステップＳ４０８に処理を移行し、メインメモリ領域１のメモリダンプ処理を実行する。
さらに、ステップＳ４０９において、ブートファームウェアのサービスルーチンを呼び出し、不揮発性メモリ４に格納されているファームウェア運用モード指定フラグをシステム運用モードに設定する。
【００８１】
以上のメモリダンプ処理が完了すると、ＣＰＵ２は、処理をステップＳ４１０に移行し、再起動処理を呼び出し、システム運用モードにてシステムを再起動する。
図５は、図４のステップＳ４０７に示した第２のメインメモリ領域で動作しているＯＳカーネルのダンププログラムが第１のメインメモリ領域のダンプ対象領域を決定する処理の具体例を示す図である。
【００８２】
同図には、図１に示したメインメモリ５に配される第１のメインメモリ領域と第２のメインメモリ領域とを示している。また、ＯＳは、ダンプ運用モードで起動しているので、第１のメインメモリ領域へのアクセスは原則として不可能な状態であり、第２のメインメモリ領域のみアクセス可能な状態となっている。したがって、ＯＳは、ダンププログラムが起動するブートファームウェアのサービスルーチン又はＲＯＭファームウェアのサービスルーチンによってのみ第１のメインメモリ領域の物理アドレスにアクセスが可能となっている。
【００８３】
また、同図に示す第２のメインメモリ領域には、ＯＳカーネルが、カーネルコア領域７ａとカーネル物理メモリ不連続領域７ｂとカーネル動的割り当て領域７ｃとに展開されており、ＣＰＵ２は、この第２のメインメモリ領域に展開されているＯＳカーネルの命令に従って動作している。
【００８４】
同図に示す第１のメインメモリ領域にも、ＯＳカーネルが、カーネル領域９ａとカーネル物理メモリ不連続領域９ｂとカーネル動的割り当て領域９Ｃとに展開されているが、これらの領域に展開されているＯＳカーネルは、第２のメインメモリ領域に展開されているＯＳカーネルが起動（再起動）される前に展開されたものである。
【００８５】
以下、第２のメインメモリ領域に展開されているＯＳカーネルのダンププログラムによって、第１のメインメモリ領域に展開されている所望のダンプ対象領域を決定する処理について説明する。
【００８６】
（１）カーネルのコア領域９ａなど、物理アドレスが連続な領域に割り当てられるテキスト領域やデータ領域（以下、単に静的テキスト領域、静的データ領域という）をダンプ処理の対象とする場合、まず、カーネル内の静的データ８の論理アドレスと静的データ１０の論理アドレスは、同一カーネルならば同一であるので、ＯＳカーネルから、ブートファームウェアのサービスルーチンを呼び出し、第１のメインメモリ領域でのカーネルコア領域９ａのベースアドレス（カーネルコア領域９ａの先頭アドレス）を取得する。
【００８７】
そして、第２のメインメモリ領域のカーネルコア領域７ａの先頭アドレスから第１のメインメモリ領域のカーネルコアの先頭アドレスを引いた値（オフセット１５）を算出する。
【００８８】
さらに、第２のメインメモリ領域のカーネル内の静的データ８の論理アドレスをアドレス変換テーブル（システムメモリテーブル）に基づいて物理アドレスに変換し、オフセット１５を引くことによって、第２のメインメモリ領域の静的データ８と対応する第１のメインメモリ領域の静的データ１０の物理アドレスが得られる。また、静的テキスト領域についても同様の処理によって、第２のメインメモリ領域の静的テキスト領域に基づいて、ダンプ採取対象である第１のメインメモリ領域内の静的テキスト領域の物理アドレス（例えば、ダンプ対象領域１２の物理アドレス）を得ることができる。
【００８９】
また、さらに通常はこのオフセット１５は第２のメインメモリ領域の先頭アドレスから第２のメインメモリ領域の先頭アドレスをひいたものに等しいため、カーネルコア領域７ａ内の静的データ領域や静的テキスト領域であれば、第１のメインメモリ領域及び第２のメインメモリ領域のベースアドレスの情報と、ダンプ運用モードで動作している第２のメインメモリ領域内のアドレス変換テーブル（システムメモリテーブル）から容易にダンプ対象領域である第１のメインメモリ領域あるカーネルコア９ａの静的データ領域又はテキスト領域のアドレスが得ることが可能である。
【００９０】
（２）物理アドレスが不連続な領域に割り当てられる領域のために、上記（１）で説明したオフセット１５に基づく計算では、第２のメインメモリ領域情報に基づいて第１のメインメモリ領域内のダンプ対象領域（例えば、ダンプ対象領域１３、ダンプ対象領域１４）の物理アドレスが算出できない場合や、静的データ領域ではなく、論理アドレス自体が動的に割り当てられるために第２のメインメモリ領域で動作しているときとは異なった論理アドレスに配置されるようなカーネル内のデータ領域に対してダンプ処理を行なう場合には、第１のメインメモリ領域のカーネル内にあるシステムメモリテーブル（アドレス変換テーブル）１１のデータを参照し、対応する物理アドレスを計算すればよい。
【００９１】
ここで、第１のメインメモリ領域内のカーネルコア領域９ａにあるシステムメモリテーブル１１のある場所の物理アドレスは上記（１）の処理で得ることができる。
ここで、カーネルコア領域７ａ及び９ａは、カーネルテキスト（静的テキスト領域）、カーネルデータ（静的データ領域）の基本的な部分で、カーネル内の各種制御データへリンクするもととなるデータが定義されており、物理アドレスが連続した領域に割り当てられているものとする。
【００９２】
以上の図２Ａから図５に基づいて説明した処理は、情報処理装置１に電源投入又は、ＯＳパニックによる再起動を要因としてＯＳが起動するまでの処理であるが、図６では、ＯＳが異常を検出してから再起動処理が行なわれるまでの処理を説明する。
【００９３】
図６は、ＯＳが異常を検出してから再起動処理が行なわれるまでの処理の例を示すフローチャートである。
情報処理装置１（ＯＳ）がシステム運用モードで動作している状態において、メモリ破壊等のシステム運用を継続するには致命的なハードウェア故障が発生すると、ハードウェアからの割り込み信号や、ＯＳカーネルからのエラー通知によって、ＯＳは異常を検出する（ステップＳ６０１）。
【００９４】
ＯＳが異常を検出すると、ＣＰＵ２は、制御をステップＳ６０２に移行し、ダンプ処理エントリを行なう。例えば、ハードウェアからの割り込み信号に応じて、割り込みハンドラが起動されると、ＣＰＵ２に備わるＰＣにダンププログラムの命令開始アドレスが設定され、ダンプ処理エントリプログラムの命令に従ってＣＰＵ２が動作することとなる。
【００９５】
なお、複数のプログラム（プロセス、タスク、アプリケーション）が同時に動作するＯＳの場合には、ダンプ処理エントリプログラム以外のプログラムも当然に動作している。
そして、処理をステップＳ６０３に移行して、ダンプ処理エントリプログラムからブートファームウェアのサービスルーチンを呼び出し、不揮発性メモリ４内に確保されているＲＯＭファームウェア環境変数領域の所定のアドレスに格納されているＲＯＭファームウェア運用モード指定フラグ、又はＲＯＭファームウェア運用モード指定フラグ及びファームウェア環境変数領域の所定のアドレスに格納されているファームウェア運用モード指定フラグをダンプ運用モードに設定する。
【００９６】
ダンプ運用モードに設定する処理が完了すると、ＣＰＵ２は、制御をステップＳ６０４に移行し、再起動処理を呼び出して再起動を開始する。すなわち、図２Ａに示したステップＳ２０１に処理が移行し、再起動処理（リセット処理）が開始されることとなる。
【００９７】
また、同図では、ステップＳ６０３の処理において、ファームウェアのサービスルーチンによって、ダンプ運用モードを設定する処理を行なったが、ＯＳから直接ＲＯＭファームウェアにアクセスするインターフェース（手段）を用意することによって、ＲＯＭファームウェア運用モード指定フラグ、又はＲＯＭファームウェア運用モード指定フラグ及びファームウェア運用モード指定フラグにダンプ運用モードを設定してもよい。
【００９８】
図７に、ＯＳが異常を検出してから再起動処理が行なわれるまでの処理の変形例を示す。
図６と同様に、情報処理装置１（ＯＳ）がシステム運用モードで動作している状態において、メモリ破壊等のシステム運用を継続するには致命的なハードウェア故障が発生すると、ハードウェアからの割り込み信号や、ＯＳカーネルからのエラー通知によって、ＯＳは異常を検出する（ステップＳ７０１）。
【００９９】
ＯＳが異常を検出すると、ＣＰＵ２は、制御をステップＳ７０２に移行し、ダンプ処理エントリを行なう（ダンプ処理エントリプログラムを起動する）。
そして、処理をステップＳ６０３に移行して、ダンプ処理エントリプログラムからＲＯＭファームウェアのサービスルーチンを呼び出し、不揮発性メモリ４内に確保されているＲＯＭファームウェア運用モード指定フラグ又はファームウェア運用モード指定フラグに一方又は全てに対して、ダンプ運用モードを設定する。
【０１００】
ダンプ運用モードを設定すると、ＣＰＵ２は、制御をステップＳ７０４に移行し、再起動処理を呼び出して再起動を開始する。すなわち、図２Ａに示したステップＳ２０１に処理を移行し、再起動処理が開始されることとなる。
【０１０１】
また、図１において図示しない電源制御手段（例えば、電源制御又は監視を行なうシステム監視機構）が、システム起動時に、ＲＯＭファームウェア運用モード指定フラグ及びファームウェア運用モード指定フラグをダンプ運用モードに設定するようにしてもよい。
【０１０２】
図８は、電源制御手段にダンプ運用モード／システム運用モードの切替手段を持たせた場合に、ＯＳが異常を検出してから再起動処理が行なわれるまでの処理の例を示している。
【０１０３】
図６と同様に、情報処理装置１（ＯＳ）がシステム運用モードで動作している状態において、メモリ破壊等のシステム運用を継続するには致命的なハードウェア故障が発生すると、ハードウェアからの割り込み信号や、ＯＳカーネルからのエラー通知によって、ＯＳは異常を検出する（ステップＳ８０１）。
【０１０４】
ＯＳが異常を検出すると、ＣＰＵ２は、制御をステップＳ８０２に移行し、ダンプ処理エントリを行なう（ダンプ処理エントリプログラムを起動する）。
そして、処理をステップＳ８０３に移行して、ダンプ処理エントリプログラムから、電源制御を行なうシステム監視機構に次回のシステム起動時（図２Ａから図４に示した処理）にＲＯＭファームウェア運用モード指定フラグ、又はＲＯＭファームウェア運用モード指定フラグ及びファームウェア運用モード指定フラグをダンプ運用モードとするように通知する。
【０１０５】
例えば、不揮発性メモリ４内にシステム監視機構の機能を備えるプログラムが参照するメモリ領域を予め確保し、このメモリ領域の所定のアドレスにシステム監視機構運用モード指定フラグを格納するようにする（例えば、１バイトデータで０ｘＦＦであればダンプ運用モードとし、０ｘＦＦ以外をシステム運用モードとする）。
【０１０６】
そして、図６にも示したように、ＯＳがブートファームウェアのサービスルーチンを呼び出して、システム監視機構運用モード指定フラグにダンプ運用モードを設定するようにする。
【０１０７】
一方、システム監視機構は、システム起動時（例えば、図２Ａに示したステップＳ２０１）において、システム監視機構運用モード指定フラグを参照し、ダンプ運用モードに設定されている場合には、ＲＯＭファームウェア運用モード指定フラグ、又はＲＯＭファームウェア運用モード指定フラグ及びファームウェア運用モード指定フラグをダンプ運用モードに設定すればよい。
【０１０８】
システム監視機構にダンプ運用モードを通知すると、ＣＰＵ２は、制御をステップＳ８０４に移行し、再起動処理を呼び出して再起動を開始する。すなわち、図２Ａに示したステップＳ２０１に処理を移行し、再起動処理が開始されることとなる。
【０１０９】
また、システム監視機構によって、例えば、ＲＯＭファームウェア運用モード指定フラグ、又はＲＯＭファームウェア運用モード指定フラグ及びブートファームウェア運用モード指定フラグを、強制的にダンプ運用モードに設定して再起動を実行させるようにしてもよい。
【０１１０】
これにより、ＯＳがハングアップし、ダンプ処理エントリに制御が移行できなくなっても、ダンプ運用モードで再起動ができるようになるのでダンプ採取を行なうことが可能となる。
【０１１１】
以上の説明においては、第１のメインメモリ領域と第２のメインメモリ領域とは、システム運用モード時及びダンプ運用モード時の両モード時においても分割されているが、これに限定するものではない。すなわち、システム運用モード時においては、メインメモリ５の全ての領域を図１に示した第１のメインメモリ領域として使用し、ダンプ運用モード時にのみ第１のメインメモリ領域と第２のメインメモリ領域とに分割してもよい。この場合、第１のメインメモリ領域で使用頻度が少ない領域や障害解析に不要な領域等を第２のメインメモリ領域として割り当てればよい。
【０１１２】
以上に説明したダンプ処理によって採取したデータを障害解析する場合には、障害解析に必要な領域の決定のためにカーネル固有のテーブル（例えば、データの配置の定義したテーブル）を参照する必要があるが、ダンプ運用モードで動作しているカーネルは、システム運用モードで動作しているカーネルと同一のものであるため同一のテーブルを使用して所定のデータが配置されているアドレス等の情報を取得することが可能であり、容易に障害解析することが可能となる。
【０１１３】
また、システムダンプ採取プログラムがシステム運用モード時と同一のカーネル（オペレーティングシステム）で動作するため、ダンプ採取領域を決定するためにメインメモリ上の領域を管理するテーブル情報（例えば、メモリ管理テーブルなど）からシステムダンプを取得すべき領域のリストを予め作成しておく必要がなく、カーネルの版数と領域リストの版数（又は、領域リストを作成するためのテーブル情報の版数）を管理する必要がなくなる。
【０１１４】
したがって、カーネルの版数と領域リストの版数（又は、領域リストを作成するためのテーブル情報の版数）との不一致によって、誤った領域をダンプしてしまったり、メモリの未実装領域にアクセスしてしまいシステムダンプの採取が異常終了してしまうことを回避することが可能となる。また、余計な版数管理を行う必要がなくなる。
【０１１５】
さらに、システムダンプ時にカーネルに組み込まれたダンプ採取プログラムが動作するので、障害発生時のメモリデータから障害解析に必要な最適な領域をダンプ採取することが可能となる。
【０１１６】
そして、ダンプを採取するために、一度リセットを実施するので、安定したオペレーティングシステム上でダンプ採取することができ、また、単に所定の領域をダンプ採取するだけでなく、障害解析プログラムなどによりカーネル内データを解析して、障害の原因や被疑箇所の特定を障害発生時にある程度行うことも可能となる。また、そのときの解析結果に応じて、さらにダンプ採取領域を広げるなどの対応も可能となる。
【０１１７】
また、ダンプ運用モード時には、オペレーティングシステムをブートするブートファームウェアも含めて、システム運用モード時とは別の物理メモリ空間でオペレーティングシステムを起動するので、オペレーティングシステムとブートファームウェア間のインターフェース部分で異常が発生してハングアップした場合などでもダンプ採取時に異常が発生した時のブートファームウェア領域のデータも壊さずにダンプすることが可能となる。
【０１１８】
ダンプ対象であるシステム運用モード時に使用したメモリ領域のデータを上書きすることがないのでブートファームウェア側でメモリデータを一時待避する必要がなく、メモリデータを一時待避するための専用のハードウェア資源を持つ必要がないので、信頼性を高めながらコストを抑えることが可能となる。そのため、メモリデータの一時待避用に専用パーティションを確保しておく必要もないためディスクのパーティション管理も容易となる。
【０１１９】
さらに、障害が発生した環境（カーネルの制御データの不整合やメモリ破壊など）とは無関係にダンプ採取を行なうことが可能となる。
また、一時的なハード異常が発生していた場合には、一旦リセットすることにより、正常に動作できる可能性を高めることが可能となり、恒常的なハード異常が発生していた場合でも、リセットによるシステムの再起動時に実行されるＰＯＳＴ診断やハードウェアの初期化処理で異常を検出できる可能性を高めることが可能となる。
【０１２０】
（付記１）  情報処理装置の動作を制御する運用モード指定情報に応じて、前記情報処理装置が備える記憶手段の領域をオペレーティングシステムに使用していた第１の領域以外の第２の領域に画する第２の領域定義情報を記憶した領域定義情報手段から、該第２の領域定義情報を取得する領域定義情報取得処理と、
該第２の領域定義情報に基づく領域にオペレーティングシステムを格納するオペレーティングシステム格納処理と、
前記第２の領域定義情報に基づく領域における所定の領域に対応する前記第１の領域における所定の領域をダンプ対象領域として算出するダンプ対象領域算出処理と、
該ダンプ対象領域に格納されている情報を読み出して出力するダンプ処理と、
を備えるパニックダンプ採取処理をコンピュータに実行させるためのプログラム。
【０１２１】
（付記２）  情報処理装置が動作するために必要な構成要素に障害が発生したことを検出して通知する障害通知処理と、
該障害通知処理による通知に応じて、前記運用モード指定情報を運用モード指定情報記憶手段に記憶する運用モード指定情報記憶処理と、
前記障害発生時に使用されていた領域の状態を保持したまま、前記情報処理装置を再起動する再起動処理と、
を更に前記領域定義情報取得処理の前に備える付記１に記載のパニックダンプ採取処理をコンピュータに実行させるためのプログラム。
【０１２２】
（付記３）  前記ダンプ対象領域算出処理は、前記ダンプ対象領域を、前記第１の領域の先頭位置と前記第２の領域の先頭位置とのオフセットと、前記第２の領域における所定の領域と、の差によって算出する処理であることを特徴とする付記１又は２に記載のパニックダンプ採取を行なうためのプログラム。
【０１２３】
（付記４）  前記ダンプ対象領域算出処理は、前記ダンプ対象領域を、前記第１の領域の先頭位置と前記第２の領域の先頭位置とのオフセットと、前記第２の領域における所定の領域と、の差によって算出する情報と、前記第１の領域を管理するための情報とに基づいて取得する処理であることを特徴とする付記１から３のいずれか一項に記載のパニックダンプ採取を行なうためのプログラム。
【０１２４】
（付記５）  情報処理装置の動作を制御する運用モード指定情報に応じて、前記情報処理装置が備える記憶手段の領域を、オペレーティングシステムに使用していた第１の領域以外の第２の領域に画する第２の領域定義情報を記憶した領域定義情報手段から、該第２の領域定義情報を取得する領域定義情報取得処理と、
該第２の領域定義情報に基づく領域にオペレーティングシステムを格納するオペレーティングシステム格納処理と、
前記第２の領域定義情報に基づく領域における所定の領域に対応する前記第１の領域における所定の領域をダンプ対象領域として算出するダンプ対象領域算出処理と、
該ダンプ対象領域に格納されている情報を読み出して出力するダンプ処理と、
を行なうパニックダンプ採取方法。
【０１２５】
（付記６）  情報処理装置が動作するために必要な構成要素に障害が発生したことを検出して通知する障害通知処理と、
該障害通知処理による通知に応じて、前記運用モード指定情報を運用モード指定情報記憶手段に記憶する運用モード指定情報記憶処理と、
前記障害発生時に使用されていた領域の状態を保持したまま、前記情報処理装置を再起動する再起動処理と、
を更に前記領域定義情報取得処理の前に備える付記５に記載のパニックダンプ採取方法。
【０１２６】
（付記７）  前記ダンプ対象領域算出処理は、前記ダンプ対象領域を、前記第１の領域の先頭位置と前記第２の領域の先頭位置とのオフセットと、前記第２の領域における所定の領域と、の差によって算出する処理であることを特徴とする付記５又は６に記載のパニックダンプ採取方法。
【０１２７】
（付記８）  前記ダンプ対象領域算出処理は、前記ダンプ対象領域を、前記第１の領域の先頭位置と前記第２の領域の先頭位置とのオフセットと、前記第２の領域における所定の領域と、の差によって算出する情報と、前記第１の領域を管理するための情報とに基づいて取得する処理であることを特徴とする付記５から７のいずれか一項に記載のパニックダンプ採取方法。
【０１２８】
（付記９）  情報処理装置の動作を制御する運用モード指定情報に応じて、前記情報処理装置が備える記憶手段の領域をオペレーティングシステムに使用していた第１の領域以外の第２の領域に画する第２の領域定義情報を記憶した領域定義情報手段から、該第２の領域定義情報を取得する領域定義情報取得手段と、
該第２の領域定義情報に基づく領域にオペレーティングシステムを格納するオペレーティングシステム格納手段と、
前記第２の領域定義情報に基づく領域における所定の領域に対応する前記第１の領域における所定の領域をダンプ対象領域として算出するダンプ対象領域算出手段と、
該ダンプ対象領域に格納されている情報を読み出して出力するダンプ手段と、
を備えるパニックダンプ採取機構。
【０１２９】
（付記１０）  情報処理装置が動作するために必要な構成要素に障害が発生したことを検出して通知する障害通知手段と、
該障害通知手段による通知に応じて、前記運用モード指定情報を記憶する運用モード指定情報記憶手段と、
前記障害発生時に使用されていた領域の状態を保持したまま、前記情報処理装置を再起動する再起動手段と、
を更に備える付記９に記載のパニックダンプ採取機構。
【０１３０】
（付記１１）  前記ダンプ対象領域算出手段は、前記ダンプ対象領域を、前記第１の領域の先頭位置と前記第２の領域の先頭位置とのオフセットと、前記第２の領域における所定の領域と、の差によって算出する処理であることを特徴とする付記９又は１０に記載のパニックダンプ採取機構。
【０１３１】
（付記１２）  前記ダンプ対象領域算出手段は、前記ダンプ対象領域を、前記第１の領域の先頭位置と前記第２の領域の先頭位置とのオフセットと、前記第２の領域における所定の領域と、の差によって算出する情報と、前記第１の領域を管理するための情報とに基づいて取得する処理であることを特徴とする付記９から１１のいずれか一項に記載のパニックダンプ採取機構。
【図面の簡単な説明】
【０１３２】
【図１】本発明の実施例に係る構成の主要部の例を示す図である。
【図２Ａ】本発明の実施例に係るＲＯＭファームウェアの処理を示すフローチャートである。
【図２Ｂ】ＲＯＭファームウェアが作成するシステム運用モード時のメモリ情報テーブルの例を示す図である。
【図２Ｃ】ＲＯＭファームウェアが作成するシステム運用モード時のメモリ情報テーブルの例を示す図である。
【図２Ｄ】ＲＯＭファームウェアが作成するダンプ運用モード時のメモリ情報テーブルの例を示す図である。
【図３】本発明の実施例に係るブートファームウェアの処理を示すフローチャートである。
【図４】本発明の実施例に係るＯＳローダ及びＯＳの処理を示すフローチャートである。
【図５】図５に示したステップＳ４０７からステップＳ４０９の処理の具体例を示す図である。
【図６】ＯＳが異常を検出してから再起動処理が行なわれるまでの処理を示すフローチャートである。
【図７】ＯＳが異常を検出してから再起動処理が行なわれるまでの処理の変形例を示すフローチャートである。。
【図８】電源制御手段にダンプ運用モード／システム運用モードの切替手段を持たせた場合に、ＯＳが異常を検出してから再起動処理が行なわれるまでの処理の例を示している。
【符号の説明】
【０１３３】
１      情報処理装置
２      ＣＰＵ
３      ＲＯＭ
４      不揮発性メモリ
５      メインメモリ
６      外部記録装置
７ａ    カーネルコア領域
７ｂ    カーネル物理メモリ不連続領域
７ｃ    カーネル動的割り当て領域
８      静的データ
９ａ    カーネルコア領域
９ｂ    カーネル物理メモリ不連続領域
９ｃ    カーネル動的割当て領域
１０      静的データ
１１      アドレス情報
１２      ダンプ対象領域Ａ
１３      ダンプ対象領域Ｂ
１４      ダンプ対象領域Ｃ
１５      オフセット
【図１】
2006072931.tif 000003
【図２Ａ】
2006072931.tif 000004
【図２Ｂ】
2006072931.tif 000005
【図２Ｃ】
2006072931.tif 000006
【図２Ｄ】
2006072931.tif 000007
【図３】
2006072931.tif 000008
【図４】
2006072931.tif 000009
【図５】
2006072931.tif 000010
【図６】
2006072931.tif 000011
【図７】
2006072931.tif 000012
【図８】
2006072931.tif 000013