JP4677214B2 - パニックダンプ採取のためのプログラム、方法、及び機構 - Google Patents

パニックダンプ採取のためのプログラム、方法、及び機構 Download PDF

Info

Publication number
JP4677214B2
JP4677214B2 JP2004258750A JP2004258750A JP4677214B2 JP 4677214 B2 JP4677214 B2 JP 4677214B2 JP 2004258750 A JP2004258750 A JP 2004258750A JP 2004258750 A JP2004258750 A JP 2004258750A JP 4677214 B2 JP4677214 B2 JP 4677214B2
Authority
JP
Japan
Prior art keywords
area
dump
operation mode
information
operating system
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Expired - Fee Related
Application number
JP2004258750A
Other languages
English (en)
Other versions
JP2006072931A (ja
Inventor
幸雄 小熊
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Fujitsu Ltd
Original Assignee
Fujitsu Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Fujitsu Ltd filed Critical Fujitsu Ltd
Priority to JP2004258750A priority Critical patent/JP4677214B2/ja
Priority to US11/023,184 priority patent/US7631224B2/en
Priority to EP05250187A priority patent/EP1638000B1/en
Publication of JP2006072931A publication Critical patent/JP2006072931A/ja
Application granted granted Critical
Publication of JP4677214B2 publication Critical patent/JP4677214B2/ja
Expired - Fee Related legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00Error detection; Error correction; Monitoring
    • G06F11/07Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/0703Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation
    • G06F11/0766Error or fault reporting or storing
    • G06F11/0778Dumping, i.e. gathering error/state information after a fault for later diagnosis
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00Error detection; Error correction; Monitoring
    • G06F11/07Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/0703Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation
    • G06F11/0706Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation the processing taking place on a specific hardware platform or in a specific software environment
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00Arrangements for program control, e.g. control units
    • G06F9/06Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44Arrangements for executing specific programs
    • G06F9/4401Bootstrapping
    • G06F9/4406Loading of operating system

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Software Systems (AREA)
  • Quality & Reliability (AREA)
  • Health & Medical Sciences (AREA)
  • Biomedical Technology (AREA)
  • Computer Security & Cryptography (AREA)
  • Debugging And Monitoring (AREA)
  • Retry When Errors Occur (AREA)

Description

本発明は、障害発生時のパニックダンプ採取のためのプログラム、方法、及び機構に関する。
情報通信技術が普及するに従って、情報処理装置、特に基幹システムで運用されるサーバシステムには高い信頼性が要求される。そのため、システム運用中に障害が発生した場合には、すみやかに情報を収集し、運用を継続させることが不可欠である。
一般に、致命的な障害の発生によりシステムの運用を継続できなくなった場合には、情報採取の手段として、障害発生時のメモリデータをダンプする、いわゆるパニックダンプ機能が用いられている。
パニックダンプは、システム運用中に、システムを継続動作させることが不可能な異常を検出した場合に、その時点でのメモリ内容を保存するものであり、通常はOS(Operating System)又は、カーネル内で動作するプログラムがダンプ処理を行っている。
例えば、CPUがカーネル内のプログラムを動作させている場合に、異常検出の割り込み信号を受け付けると、CPUはカーネルに組み込まれているメモリダンププログラムに制御を移行し、メモリダンプ採取を行う。
メモリダンププログラムは、カーネルに組み込まれているので、カーネル内のシステムテーブルを解析して障害解析に必要な情報を最適のダンプサイズでダンプ可能である。
しかし、異常の原因が、例えば、カーネル内で動作するプログラム自体、制御データの不整合、カーネル(プログラム)が格納されているメモリの破壊、ハードウェアの異常等であった場合には、ダンプ処理において異常の原因となった資源(例えば、破壊されたメモリ)を必要とする可能性がある。そのような場合、ダンプ処理の実行中に再度異常が発生するためダンプ処理に失敗する結果となる。
また、異常の種類によってはシステムがハングアップし、パニックダンプ処理まで処理が進めないためメモリデータをダンプすることができない場合もある。
このような問題を解決するための手段として、メモリデータを保存したままシステムにリセットをかけ、ダンプしたいメモリデータ以外のハード資源を再設定してダンプ処理プログラムを起動しなおし、その環境でメモリデータをダンプするスタンドアロンダンプが知られている。
例えば、上述のようにカーネルに組み込まれたメモリダンププログラムよるメモリダンプ採取に失敗し、システムがハングした場合、メモリに格納されているデータを保存した状態のままシステムにリセットをかけ、カーネルに組み込まれたメモリダンププログラムとは別の専用のメモリダンププログラム(スタンドアロンダンププログラム)を起動してメモリダンプを採取する。
スタンドアロンダンプによって、異常が発生した環境(カーネルの制御データの不整合やメモリ破壊など)とは無関係にダンプ採取が行え、一時的なハードウェアの異常である場合には、一旦ハードウェアをリセットすることにより、正常に動作できる可能性が高まる。また、恒常的なハードウェアの異常である場合には、リセットによるシステムの再起動時に実行されるPOST(Power On Self Test)診断やハードウェアの初期化処理で異常を検出できる可能性が高まる。
特開平08−095834号公報
しかし、従来のスタンドアロンダンプでは以下のような問題点があった。
1)システムにリセットをかけ、スタンドアロンダンプをダウンロードするため、スタンドアロンダンプが上書きするメモリ領域のデータをあらかじめ保存しておく必要がある。これは、スタンドアロンダンプをロード(格納)する前にOSをブートするためのブートファームウェアで行う必要がある。
そのため、ブートファームウェア側でメモリデータを一時待避させるだけのハードウェア資源を持つか、またはディスクなどにブートファームウェアが制御可能な専用パーティションを確保し、そこにファイルとして保存する必要がある。
専用ハードウェア資源を持つ場合にはコスト的に不利である。また、専用パーティションを持つ場合には、接続ディスクに必ずメモリデータの一時待避のための専用パーティションが存在することを保証しなければならないが、接続ディスクに専用パーティションが確保されているかいないかはブートファームウェアからは制御できないため、ディスクのパーティション管理が複雑になるという問題がある。
2)障害発生時のメモリデータを保存した状態でスタンドアロンダンプをブートするため、メモリ上のブートファームウェアやOSローダ(OSをメモリにロードするためのプログラム)のデータは、システムのブート処理で完全に上書きされてしまう。
そのため、カーネルとこれらブートファームウェアやOSローダの間で異常が発生した場合には、ファームウェアのデータはダンプデータとして採取できないため調査が困難となってしまう問題がある。
3)サーバシステムは通常、数GB又は数十GB以上のメインメモリを搭載しているため、パニックダンプで全メモリのデータを採取することは現実的ではない。そのため、通常は調査に必要なオペレーティングシステムのカーネルテキスト、カーネルデータなどの領域だけを採取する。この領域の情報を取得するためにはカーネル内のテーブルを検索し解析する必要があるが、これらの情報はカーネルの版数によって異なっているため、オペレーティングシステムと別プログラムであるスタンドアロンダンプを使用する場合にはオペレーティングシステムの版数に対応したスタンドアロンダンププログラムを用意する必要がある。そのため、スタンドアロンダンプの版数は対応するオペレーティングシステムの版数と合っている必要がある。もし、合っていない場合には、カーネル内のテーブルを検索することができないため、ダンプに失敗するか、実装する全メモリデータをダンプしなくてはいけなくなってしまう。
特許文献1には、これらの問題点の1)および2)を解決するために、システムの主記憶メモリ領域に、通常稼働時には使用されないシステムダンプ採取プログラム使用領域を、オペレーティングシステムが使用するオペレーティングシステム使用領域とは別に設け、ハングアップ等によりシステムダンプが採取できないときに、計算機システムをリセットした後、オペレーティングシステムをオペレーティングシステム使用領域に再ロードする前に、外部記憶装置からシステムダンプ採取プログラムをシステムダンプ採取プログラム使用領域にロードして実行することによりオペレーティングシステム使用領域のシステムダンプを採取することを特徴とするシステムについて開示されている。
しかし、オペレーティングシステムとは別のスタンドアロンダンプシステムでは、上記3)で指摘した問題点を解決することができない。すなわち、特許文献1で開示されているシステムにおいても、静的または動的にアロケーションされた主記憶装置上の領域を管理するテーブル情報からシステムダンプを取得すべき領域のリストを予め作成しておくことにより、このリストに示された領域のみシステムダンプを採取するようにしているので、対象とする領域のリストを予め用意しておかなければならない。
このリストの情報を作成するための情報は通常オペレーティングシステムの版数に強く依存しているため、オペレーティングシステムの版数管理とリストの版数管理が複雑となる問題が解決できない。
さらに、システムダンプを取得すべき領域のリストは予め作成しておかなければいけないので、オペレーティングシステムが動作中に動的に割り当てた領域をきめ細かく予測できず、システム構成が複雑な大規模サーバシステムの場合には必要な情報を効率よく採取することが難しいという問題がある。また、もし、パッチにより版数合わせに失敗した場合、必要な領域が採取不可能となってしまう問題がある。
本発明は、上述した問題に鑑みてなされたものであり、その解決しようとする問題は、障害発生時のパニックダンプによるメモリデータ採取処理を確実に行なうことを可能にするパニックダンプ採取のためのプログラム、方法、及び機構を提供することである。
請求項1に記載の発明は、情報処理装置の動作を制御する運用モード指定情報に応じて、前記情報処理装置が備える記憶手段の領域をオペレーティングシステムに使用していた第1の領域以外の第2の領域に画する第2の領域定義情報を記憶した領域定義情報手段から、該第2の領域定義情報を取得する領域定義情報取得処理と、該第2の領域定義情報に基づく領域にオペレーティングシステムを格納するオペレーティングシステム格納処理と、前記第2の領域定義情報に基づく領域における所定の領域に対応する前記第1の領域における所定の領域をダンプ対象領域として算出するダンプ対象領域算出処理と、該ダンプ対象領域に格納されている情報を読み出して出力するダンプ処理と、を備えるパニックダンプ採取処理をコンピュータに実行させるためのプログラムである。
請求項1に記載の発明によると、前記ダンプ対象領域算出処理によって、前記領域定義情報取得処理によって取得した前記第2の領域における所定の領域に対応する前記第1の領域(障害発生時に使用されていた領域)における所定の領域を算出して、該算出されたダンプ対象領域のデータを出力するので、障害発生時に使用していた領域のデータを確実に取得することが可能となる。
また、前記第1の領域、すなわち、障害発生時に使用されていた領域で動作していたオペレーティングシステムと、前記第2の領域で動作するオペレーティングシステムは、同一の領域管理(例えば、メモリ管理テーブルによって、オペレーティングシステム等が動作するために必要なプログラムを含むデータのメモリアドレスを管理する場合など)を行なうので、前記ダンプ対象領域算出処理によって、前記領域定義情報取得処理によって取得した前記第2の領域における所定の領域に対応する前記第1の領域における所定の領域を容易に算出することが可能となる。
請求項2に記載の発明は、情報処理装置が動作するために必要な構成要素に障害が発生したことを検出して通知する障害通知処理と、該障害通知処理による通知に応じて、前記情報処理装置の動作を制御する運用モード指定情報を運用モード指定情報記憶手段に記憶する運用モード指定情報記憶処理と、前記障害発生時に使用されていた領域の状態を保持したまま、前記情報処理装置を再起動する再起動処理と、前記運用モード指定情報に応じて、前記情報処理装置が備える記憶手段の領域をオペレーティングシステムに使用していた第1の領域以外の第2の領域に画する第2の領域定義情報を記憶した領域定義情報手段から、該第2の領域定義情報を取得する領域定義情報取得処理と、該第2の領域定義情報に基づく領域にオペレーティングシステムを格納するオペレーティングシステム格納処理と、前記第2の領域定義情報に基づく領域における所定の領域に対応する前記第1の領域における所定の領域をダンプ対象領域として算出するダンプ対象領域算出処理と、該ダンプ対象領域に格納されている情報を読み出して出力するダンプ処理と、を備えるパニックダンプ採取処理をコンピュータに実行させるためのプログラムである。
請求項2に記載の発明によると、請求項1に記載の発明の効果に加えて、障害が発生すると、再起動処理によって、情報処理装置(又は、情報処理装置を構成する構成要素、及びそれらを制御するためのプログラム)が再起動し、前記領域定義情報取得処理によって前記情報処理装置が備える記憶手段の領域を複数の領域に画するための領域定義情報を記憶した領域定義情報手段から、オペレーティングシステムに使用していた第1の領域以外の第2の領域についての領域定義情報を取得し、該取得した前記領域定義情報に基づく領域にオペレーティングシステムがローディングされるので、前記障害発生時に使用されていた領域を保持したままリセット処理を行なうことが可能となる。
請求項3に記載の発明は、前記ダンプ対象領域算出処理は、前記ダンプ対象領域を、前記第1の領域の先頭位置と前記第2の領域の先頭位置とのオフセットと、前記第2の領域における所定の領域と、の差によって算出する処理であることを特徴とする請求項1又は2に記載のパニックダンプ採取を行なうためのプログラムである。
請求項3に記載の発明によると、前記第1の領域の先頭位置と前記第2の領域の先頭位置とのオフセットと、前記第2の領域における所定の領域と、の差によって、前記第2の領域における所定の領域に対応する前記第1の領域を、算出することによって、ダンプ対象領域を容易に算出して取得することが可能となる。
請求項4に記載の発明は、情報処理装置の動作を制御する運用モード指定情報に応じて、前記情報処理装置が備える記憶手段の領域を、オペレーティングシステムに使用していた第1の領域以外の第2の領域に画する第2の領域定義情報を記憶した領域定義情報手段から、該第2の領域定義情報を取得する領域定義情報取得処理と、該第2の領域定義情報に基づく領域にオペレーティングシステムを格納するオペレーティングシステム格納処理と、前記第2の領域定義情報に基づく領域における所定の領域に対応する前記第1の領域における所定の領域をダンプ対象領域として算出するダンプ対象領域算出処理と、該ダンプ対象領域に格納されている情報を読み出して出力するダンプ処理と、を行なうパニックダンプ採取方法である。
請求項5に記載の発明は、情報処理装置の動作を制御する運用モード指定情報に応じて、前記情報処理装置が備える記憶手段の領域をオペレーティングシステムに使用していた第1の領域以外の第2の領域に画する第2の領域定義情報を記憶した領域定義情報手段から、該第2の領域定義情報を取得する領域定義情報取得手段と、該第2の領域定義情報に基づく領域にオペレーティングシステムを格納するオペレーティングシステム格納手段と、前記第2の領域定義情報に基づく領域における所定の領域に対応する前記第1の領域における所定の領域をダンプ対象領域として算出するダンプ対象領域算出手段と、該ダンプ対象領域に格納されている情報を読み出して出力するダンプ手段と、を備えるパニックダンプ採取機構である。
請求項4及び請求項5に記載の発明によっても、請求項1と同様に、障害が発生すると、前記ダンプ対象領域算出処理(又は、前記ダンプ対象領域算出手段)によって、前記領域定義情報取得処理によって取得した前記第2の領域における所定の領域に対応する前記第1の領域(障害発生時に使用されていた領域)における所定の領域を算出して、該算出されたダンプ対象領域のデータを出力するので、障害発生時に使用していた領域のデータを確実に取得することが可能となる。
また、前記第1の領域、すなわち、障害発生時に使用されていた領域で動作していたオペレーティングシステムと、前記第2の領域で動作するオペレーティングシステムは、同一の領域管理を行なうので、前記ダンプ対象領域算出処理(又は、前記ダンプ対象領域算出手段)によって、前記領域定義情報取得処理によって取得した前記第2の領域における所定の領域に対応する前記第1の領域における所定の領域を容易に算出することが可能となる。
以上のように、本発明によると、障害発生時のパニックダンプによるメモリデータ採取処理を確実に行なうことを可能にするパニックダンプ採取のためのプログラム、方法、及び機構を提供することができる。
以下、本発明の実施形態について図1から図8に基づいて説明する。
図1は、本発明の実施例に係る構成の主要部の例を示す図である。
同図に示す情報処理装置1は、情報処理装置の各構成要素を制御し本実施例に係るプログラムに応じて処理を行なう図示しないCPU2と、本実施例に係るROMファームウェア及びブートファームウェア等を格納するROM(Read Only Memory)3と、ROMファームウェアが使用する環境変数及びブートファームウェアが使用する環境変数(例えば、ROMファームウェア運用モード指定フラグやブートファームウェア運用モード指定フラグ等)などを格納するNVRAM(Non Volatile RAM)やFlash Memory等で構成される不揮発性メモリ4と、ブートファームウェアやOSローダ、OSカーネル等を格納するメインメモリ5と、を少なくとも備える情報処理装置である。
また、本実施例に係る情報処理装置1は、OSローダ及びOSカーネルを記憶する外部記録装置6(例えば、磁気ディスク装置)と接続される。なお、同図に示す外部記録装置6は、情報処理装置1外部に接続されているが内部にあってもよい。
本体装置の電源が投入されると、ROM3に格納されたROMファームウェアが起動し、ハードウェアの初期化と診断を実行し、ハードウェアの構成認識処理を行う。構成認識処理では、実装CPU2の数や実装メモリ(実装されているメインメモリ5)の構成などの認識を行い、構成情報をROMファームウェア環境変数格納領域に格納する。
ROMファームウェアは、ROM3の所定のアドレスからブートファームウェアデータを読み出しメインメモリ5に格納し、メインメモリ5上に実行可能なブートファームウェアとして展開して、ブートファームウェアに制御を渡す。
ここで、ROMファームウェアはブートファームウェアに制御を渡す時に構成認識処理で認識したハードウェアのメモリ構成情報を渡すか、または、メモリの構成情報を通知するメソッドを提供する。
ブートファームウェアは、システム全体のメモリの実装状態を認識するとともに、OSローダ、及びOSをこのメモリ実装環境下で動作させる。
また、OS起動後も一部のプログラムは、メインメモリ5上に常駐し、OSローダやOSに対して各種のサービスを提供する。
したがって、OSローダやOSカーネルは、ハードウェアの情報を直接見ることなく、抽象化された構成情報(例えば、現実に実装されたメモリの構成情報ではなく、ブートファームウェアによって通知されたメモリの構成情報)を見ることによって、個々のハードウェアの仕様に依存しないで汎用性を高めるようになっている。
また、第1のメインメモリ領域と第2のメインメモリ領域は、ROMファームウェアからブートファームウェアに通知されるメモリの構成情報に基づいて決定される。
以上に説明した本実施例に係るメインメモリ5は、第1のメインメモリ領域7と第2のメインメモリ領域8とで構成されるが、論理的に2つのメモリ領域に分割されていればよく、物理的には1つメモリで構成されてもよい。また、複数の(物理的に分割された)メモリで構成されてもよい。また、論理的に2以上のメモリ領域(例えば、第1のメモリ領域、第2のメインメモリ領域、及び第3のメインメモリ領域)に分割してもよい。
図2Aから図4に、情報処理装置1に電源が投入された場合、及び再起動の場合(OSがパニックを起こした場合の再起動処理)について処理のフローチャートを示し、図面に基づいて処理を説明する。
図2Aは、本発明の実施例に係るROMファームウェアの処理を示すフローチャートである。
情報処理装置1が電源投入、又は再起動されると(ステップS201)、情報処理装置1に備わるCPU2は、ROM3の所定のアドレスに格納されているROMファームウェアを参照し、命令に従ってハードウェアの初期化処理を行なう(ステップS202)。例えば、メインメモリ5や外部記録装置6等のハードウェアの初期化を行なう。
ステップS202においてハードウェアの初期化処理が完了すると、CPU2は、例えば、電源制御を行なうファームウェアから通知されるリセット要因(ここでは、ROMファームウェア運用モード指定フラグに係る運用モード情報ではなく、例えば、電源スイッチによって電源が投入されたのか、或は、再起動によって電源が投入されたのか等の情報のことを示す)が電源投入に因るものか、又は再起動に因るものかを判別する(ステップS203)。
リセット要因が電源投入に因る場合は、CPU2は、処理をステップS204に移行し、ROM3内の所定のアドレスに格納されているROMファームウェア運用モード指定フラグをシステム運用モードに初期化する。そして、ROMファームウェア運用モード指定フラグの初期化が完了すると、処理をステップS205に移行する。
また、ステップS203において、リセット要因が電源投入でない場合(再起動である場合)は、CPU2は、ROMファームウェア運用モード指定フラグの初期化を行なわずに処理をステップS205に移行する。
ステップS205において、CPU2は、情報処理装置1を構成する構成要素に関する実装情報等(以下、単に構成情報という)の認識処理を行なう。
例えば、情報処理装置1に備わりステップS202において正常に初期化処理が完了したCPU2やメモリ等の構成情報(例えば、CPU2の実装数やメモリの実装容量など)を各構成要素に備わるレジスタを読み出すことによって、構成情報を取得する。
CPU2やメモリ等の構成情報の認識処理が完了すると、CPU2は、処理をステップS206に移行し、実装されているCPU2及びメモリ情報をROM3内のROMファームウェア環境変数格納領域に格納する。
さらに、ステップS208において、CPU2は、ROM3内の所定のアドレスに格納されているROMファームウェア運用モード指定フラグを読出し、システム運用モードであるかを判別する処理を行なう。
本実施例では、ROMファームウェア運用モード指定フラグは1バイトのデータを使用し、当該フラグが0xFFの場合にダンプ運用モードと判別している。また、当該フラグが0xFF以外である場合には、システム運用モードであると判別している。ただし、当該フラグは、上述の場合に限定するものではなく、ダンプ運用モードとシステム運用モードとが判別できるように当該フラグを予め決めた値を使用すればよい。
ステップS208において、CPU2が、システム運用モードでないと判断した場合には、処理をステップS209に移行し、ステップS205の処理で取得した実装メモリ情報からダンプ運用モードで使用するメモリ情報テーブル、すなわち、第2のメインメモリ領域を定義したメモリ情報テーブルを作成し、ブートファームウェアにシステムメモリテーブルとして渡す。
ここで、システムメモリテーブルとは、ブートファームウェア、OSローダ、及びOSカーネル(又は、OSカーネルを含むOS)がアクセス可能なメモリ領域(又は、メモリ構成)を定義するテーブルである。
したがって、以降に説明する処理(図2Aから図4に示す処理)において、ダンプ運用モードで動作している場合には、第2のメインメモリ領域に対する処理となる(例えば、ステップS213のブートファームウェアを展開する領域や、図3のステップS305のOSローダを展開する領域、図4のステップS401のOSカーネルを展開する領域など)
ステップS209によって、ROMファームウェアは、例えば、図2Bに示すテーブルを作成する。
図2Bに示すメモリ情報テーブルは、ROMファームウェアがダンプ運用モード時に、0x000000C000000000から始まる512MBの連続領域だけがブートファームウェア、OSカーネル、及びOSカーネルによって使用可能な領域として定義した場合の例である。
同図に示すメモリ情報テーブルでは、例えば、最初の128MBの領域をブートファームウェアが使用し、次の358MBの領域をOSローダ及びOSカーネルが使用する。
また、ステップS208において、CPU2が、システム運用モードであると判断した場合には、処理をステップS210に移行し、ステップS205の処理で取得した実装メモリ情報からシステム運用で使用するメモリ情報テーブル、すなわち、第1のメインメモリ領域を定義したメモリ情報テーブルを作成し、ブートファームウェアにシステムメモリテーブルとして渡す。
したがって、以降に説明する処理(図2Aから図4に示す処理)において、システム運用モードで動作している場合には、第1のメインメモリ領域に対する処理となる(例えば、ステップS213のブートファームウェアを展開する領域や、図3のステップS305のOSローダを展開する領域、図4のステップS401のOSカーネルを展開する領域など)。
ステップS210によって、ROMファームウェアは、例えば、図2C又は図2Dに示すテーブルを作成する。
図2Cに示すメモリ情報テーブルは、4つの256GBごとの空間の先頭に4GBの連続領域があり、アドレス0x00000000F8000000からの128MBの領域をブートファームウェアが使用し、その他の領域をブートファームウェア、OSローダ、及びOSカーネルが使用する場合のテーブルを示している。
すなわち、ROMファームウェアが、システム運用モード時には、メインメモリ5全てを第1のメインメモリ領域として定義した場合の例である(したがって、この場合には、ダンプ運用モード時のみ、第1のメインメモリ領域と第2のメインメモリ領域とを定義することになる)。
また、図2Dに示すメモリ情報テーブルは、4つの256GBごとの空間の先頭に4GBの連続領域があり、0x00000000F8000000から128MBをブートファームウェアが使用し、0x000000C000000000から始まる連続領域は最後の512MBが隠されており、OSカーネル等からは、連続領域としては4GB−512MBしかアクセスできない場合のテーブルを示している。
すなわち、ROMファームウェアが、0x000000C000000000から始まる連続領域は最後の512MBを第2のメインメモリ領域と定義し、それ以外の領域を第1のメインメモリ領域として定義した場合の例である。したがって、システム運用モード時においては、ブートファームウェア、OSローダ、及びOSカーネルからは、上記第1のメインメモリ領域のみアクセス可能な状態である。
メモリ情報テーブルの作成が完了すると、CPU2は、処理をステップS211に移行し、ブートファームウェアに渡すシステムメモリテーブルに設定されているメモリ領域について、メモリの初期化処理及び診断処理を実行する。
例えば、メモリ初期化処理は、メモリのデータに所定のパターン(例えば、オール0)を書き込むことによって行なわれる。また、メモリ診断処理は、所定のパターンについて書き込み読出しを行い、書き込んだパターンと読み出したパターンとの比較を行ない一致するかで異常を判断することによって行なうことができる。
また、本実施例においては、システムメモリテーブルに設定されている使用可能なメモリ領域の全領域をメモリ診断の対象としている。すなわち、システム運用モードの場合には、システム運用時に使用するメモリ領域の全領域をメモリ診断の対象とし、同様に、ダンプ運用モードの場合には、ダンプ運用時に使用するメモリ領域の全領域をメモリ診断の対象としている。
ステップS211において、メモリの初期化処理及び診断処理が完了すると、CPU2は、処理をステップS212に移行し、システムメモリテーブルで管理するメモリ領域からブートファームウェアを格納するメモリのアドレスを決定する。
例えば、システムメモリテーブルで定義されているメモリ領域のブートファームウェアを格納する開始アドレス(当該メモリ領域からのオフセットアドレス)を、ROM3のROMファームウェア環境変数格納領域の所定のアドレスから読み出す。
ブートファームウェアを格納するメモリのアドレスが決定すると、CPU2は、処理をステップS213に移行し、ROM3内の所定のアドレスに格納されているブートファームウェアを読出して、当該アドレスに読み出したブートファームウェアを展開する。
ステップS213において、ブートファームウェアのメインメモリ5への展開処理が完了すると、CPU2は、処理をステップS214に移行し、システムメモリテーブルへのポインタとROMファームウェア運用モード指定フラグの値(設定値)をパラメータとしてブートファームウェアに制御を渡すこととなる。
ここで、システムメモリテーブルへのポインタとROMファームウェア運用モード指定フラグの値をパラメータとしてブートファームウェアに制御を渡す処理は、例えば、ブートファームウェアがアクセス可能なメモリ領域の所定のアドレスに、システムメモリテーブルへのポインタとROMファームウェア運用モード指定フラグとを格納し、さらに、ブートファームウェアが展開されているメインメモリ5の命令開始アドレスを読み出してPC(Program Counter)にセットすればよい。
以上に説明した処理によって、メインメモリ5上にブートファームウェアが展開され、以後はブートファームウェアの命令に従ってCPU2が動作することとなる。
図3は、本発明の実施例に係るブートファームウェアの処理を示すフローチャートである。
図2Aに示したステップS214において、CPU2の制御が、ROMファームウェアからブートファームウェアに移行すると、CPU2は、ステップS301に処理を移行し、ROMファームウェアからシステムメモリテーブルへのポインタとROMファームウェア運用モード指定フラグの値をパラメータとして取得する。
ここで、例えば、図2Aに示したステップS214において、ROMファームウェアによって、ブートファームウェアがアクセス可能なメモリ領域の所定のアドレスに、システムメモリテーブルへのポインタとROMファームウェア運用モード指定フラグとを格納した場合には、当該所定のアドレスをCPU2が参照することによって、ROMファームウェアが設定したシステムメモリテーブルへのポインタとROMファームウェア運用モード指定フラグとをパラメータとして取得することが可能である。
システムメモリテーブルのポインタとROMファームウェア運用モード指定フラグを取得すると、CPU2は、ステップS302に処理を移行し、取得したシステムメモリテーブルのポインタとROMファームウェア運用モード指定フラグを、不揮発性メモリ4のブートファームウェア環境変数を格納する領域におけるシステムメモリテーブルのポインタを格納する領域とブートファームウェア運用モード指定フラグを格納する領域に格納する。
そして、ステップS303において、パラメータとして受け取ったシステムメモリテーブルからブートファームウェアのメモリを管理するためのメモリ管理テーブルを作成する。
ブートファームウェアのメモリ管理テーブルが作成されると、CPU2は、制御をステップS304に移行し、ブートファームウェア用ドライバ(例えば、OSローダやOSカーネルが格納されている外部記録装置6にアクセスするためのドライバ(SCSIドライバなど)やネットワーク装置を動作させてネットワーク通信を可能にするためのドライバなど)のローディング及処理び初期化処理を行なう。
そして、外部記録装置6からOSローダを読出してメインメモリ5に展開し(ステップS306)、CPU2の制御をブートファームウェアからOSローダに渡すこととなる(ステップS306)。
この場合も、図2AのステップSS214の処理と同様に、OSローダが展開されているメインメモリ5の命令開始アドレスを読み出してPCにセットすればよい。
以上に説明した処理によって、メインメモリ5上にOSローダが展開され、以後は、OSローダの命令に従ってCPU2が動作することとなる。
図4は、本発明の実施例に係るOSローダ及びOSの処理を示すフローチャートである。
図3に示したステップS306において、CPU2の制御が、ブートファームウェアからOSローダに移行すると、CPU2は、ステップS401に処理を移行し、外部記録装置6からOSカーネルデータを読み出して、メインメモリ5に展開(格納)する。
OSカーネルデータをメインメモリ5に展開する処理が完了すると、CPU2は、処理をステップS402に移行し、メインメモリ5に展開したOSカーネルデータを実行可能な形式に配置し、OSカーネルに制御を移行する(例えば、CPU2がOSカーネルの命令の先頭アドレスから実行される)こととなる。
CPU2の制御がOSカーネルに移行すると、処理をステップS403に移行し、OSカーネルの初期化処理が行なわれる。
OSカーネルの初期化処理が完了すると、CPU2は、ブートファームウェアのサービスルーチンを呼び出し、不揮発性メモリ4のブートファームウェア環境変数が格納されている領域の所定のアドレスからブートファームウェア運用モード指定フラグを取得する(ステップS404)。
ここで、ブートファームウェアのサービスルーチンとは、ブートファームウェアとOSカーネルとのインターフェースであって、ブートファームウェアの機能をOSカーネルから利用可能とするプログラムのことである。
ステップS405において、ブートファームウェア運用モード指定フラグがダンプ運用モードでない場合には、処理をステップS406に移行し、システム運用モードとして通常の運用処理を行なう。
また、ステップS405において、ブートファームウェア運用モード指定フラグがダンプ運用モードである場合には、処理をステップS407に移行し、ブートファームウェアのサービスルーチンを呼び出して、ダンプ対象のメインメモリ領域の物理アドレス情報を取得する。
そして、ステップS408に処理を移行し、メインメモリ領域1のメモリダンプ処理を実行する。
さらに、ステップS409において、ブートファームウェアのサービスルーチンを呼び出し、不揮発性メモリ4に格納されているファームウェア運用モード指定フラグをシステム運用モードに設定する。
以上のメモリダンプ処理が完了すると、CPU2は、処理をステップS410に移行し、再起動処理を呼び出し、システム運用モードにてシステムを再起動する。
図5は、図4のステップS407に示した第2のメインメモリ領域で動作しているOSカーネルのダンププログラムが第1のメインメモリ領域のダンプ対象領域を決定する処理の具体例を示す図である。
同図には、図1に示したメインメモリ5に配される第1のメインメモリ領域と第2のメインメモリ領域とを示している。また、OSは、ダンプ運用モードで起動しているので、第1のメインメモリ領域へのアクセスは原則として不可能な状態であり、第2のメインメモリ領域のみアクセス可能な状態となっている。したがって、OSは、ダンププログラムが起動するブートファームウェアのサービスルーチン又はROMファームウェアのサービスルーチンによってのみ第1のメインメモリ領域の物理アドレスにアクセスが可能となっている。
また、同図に示す第2のメインメモリ領域には、OSカーネルが、カーネルコア領域7aとカーネル物理メモリ不連続領域7bとカーネル動的割り当て領域7cとに展開されており、CPU2は、この第2のメインメモリ領域に展開されているOSカーネルの命令に従って動作している。
同図に示す第1のメインメモリ領域にも、OSカーネルが、カーネル領域9aとカーネル物理メモリ不連続領域9bとカーネル動的割り当て領域9Cとに展開されているが、これらの領域に展開されているOSカーネルは、第2のメインメモリ領域に展開されているOSカーネルが起動(再起動)される前に展開されたものである。
以下、第2のメインメモリ領域に展開されているOSカーネルのダンププログラムによって、第1のメインメモリ領域に展開されている所望のダンプ対象領域を決定する処理について説明する。
(1)カーネルのコア領域9aなど、物理アドレスが連続な領域に割り当てられるテキスト領域やデータ領域(以下、単に静的テキスト領域、静的データ領域という)をダンプ処理の対象とする場合、まず、カーネル内の静的データ8の論理アドレスと静的データ10の論理アドレスは、同一カーネルならば同一であるので、OSカーネルから、ブートファームウェアのサービスルーチンを呼び出し、第1のメインメモリ領域でのカーネルコア領域9aのベースアドレス(カーネルコア領域9aの先頭アドレス)を取得する。
そして、第2のメインメモリ領域のカーネルコア領域7aの先頭アドレスから第1のメインメモリ領域のカーネルコアの先頭アドレスを引いた値(オフセット15)を算出する。
さらに、第2のメインメモリ領域のカーネル内の静的データ8の論理アドレスをアドレス変換テーブル(システムメモリテーブル)に基づいて物理アドレスに変換し、オフセット15を引くことによって、第2のメインメモリ領域の静的データ8と対応する第1のメインメモリ領域の静的データ10の物理アドレスが得られる。また、静的テキスト領域についても同様の処理によって、第2のメインメモリ領域の静的テキスト領域に基づいて、ダンプ採取対象である第1のメインメモリ領域内の静的テキスト領域の物理アドレス(例えば、ダンプ対象領域12の物理アドレス)を得ることができる。
また、さらに通常はこのオフセット15は第2のメインメモリ領域の先頭アドレスから第1のメインメモリ領域の先頭アドレスをひいたものに等しいため、カーネルコア領域7a内の静的データ領域や静的テキスト領域であれば、第1のメインメモリ領域及び第2のメインメモリ領域のベースアドレスの情報と、ダンプ運用モードで動作している第2のメインメモリ領域内のアドレス変換テーブル(システムメモリテーブル)から容易にダンプ対象領域である第1のメインメモリ領域あるカーネルコア9aの静的データ領域又はテキスト領域のアドレスが得ることが可能である。
(2)物理アドレスが不連続な領域に割り当てられる領域のために、上記(1)で説明したオフセット15に基づく計算では、第2のメインメモリ領域情報に基づいて第1のメインメモリ領域内のダンプ対象領域(例えば、ダンプ対象領域13、ダンプ対象領域14)の物理アドレスが算出できない場合や、静的データ領域ではなく、論理アドレス自体が動的に割り当てられるために第2のメインメモリ領域で動作しているときとは異なった論理アドレスに配置されるようなカーネル内のデータ領域に対してダンプ処理を行なう場合には、第1のメインメモリ領域のカーネル内にあるシステムメモリテーブル(アドレス変換テーブル)11のデータを参照し、対応する物理アドレスを計算すればよい。
ここで、第1のメインメモリ領域内のカーネルコア領域9aにあるシステムメモリテーブル11のある場所の物理アドレスは上記(1)の処理で得ることができる。
ここで、カーネルコア領域7a及び9aは、カーネルテキスト(静的テキスト領域)、カーネルデータ(静的データ領域)の基本的な部分で、カーネル内の各種制御データへリンクするもととなるデータが定義されており、物理アドレスが連続した領域に割り当てられているものとする。
以上の図2Aから図5に基づいて説明した処理は、情報処理装置1に電源投入又は、OSパニックによる再起動を要因としてOSが起動するまでの処理であるが、図6では、OSが異常を検出してから再起動処理が行なわれるまでの処理を説明する。
図6は、OSが異常を検出してから再起動処理が行なわれるまでの処理の例を示すフローチャートである。
情報処理装置1(OS)がシステム運用モードで動作している状態において、メモリ破壊等のシステム運用を継続するには致命的なハードウェア故障が発生すると、ハードウェアからの割り込み信号や、OSカーネルからのエラー通知によって、OSは異常を検出する(ステップS601)。
OSが異常を検出すると、CPU2は、制御をステップS602に移行し、ダンプ処理エントリを行なう。例えば、ハードウェアからの割り込み信号に応じて、割り込みハンドラが起動されると、CPU2に備わるPCにダンププログラムの命令開始アドレスが設定され、ダンプ処理エントリプログラムの命令に従ってCPU2が動作することとなる。
なお、複数のプログラム(プロセス、タスク、アプリケーション)が同時に動作するOSの場合には、ダンプ処理エントリプログラム以外のプログラムも当然に動作している。
そして、処理をステップS603に移行して、ダンプ処理エントリプログラムからブートファームウェアのサービスルーチンを呼び出し、不揮発性メモリ4内に確保されているROMファームウェア環境変数領域の所定のアドレスに格納されているROMファームウェア運用モード指定フラグ、又はROMファームウェア運用モード指定フラグ及びファームウェア環境変数領域の所定のアドレスに格納されているファームウェア運用モード指定フラグをダンプ運用モードに設定する。
ダンプ運用モードに設定する処理が完了すると、CPU2は、制御をステップS604に移行し、再起動処理を呼び出して再起動を開始する。すなわち、図2Aに示したステップS201に処理が移行し、再起動処理(リセット処理)が開始されることとなる。
また、同図では、ステップS603の処理において、ファームウェアのサービスルーチンによって、ダンプ運用モードを設定する処理を行なったが、OSから直接ROMファームウェアにアクセスするインターフェース(手段)を用意することによって、ROMファームウェア運用モード指定フラグ、又はROMファームウェア運用モード指定フラグ及びファームウェア運用モード指定フラグにダンプ運用モードを設定してもよい。
図7に、OSが異常を検出してから再起動処理が行なわれるまでの処理の変形例を示す。
図6と同様に、情報処理装置1(OS)がシステム運用モードで動作している状態において、メモリ破壊等のシステム運用を継続するには致命的なハードウェア故障が発生すると、ハードウェアからの割り込み信号や、OSカーネルからのエラー通知によって、OSは異常を検出する(ステップS701)。
OSが異常を検出すると、CPU2は、制御をステップS702に移行し、ダンプ処理エントリを行なう(ダンプ処理エントリプログラムを起動する)。
そして、処理をステップS703に移行して、ダンプ処理エントリプログラムからROMファームウェアのサービスルーチンを呼び出し、不揮発性メモリ4内に確保されているROMファームウェア運用モード指定フラグ又はファームウェア運用モード指定フラグに一方又は全てに対して、ダンプ運用モードを設定する。
ダンプ運用モードを設定すると、CPU2は、制御をステップS704に移行し、再起動処理を呼び出して再起動を開始する。すなわち、図2Aに示したステップS201に処理を移行し、再起動処理が開始されることとなる。
また、図1において図示しない電源制御手段(例えば、電源制御又は監視を行なうシステム監視機構)が、システム起動時に、ROMファームウェア運用モード指定フラグ及びファームウェア運用モード指定フラグをダンプ運用モードに設定するようにしてもよい。
図8は、電源制御手段にダンプ運用モード/システム運用モードの切替手段を持たせた場合に、OSが異常を検出してから再起動処理が行なわれるまでの処理の例を示している。
図6と同様に、情報処理装置1(OS)がシステム運用モードで動作している状態において、メモリ破壊等のシステム運用を継続するには致命的なハードウェア故障が発生すると、ハードウェアからの割り込み信号や、OSカーネルからのエラー通知によって、OSは異常を検出する(ステップS801)。
OSが異常を検出すると、CPU2は、制御をステップS802に移行し、ダンプ処理エントリを行なう(ダンプ処理エントリプログラムを起動する)。
そして、処理をステップS803に移行して、ダンプ処理エントリプログラムから、電源制御を行なうシステム監視機構に次回のシステム起動時(図2Aから図4に示した処理)にROMファームウェア運用モード指定フラグ、又はROMファームウェア運用モード指定フラグ及びファームウェア運用モード指定フラグをダンプ運用モードとするように通知する。
例えば、不揮発性メモリ4内にシステム監視機構の機能を備えるプログラムが参照するメモリ領域を予め確保し、このメモリ領域の所定のアドレスにシステム監視機構運用モード指定フラグを格納するようにする(例えば、1バイトデータで0xFFであればダンプ運用モードとし、0xFF以外をシステム運用モードとする)。
そして、図6にも示したように、OSがブートファームウェアのサービスルーチンを呼び出して、システム監視機構運用モード指定フラグにダンプ運用モードを設定するようにする。
一方、システム監視機構は、システム起動時(例えば、図2Aに示したステップS201)において、システム監視機構運用モード指定フラグを参照し、ダンプ運用モードに設定されている場合には、ROMファームウェア運用モード指定フラグ、又はROMファームウェア運用モード指定フラグ及びファームウェア運用モード指定フラグをダンプ運用モードに設定すればよい。
システム監視機構にダンプ運用モードを通知すると、CPU2は、制御をステップS804に移行し、再起動処理を呼び出して再起動を開始する。すなわち、図2Aに示したステップS201に処理を移行し、再起動処理が開始されることとなる。
また、システム監視機構によって、例えば、ROMファームウェア運用モード指定フラグ、又はROMファームウェア運用モード指定フラグ及びブートファームウェア運用モード指定フラグを、強制的にダンプ運用モードに設定して再起動を実行させるようにしてもよい。
これにより、OSがハングアップし、ダンプ処理エントリに制御が移行できなくなっても、ダンプ運用モードで再起動ができるようになるのでダンプ採取を行なうことが可能となる。
以上の説明においては、第1のメインメモリ領域と第2のメインメモリ領域とは、システム運用モード時及びダンプ運用モード時の両モード時においても分割されているが、これに限定するものではない。すなわち、システム運用モード時においては、メインメモリ5の全ての領域を図1に示した第1のメインメモリ領域として使用し、ダンプ運用モード時にのみ第1のメインメモリ領域と第2のメインメモリ領域とに分割してもよい。この場合、第1のメインメモリ領域で使用頻度が少ない領域や障害解析に不要な領域等を第2のメインメモリ領域として割り当てればよい。
以上に説明したダンプ処理によって採取したデータを障害解析する場合には、障害解析に必要な領域の決定のためにカーネル固有のテーブル(例えば、データの配置の定義したテーブル)を参照する必要があるが、ダンプ運用モードで動作しているカーネルは、システム運用モードで動作しているカーネルと同一のものであるため同一のテーブルを使用して所定のデータが配置されているアドレス等の情報を取得することが可能であり、容易に障害解析することが可能となる。
また、システムダンプ採取プログラムがシステム運用モード時と同一のカーネル(オペレーティングシステム)で動作するため、ダンプ採取領域を決定するためにメインメモリ上の領域を管理するテーブル情報(例えば、メモリ管理テーブルなど)からシステムダンプを取得すべき領域のリストを予め作成しておく必要がなく、カーネルの版数と領域リストの版数(又は、領域リストを作成するためのテーブル情報の版数)を管理する必要がなくなる。
したがって、カーネルの版数と領域リストの版数(又は、領域リストを作成するためのテーブル情報の版数)との不一致によって、誤った領域をダンプしてしまったり、メモリの未実装領域にアクセスしてしまいシステムダンプの採取が異常終了してしまうことを回避することが可能となる。また、余計な版数管理を行う必要がなくなる。
さらに、システムダンプ時にカーネルに組み込まれたダンプ採取プログラムが動作するので、障害発生時のメモリデータから障害解析に必要な最適な領域をダンプ採取することが可能となる。
そして、ダンプを採取するために、一度リセットを実施するので、安定したオペレーティングシステム上でダンプ採取することができ、また、単に所定の領域をダンプ採取するだけでなく、障害解析プログラムなどによりカーネル内データを解析して、障害の原因や被疑箇所の特定を障害発生時にある程度行うことも可能となる。また、そのときの解析結果に応じて、さらにダンプ採取領域を広げるなどの対応も可能となる。
また、ダンプ運用モード時には、オペレーティングシステムをブートするブートファームウェアも含めて、システム運用モード時とは別の物理メモリ空間でオペレーティングシステムを起動するので、オペレーティングシステムとブートファームウェア間のインターフェース部分で異常が発生してハングアップした場合などでもダンプ採取時に異常が発生した時のブートファームウェア領域のデータも壊さずにダンプすることが可能となる。
ダンプ対象であるシステム運用モード時に使用したメモリ領域のデータを上書きすることがないのでブートファームウェア側でメモリデータを一時待避する必要がなく、メモリデータを一時待避するための専用のハードウェア資源を持つ必要がないので、信頼性を高めながらコストを抑えることが可能となる。そのため、メモリデータの一時待避用に専用パーティションを確保しておく必要もないためディスクのパーティション管理も容易となる。
さらに、障害が発生した環境(カーネルの制御データの不整合やメモリ破壊など)とは無関係にダンプ採取を行なうことが可能となる。
また、一時的なハード異常が発生していた場合には、一旦リセットすることにより、正常に動作できる可能性を高めることが可能となり、恒常的なハード異常が発生していた場合でも、リセットによるシステムの再起動時に実行されるPOST診断やハードウェアの初期化処理で異常を検出できる可能性を高めることが可能となる。
(付記1) 情報処理装置の動作を制御する運用モード指定情報に応じて、前記情報処理装置が備える記憶手段の領域をオペレーティングシステムに使用していた第1の領域以外の第2の領域に画する第2の領域定義情報を記憶した領域定義情報手段から、該第2の領域定義情報を取得する領域定義情報取得処理と、
該第2の領域定義情報に基づく領域にオペレーティングシステムを格納するオペレーティングシステム格納処理と、
前記第2の領域定義情報に基づく領域における所定の領域に対応する前記第1の領域における所定の領域をダンプ対象領域として算出するダンプ対象領域算出処理と、
該ダンプ対象領域に格納されている情報を読み出して出力するダンプ処理と、
を備えるパニックダンプ採取処理をコンピュータに実行させるためのプログラム。
(付記2) 情報処理装置が動作するために必要な構成要素に障害が発生したことを検出して通知する障害通知処理と、
該障害通知処理による通知に応じて、前記運用モード指定情報を運用モード指定情報記憶手段に記憶する運用モード指定情報記憶処理と、
前記障害発生時に使用されていた領域の状態を保持したまま、前記情報処理装置を再起動する再起動処理と、
を更に前記領域定義情報取得処理の前に備える付記1に記載のパニックダンプ採取処理をコンピュータに実行させるためのプログラム。
(付記3) 前記ダンプ対象領域算出処理は、前記ダンプ対象領域を、前記第1の領域の先頭位置と前記第2の領域の先頭位置とのオフセットと、前記第2の領域における所定の領域と、の差によって算出する処理であることを特徴とする付記1又は2に記載のパニックダンプ採取を行なうためのプログラム。
(付記4) 前記ダンプ対象領域算出処理は、前記ダンプ対象領域を、前記第1の領域の先頭位置と前記第2の領域の先頭位置とのオフセットと、前記第2の領域における所定の領域と、の差によって算出する情報と、前記第1の領域を管理するための情報とに基づいて取得する処理であることを特徴とする付記1から3のいずれか一項に記載のパニックダンプ採取を行なうためのプログラム。
(付記5) 情報処理装置の動作を制御する運用モード指定情報に応じて、前記情報処理装置が備える記憶手段の領域を、オペレーティングシステムに使用していた第1の領域以外の第2の領域に画する第2の領域定義情報を記憶した領域定義情報手段から、該第2の領域定義情報を取得する領域定義情報取得処理と、
該第2の領域定義情報に基づく領域にオペレーティングシステムを格納するオペレーティングシステム格納処理と、
前記第2の領域定義情報に基づく領域における所定の領域に対応する前記第1の領域における所定の領域をダンプ対象領域として算出するダンプ対象領域算出処理と、
該ダンプ対象領域に格納されている情報を読み出して出力するダンプ処理と、
を行なうパニックダンプ採取方法。
(付記6) 情報処理装置が動作するために必要な構成要素に障害が発生したことを検出して通知する障害通知処理と、
該障害通知処理による通知に応じて、前記運用モード指定情報を運用モード指定情報記憶手段に記憶する運用モード指定情報記憶処理と、
前記障害発生時に使用されていた領域の状態を保持したまま、前記情報処理装置を再起動する再起動処理と、
を更に前記領域定義情報取得処理の前に備える付記5に記載のパニックダンプ採取方法。
(付記7) 前記ダンプ対象領域算出処理は、前記ダンプ対象領域を、前記第1の領域の先頭位置と前記第2の領域の先頭位置とのオフセットと、前記第2の領域における所定の領域と、の差によって算出する処理であることを特徴とする付記5又は6に記載のパニックダンプ採取方法。
(付記8) 前記ダンプ対象領域算出処理は、前記ダンプ対象領域を、前記第1の領域の先頭位置と前記第2の領域の先頭位置とのオフセットと、前記第2の領域における所定の領域と、の差によって算出する情報と、前記第1の領域を管理するための情報とに基づいて取得する処理であることを特徴とする付記5から7のいずれか一項に記載のパニックダンプ採取方法。
(付記9) 情報処理装置の動作を制御する運用モード指定情報に応じて、前記情報処理装置が備える記憶手段の領域をオペレーティングシステムに使用していた第1の領域以外の第2の領域に画する第2の領域定義情報を記憶した領域定義情報手段から、該第2の領域定義情報を取得する領域定義情報取得手段と、
該第2の領域定義情報に基づく領域にオペレーティングシステムを格納するオペレーティングシステム格納手段と、
前記第2の領域定義情報に基づく領域における所定の領域に対応する前記第1の領域における所定の領域をダンプ対象領域として算出するダンプ対象領域算出手段と、
該ダンプ対象領域に格納されている情報を読み出して出力するダンプ手段と、
を備えるパニックダンプ採取機構。
(付記10) 情報処理装置が動作するために必要な構成要素に障害が発生したことを検出して通知する障害通知手段と、
該障害通知手段による通知に応じて、前記運用モード指定情報を記憶する運用モード指定情報記憶手段と、
前記障害発生時に使用されていた領域の状態を保持したまま、前記情報処理装置を再起動する再起動手段と、
を更に備える付記9に記載のパニックダンプ採取機構。
(付記11) 前記ダンプ対象領域算出手段は、前記ダンプ対象領域を、前記第1の領域の先頭位置と前記第2の領域の先頭位置とのオフセットと、前記第2の領域における所定の領域と、の差によって算出する処理であることを特徴とする付記9又は10に記載のパニックダンプ採取機構。
(付記12) 前記ダンプ対象領域算出手段は、前記ダンプ対象領域を、前記第1の領域の先頭位置と前記第2の領域の先頭位置とのオフセットと、前記第2の領域における所定の領域と、の差によって算出する情報と、前記第1の領域を管理するための情報とに基づいて取得する処理であることを特徴とする付記9から11のいずれか一項に記載のパニックダンプ採取機構。
本発明の実施例に係る構成の主要部の例を示す図である。 本発明の実施例に係るROMファームウェアの処理を示すフローチャートである。 ROMファームウェアが作成するシステム運用モード時のメモリ情報テーブルの例を示す図である。 ROMファームウェアが作成するシステム運用モード時のメモリ情報テーブルの例を示す図である。 ROMファームウェアが作成するダンプ運用モード時のメモリ情報テーブルの例を示す図である。 本発明の実施例に係るブートファームウェアの処理を示すフローチャートである。 本発明の実施例に係るOSローダ及びOSの処理を示すフローチャートである。 図5に示したステップS407からステップS409の処理の具体例を示す図である。 OSが異常を検出してから再起動処理が行なわれるまでの処理を示すフローチャートである。 OSが異常を検出してから再起動処理が行なわれるまでの処理の変形例を示すフローチャートである。。 電源制御手段にダンプ運用モード/システム運用モードの切替手段を持たせた場合に、OSが異常を検出してから再起動処理が行なわれるまでの処理の例を示している。
符号の説明
1 情報処理装置
2 CPU
3 ROM
4 不揮発性メモリ
5 メインメモリ
6 外部記録装置
7a カーネルコア領域
7b カーネル物理メモリ不連続領域
7c カーネル動的割り当て領域
8 静的データ
9a カーネルコア領域
9b カーネル物理メモリ不連続領域
9c カーネル動的割当て領域
10 静的データ
11 アドレス情報
12 ダンプ対象領域A
13 ダンプ対象領域B
14 ダンプ対象領域C
15 オフセット

Claims (6)

  1. 情報処理装置の運用モードを指定する運用モード指定情報がダンプ運用モードを示している場合、
    前記情報処理装置が備える記憶手段の領域を定義する領域定義情報を記憶する領域定義情報記憶手段から、前記記憶手段の領域のうち、障害発生時にオペレーティングシステムが展開されていた領域である第1の領域以外の、ダンプ運用モードで使用する第2の領域を定義する第2の領域定義情報を取得する領域定義情報取得処理と、
    該第2の領域定義情報が定義する第2の領域にオペレーティングシステムを格納するオペレーティングシステム格納処理と、
    前記第2の領域に格納されたオペレーティングシステムを起動する起動処理と、
    前記起動したオペレーティングシステムが前記運用モード指定情報を参照し、前記運用モード指定情報がダンプ運用モードを示している場合には、前記第2の領域の物理アドレス、前記第2の領域に含まれる所定領域の物理アドレス、及び前記第1の領域の物理アドレスに基づいてダンプ対象領域の物理アドレスを求め、前記第2の領域定義情報が定義する第2の領域内の所定の領域が保持する情報に対応する情報を保持する、前記第1の領域内の領域をダンプ対象領域として決定するダンプ対象領域算出処理と、
    該ダンプ対象領域に格納されている情報を読み出して出力するダンプ処理と、
    を備えるパニックダンプ採取処理をコンピュータに実行させるためのプログラム。
  2. 情報処理装置が動作するために必要な構成要素に障害が発生したことを検出して通知する障害通知処理と、
    該障害通知処理による通知に応じて、前記情報処理装置の運用モードを指定する運用モード指定情報を運用モード指定情報記憶手段に記憶する運用モード指定情報記憶処理と、
    前記障害発生時に使用されていた領域の状態を保持したまま、前記情報処理装置を再起動する再起動処理と、
    前記運用モード指定情報がダンプ運用モードを示している場合、
    前記情報処理装置が備える記憶手段の領域を定義する領域定義情報を記憶する領域定義情報記憶手段から、前記記憶手段の領域のうち、障害発生時にオペレーティングシステムが展開されていた領域である第1の領域以外の、ダンプ運用モードで使用する第2の領域を定義する第2の領域定義情報を取得する領域定義情報取得処理と、
    該第2の領域定義情報が定義する第2の領域にオペレーティングシステムを格納するオペレーティングシステム格納処理と、
    前記第2の領域に格納されたオペレーティングシステムを起動する起動処理と、
    前記起動したオペレーティングシステムが前記運用モード指定情報を参照し、前記運用モード指定情報がダンプ運用モードを示している場合には、前記第2の領域の物理アドレス、前記第2の領域に含まれる所定領域の物理アドレス、及び前記第1の領域の物理アドレスに基づいてダンプ対象領域の物理アドレスを求め、前記第2の領域定義情報が定義する第2の領域内の所定の領域が保持する情報に対応する情報を保持する、前記第1の領域内の領域をダンプ対象領域として決定するダンプ対象領域算出処理と、
    該ダンプ対象領域に格納されている情報を読み出して出力するダンプ処理と、
    を備えるパニックダンプ採取処理をコンピュータに実行させるためのプログラム。
  3. 前記ダンプ対象領域算出処理は、前記ダンプ対象領域を、前記第1の領域の先頭位置と前記第2の領域の先頭位置とのオフセットと、前記第2の領域における所定の領域と、の差によって算出する処理であることを特徴とする請求項1又は2に記載のパニックダンプ採取を行なうためのプログラム。
  4. 情報処理装置の運用モードを指定する運用モード指定情報がダンプ運用モードを示している場合、
    前記情報処理装置が備える記憶手段の領域を定義する領域定義情報を記憶する領域定義情報記憶手段から、前記記憶手段の領域のうち、障害発生時にオペレーティングシステムが展開されていた領域である第1の領域以外の、ダンプ運用モードで使用する第2の領域を定義する第2の領域定義情報を取得する領域定義情報取得処理と、
    該第2の領域定義情報が定義する第2の領域にオペレーティングシステムを格納するオペレーティングシステム格納処理と、
    前記第2の領域に格納されたオペレーティングシステムを起動する起動処理と、
    前記起動したオペレーティングシステムが前記運用モード指定情報を参照し、前記運用モード指定情報がダンプ運用モードを示している場合には、前記第2の領域の物理アドレス、前記第2の領域に含まれる所定領域の物理アドレス、及び前記第1の領域の物理アドレスに基づいてダンプ対象領域の物理アドレスを求め、前記第2の領域定義情報が定義する第2の領域内の所定の領域が保持する情報に対応する情報を保持する、前記第1の領域内の領域をダンプ対象領域として決定するダンプ対象領域算出処理と、
    該ダンプ対象領域に格納されている情報を読み出して出力するダンプ処理と、
    を行なうパニックダンプ採取方法。
  5. 情報処理装置の運用モードを指定する運用モード指定情報がダンプ運用モードを示している場合、
    前記情報処理装置が備える記憶手段の領域を定義する領域定義情報を記憶する領域定義情報記憶手段から、前記記憶手段の領域のうち、障害発生時にオペレーティングシステムが展開されていた領域である第1の領域以外の、ダンプ運用モードで使用する第2の領域を定義する第2の領域定義情報を取得する領域定義情報取得手段と、
    該第2の領域定義情報が定義する第2の領域にオペレーティングシステムを格納するオペレーティングシステム格納手段と、
    前記第2の領域に格納されたオペレーティングシステムを起動する起動処理と、
    前記起動したオペレーティングシステムが前記運用モード指定情報を参照し、前記運用モード指定情報がダンプ運用モードを示している場合には、前記第2の領域の物理アドレス、前記第2の領域に含まれる所定領域の物理アドレス、及び前記第1の領域の物理アドレスに基づいてダンプ対象領域の物理アドレスを求め、前記第2の領域定義情報が定義する第2の領域内の所定の領域が保持する情報に対応する情報を保持する、前記第1の領域内の領域をダンプ対象領域として決定するダンプ対象領域算出手段と、
    該ダンプ対象領域に格納されている情報を読み出して出力するダンプ手段と、
    を備えるパニックダンプ採取機構。
  6. 前記ダンプ対象領域算出処理では、
    前記起動したオペレーティングシステムによって、前記第2の領域の物理アドレスと、前記第2の領域に含まれる所定の領域の物理アドレスと、前記第1の領域の物理アドレスに基づいて、前記第1の領域に含まれる所定の領域の物理アドレスを算出することを特徴とする請求項1に記載のプログラム。
JP2004258750A 2004-09-06 2004-09-06 パニックダンプ採取のためのプログラム、方法、及び機構 Expired - Fee Related JP4677214B2 (ja)

Priority Applications (3)

Application Number Priority Date Filing Date Title
JP2004258750A JP4677214B2 (ja) 2004-09-06 2004-09-06 パニックダンプ採取のためのプログラム、方法、及び機構
US11/023,184 US7631224B2 (en) 2004-09-06 2004-12-28 Program, method, and mechanism for taking panic dump
EP05250187A EP1638000B1 (en) 2004-09-06 2005-01-14 Method, apparatus and program for performing panic memory dump

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
JP2004258750A JP4677214B2 (ja) 2004-09-06 2004-09-06 パニックダンプ採取のためのプログラム、方法、及び機構

Related Child Applications (1)

Application Number Title Priority Date Filing Date
JP2010277134A Division JP5348120B2 (ja) 2010-12-13 2010-12-13 パニックダンプ採取のためのプログラム、方法、機構

Publications (2)

Publication Number Publication Date
JP2006072931A JP2006072931A (ja) 2006-03-16
JP4677214B2 true JP4677214B2 (ja) 2011-04-27

Family

ID=35501229

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2004258750A Expired - Fee Related JP4677214B2 (ja) 2004-09-06 2004-09-06 パニックダンプ採取のためのプログラム、方法、及び機構

Country Status (3)

Country Link
US (1) US7631224B2 (ja)
EP (1) EP1638000B1 (ja)
JP (1) JP4677214B2 (ja)

Families Citing this family (19)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR20070118138A (ko) * 2005-03-29 2007-12-13 후지쯔 가부시끼가이샤 처리 장치 및 기억 매체
JP4876662B2 (ja) * 2006-03-24 2012-02-15 日本電気株式会社 メモリダンプ機能を備えたコンピュータシステム、プログラム及びメモリダンプの方法
CN101295268B (zh) * 2007-04-27 2011-03-02 国际商业机器公司 面向软件系统的分区存储器转储方法和装置
JP5255348B2 (ja) * 2007-07-16 2013-08-07 ヒューレット−パッカード デベロップメント カンパニー エル.ピー. クラッシュダンプ用のメモリアロケーション
JP2009025967A (ja) * 2007-07-18 2009-02-05 Nec Computertechno Ltd 二重化ファームウェアのバックアップ方式、方法、及び、オペレーティングシステム
US7818616B2 (en) * 2007-07-25 2010-10-19 Cisco Technology, Inc. Warm reboot enabled kernel dumper
KR101658485B1 (ko) * 2009-06-18 2016-09-22 삼성전자주식회사 휴대용 단말기에서 디버깅을 위한 부팅 방법 및 장치
EP2453359B1 (en) * 2009-07-10 2016-04-20 Fujitsu Limited Server having memory dump function and method for acquiring memory dump
EP2463779A1 (en) * 2009-08-04 2012-06-13 Fujitsu Limited Reset method and monitor
US9015430B2 (en) * 2010-03-02 2015-04-21 Symantec Corporation Copy on write storage conservation systems and methods
JP5609242B2 (ja) * 2010-04-28 2014-10-22 富士通株式会社 情報処理装置及びメモリダンプ採取方法
JP5593856B2 (ja) 2010-06-02 2014-09-24 富士通株式会社 情報処理装置およびドライバ実行制御方法
EP2660724B1 (en) 2010-12-27 2020-07-29 Fujitsu Limited Information processing device having memory dump function, memory dump method, and memory dump program
US9218234B2 (en) * 2012-04-27 2015-12-22 Marvell World Trade Ltd. Memory dump and analysis in a computer system
JP6083136B2 (ja) 2012-06-22 2017-02-22 富士通株式会社 メモリダンプ機能を有する情報処理装置、メモリダンプ方法、およびメモリダンププログラム
JP6424134B2 (ja) * 2015-04-23 2018-11-14 株式会社日立製作所 計算機システム及び計算機システムの制御方法
US9727242B2 (en) 2015-06-10 2017-08-08 International Business Machines Corporation Selective memory dump using usertokens
JP2019160253A (ja) * 2018-03-16 2019-09-19 株式会社リコー 情報処理システム、情報処理システムの制御方法、及び情報処理システムの制御プログラム
CN111158772B (zh) * 2019-12-31 2022-01-14 联想(北京)有限公司 一种数据处理方法及电子设备

Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH0895834A (ja) * 1994-09-28 1996-04-12 Toshiba Corp システムダンプ採取方法
JPH10133918A (ja) * 1996-11-01 1998-05-22 Toshiba Corp コンピュータシステム
JPH10333944A (ja) * 1997-05-30 1998-12-18 Nec Software Ltd メモリダンプ採取方式
JP2001125810A (ja) * 1999-10-25 2001-05-11 Nec Corp コンピュータシステムおよびコンピュータシステムにおけるダンプ方法
JP2003208314A (ja) * 2002-01-15 2003-07-25 Mitsubishi Electric Corp オペレーティングシステムの自動入れ替え可能な計算機システムおよびそのシステムを利用したオペレーションシステムの自動入れ替え方法
JP2004102395A (ja) * 2002-09-05 2004-04-02 Hitachi Ltd メモリダンプデータの取得方法および情報処理装置、ならびにそのプログラム

Family Cites Families (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5293612A (en) * 1989-05-11 1994-03-08 Tandem Computers Incorporated Selective dump method and apparatus
JPH07210429A (ja) * 1994-01-11 1995-08-11 Hitachi Ltd ダンプ取得方法および制御装置および情報処理システム
JP3493368B2 (ja) 1995-08-11 2004-02-03 富士通株式会社 通信システム
JPH09160811A (ja) 1995-12-04 1997-06-20 Pfu Ltd ダンプ機構付き情報端末装置
JPH09223046A (ja) * 1996-02-20 1997-08-26 Nec Software Ltd ダンプ収集機能を持つコンピュータシステム
JP4269362B2 (ja) * 1998-09-24 2009-05-27 ヤマハ株式会社 コンピュータシステム
JP2002073378A (ja) * 2000-09-04 2002-03-12 Hitachi Ltd 計算機システムのダンプ取得方法および装置
JP2002149448A (ja) * 2000-11-10 2002-05-24 Mitsubishi Electric Corp メモリダンプ装置
US6898736B2 (en) * 2001-10-31 2005-05-24 International Business Machines Corporation Dynamic sizing logic for dump list generation

Patent Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH0895834A (ja) * 1994-09-28 1996-04-12 Toshiba Corp システムダンプ採取方法
JPH10133918A (ja) * 1996-11-01 1998-05-22 Toshiba Corp コンピュータシステム
JPH10333944A (ja) * 1997-05-30 1998-12-18 Nec Software Ltd メモリダンプ採取方式
JP2001125810A (ja) * 1999-10-25 2001-05-11 Nec Corp コンピュータシステムおよびコンピュータシステムにおけるダンプ方法
JP2003208314A (ja) * 2002-01-15 2003-07-25 Mitsubishi Electric Corp オペレーティングシステムの自動入れ替え可能な計算機システムおよびそのシステムを利用したオペレーションシステムの自動入れ替え方法
JP2004102395A (ja) * 2002-09-05 2004-04-02 Hitachi Ltd メモリダンプデータの取得方法および情報処理装置、ならびにそのプログラム

Also Published As

Publication number Publication date
EP1638000A2 (en) 2006-03-22
EP1638000B1 (en) 2012-06-20
JP2006072931A (ja) 2006-03-16
US20060069944A1 (en) 2006-03-30
EP1638000A3 (en) 2010-03-03
US7631224B2 (en) 2009-12-08

Similar Documents

Publication Publication Date Title
EP1638000B1 (en) Method, apparatus and program for performing panic memory dump
JP3593241B2 (ja) 計算機の再起動方法
EP1110147B1 (en) Boot failure recovery
US6889340B1 (en) Use of extra firmware flash ROM space as a diagnostic drive
US8595552B2 (en) Reset method and monitoring apparatus
JP5509568B2 (ja) コンピュータ装置、プロセッサ診断方法、及びプロセッサ診断制御プログラム
KR102136906B1 (ko) Bpram을 이용한 운영체제의 레이아웃 및 실행
CN104254840A (zh) 在计算机系统中的存储器转储和分析
JP4349837B2 (ja) 情報処理システム
JP2010086181A (ja) 仮想計算機システム及びその管理方法、プログラム並びに記録媒体
US9715267B2 (en) Method for switching operating systems and electronic apparatus
JP2007133544A (ja) 障害情報解析方法及びその実施装置
WO2019156062A1 (ja) 情報処理システム、情報処理装置、情報処理装置のbios更新方法、及び情報処理装置のbios更新プログラム
CN109271206B (zh) 一种异常现场的内存压缩和保存方法
CN108628726B (zh) Cpu状态信息记录方法和装置
JP5293062B2 (ja) コンピュータ装置、メモリ診断方法、及びメモリ診断制御プログラム
JP5348120B2 (ja) パニックダンプ採取のためのプログラム、方法、機構
US20050033952A1 (en) Dynamic scheduling of diagnostic tests to be performed during a system boot process
EP2757477A1 (en) Information processing apparatus and stored information analyzing method
CN114741119A (zh) 系统的启动方法、装置、计算机设备和存储介质
KR101420026B1 (ko) 부팅 프로세스 중에 파일들을 로딩하기 위한 방법, 장치 및 컴퓨터 판독가능 저장 매체
US20230350755A1 (en) Coordinated operating system rollback
JPH09223046A (ja) ダンプ収集機能を持つコンピュータシステム
CN116860546A (zh) 一种日志保存方法、车载设备、存储介质及芯片
JP2017062697A (ja) 情報処理装置、情報処理システム、情報処理方法およびプログラム

Legal Events

Date Code Title Description
A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20070703

A977 Report on retrieval

Free format text: JAPANESE INTERMEDIATE CODE: A971007

Effective date: 20090731

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20100216

RD12 Notification of acceptance of power of sub attorney

Free format text: JAPANESE INTERMEDIATE CODE: A7432

Effective date: 20100325

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20100329

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A821

Effective date: 20100325

A02 Decision of refusal

Free format text: JAPANESE INTERMEDIATE CODE: A02

Effective date: 20100914

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20101213

A911 Transfer to examiner for re-examination before appeal (zenchi)

Free format text: JAPANESE INTERMEDIATE CODE: A911

Effective date: 20101216

TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20110125

A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20110131

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20140204

Year of fee payment: 3

R150 Certificate of patent or registration of utility model

Ref document number: 4677214

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150

Free format text: JAPANESE INTERMEDIATE CODE: R150

LAPS Cancellation because of no payment of annual fees