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

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

Info

Publication number
JP2011054212A
JP2011054212A JP2010277134A JP2010277134A JP2011054212A JP 2011054212 A JP2011054212 A JP 2011054212A JP 2010277134 A JP2010277134 A JP 2010277134A JP 2010277134 A JP2010277134 A JP 2010277134A JP 2011054212 A JP2011054212 A JP 2011054212A
Authority
JP
Japan
Prior art keywords
area
dump
information
operation mode
processing apparatus
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.)
Granted
Application number
JP2010277134A
Other languages
English (en)
Other versions
JP5348120B2 (ja
Inventor
Yukio Oguma
幸雄 小熊
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 JP2010277134A priority Critical patent/JP5348120B2/ja
Publication of JP2011054212A publication Critical patent/JP2011054212A/ja
Application granted granted Critical
Publication of JP5348120B2 publication Critical patent/JP5348120B2/ja
Expired - Fee Related legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Abstract

【課題】障害発生時のパニックダンプによるメモリデータ採取処理を確実に行なうことを可能にする。
【解決手段】ブートファームウェアがオペレーティングシステムに通知するメインメモリ5の構成情報において、システム運用モードのオペレーティングシステムの起動時とダンプ運用モード時のオペレーティングシステムの起動とで異なった領域(第1のメインメモリ領域、第2のメインメモリ領域)を設定し、障害発生時には、障害発生時のメモリ情報を保存したまま、ダンプ運用モードで再起動してダンプ処理を行なう。
【選択図】図1

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の領域における所定の領域を容易に算出することが可能となる。
以上のように、本発明によると、障害発生時のパニックダンプによるメモリデータ採取処理を確実に行なうことを可能にするパニックダンプ採取のためのプログラム、方法、及び機構を提供することができる。
本発明の実施例に係る構成の主要部の例を示す図である。 本発明の実施例に係るROMファームウェアの処理を示すフローチャートである。 ROMファームウェアが作成するシステム運用モード時のメモリ情報テーブルの例を示す図である。 ROMファームウェアが作成するシステム運用モード時のメモリ情報テーブルの例を示す図である。 ROMファームウェアが作成するダンプ運用モード時のメモリ情報テーブルの例を示す図である。 本発明の実施例に係るブートファームウェアの処理を示すフローチャートである。 本発明の実施例に係るOSローダ及びOSの処理を示すフローチャートである。 図5に示したステップS407からステップS409の処理の具体例を示す図である。 OSが異常を検出してから再起動処理が行なわれるまでの処理を示すフローチャートである。 OSが異常を検出してから再起動処理が行なわれるまでの処理の変形例を示すフローチャートである。。 電源制御手段にダンプ運用モード/システム運用モードの切替手段を持たせた場合に、OSが異常を検出してから再起動処理が行なわれるまでの処理の例を示している。
以下、本発明の実施形態について図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のメインメモリ領域の先頭アドレスから第2のメインメモリ領域の先頭アドレスをひいたものに等しいため、カーネルコア領域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に移行し、ダンプ処理エントリを行なう(ダンプ処理エントリプログラムを起動する)。
そして、処理をステップS603に移行して、ダンプ処理エントリプログラムから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のいずれか一項に記載のパニックダンプ採取機構。
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 (4)

  1. 通常のシステム運用動作を実行するシステム運用モードと、ダンプ情報を採取するダンプ運用モードとで動作可能な情報処理装置の制御方法であって、
    前記情報処理装置の演算処理部が、プログラムの実行により、
    前記情報処理装置の起動開始時に、前記情報処理装置の運用モードを示す情報を参照し、
    前記情報がシステム運用モードを示している場合には、情報処理装置のメモリの領域のうち、第1の領域を前記情報処理装置の起動処理に使用する領域として設定する一方、前記情報が前記ダンプ運用モードを示している場合には、前記メモリの領域のうち、前記第1の領域とは異なる第2の領域を前記情報処理装置の起動処理に使用する領域として設定し、
    前記設定された領域の初期化及び診断を実行し、
    前記設定された領域を用いて前記情報処理装置を起動し、
    前記情報が前記ダンプ運用モードを示している場合には、前記第1の領域に格納されている情報を読み出すダンプ処理を実行し、前記ダンプ処理の終了後に前記情報処理装置を再起動させることを特徴とする、制御方法。
  2. 前記演算処理部は、プログラムの実行により、前記ダンプ処理が終了した場合、前記情報をシステム運用モードを示す情報に更新した後に、前記情報処理装置を再起動させることを特徴とする、請求項1に記載の制御方法。
  3. 前記演算処理部は、プログラムの実行により、前記設定された領域の初期化及び診断の実行後、前記設定された領域にオペレーティングシステムを展開し、
    前記展開されたオペレーティングシステムを動作させることで前記情報処理装置を起動させることを特徴とする、請求項1又は2に記載の制御方法。
  4. 通常のシステム運用動作を実行するシステム運用モードと、ダンプ情報を採取するダンプ運用モードとで動作可能な情報処理装置の制御方法であって、
    前記情報処理装置の演算処理部が、
    前記情報処理装置の起動処理を実行する第1のプログラムの実行により、
    前記情報処理装置の起動開始時に、前記情報処理装置の運用モードを示す情報を参照し、
    前記情報がシステム運用モードを示している場合には、情報処理装置のメモリの領域のうちの第1の領域を、前記情報処理装置の起動処理に使用する領域として設定し、前記情報が前記ダンプ運用モードを示している場合には、前記メモリの領域のうち、前記第1の領域とは異なる第2の領域を前記情報処理装置の起動処理に使用する領域として設定した管理情報を作成し、
    前記設定された領域の初期化及び診断を実行し、
    前記設定された領域にオペレーティングシステムを展開して前記情報処理装置を起動し、
    制御を前記第1のプログラムから前記オペレーティングシステムに渡し、
    前記オペレーティングシステムの実行により、
    前記情報が前記ダンプ運用モードを示している場合には、前記第1の領域に格納されている情報を読み出すダンプ処理を実行し、
    前記ダンプ処理の終了後に前記情報処理装置を再起動させることを特徴とする、制御方法。
JP2010277134A 2010-12-13 2010-12-13 パニックダンプ採取のためのプログラム、方法、機構 Expired - Fee Related JP5348120B2 (ja)

Priority Applications (1)

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

Applications Claiming Priority (1)

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

Related Parent Applications (1)

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

Publications (2)

Publication Number Publication Date
JP2011054212A true JP2011054212A (ja) 2011-03-17
JP5348120B2 JP5348120B2 (ja) 2013-11-20

Family

ID=43943058

Family Applications (1)

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

Country Status (1)

Country Link
JP (1) JP5348120B2 (ja)

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2013003984A (ja) * 2011-06-20 2013-01-07 Fuji Xerox Co Ltd 情報処理装置、画像形成装置、およびプログラム
JP2015200932A (ja) * 2014-04-04 2015-11-12 富士通株式会社 メモリ制御方法及び情報処理装置
JP2020135240A (ja) * 2019-02-15 2020-08-31 株式会社リコー 情報処理装置、制御方法、およびプログラム

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH0581089A (ja) * 1991-09-19 1993-04-02 Tokyo Electric Co Ltd 電子機器
JPH0895834A (ja) * 1994-09-28 1996-04-12 Toshiba Corp システムダンプ採取方法
JPH10133918A (ja) * 1996-11-01 1998-05-22 Toshiba Corp コンピュータシステム
JP2004013714A (ja) * 2002-06-10 2004-01-15 Mitsubishi Electric Corp 通信端末装置、デバッグ情報通知システム及びコンピュータ・プログラム
JP2004102395A (ja) * 2002-09-05 2004-04-02 Hitachi Ltd メモリダンプデータの取得方法および情報処理装置、ならびにそのプログラム

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH0581089A (ja) * 1991-09-19 1993-04-02 Tokyo Electric Co Ltd 電子機器
JPH0895834A (ja) * 1994-09-28 1996-04-12 Toshiba Corp システムダンプ採取方法
JPH10133918A (ja) * 1996-11-01 1998-05-22 Toshiba Corp コンピュータシステム
JP2004013714A (ja) * 2002-06-10 2004-01-15 Mitsubishi Electric Corp 通信端末装置、デバッグ情報通知システム及びコンピュータ・プログラム
JP2004102395A (ja) * 2002-09-05 2004-04-02 Hitachi Ltd メモリダンプデータの取得方法および情報処理装置、ならびにそのプログラム

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2013003984A (ja) * 2011-06-20 2013-01-07 Fuji Xerox Co Ltd 情報処理装置、画像形成装置、およびプログラム
JP2015200932A (ja) * 2014-04-04 2015-11-12 富士通株式会社 メモリ制御方法及び情報処理装置
JP2020135240A (ja) * 2019-02-15 2020-08-31 株式会社リコー 情報処理装置、制御方法、およびプログラム
JP7283108B2 (ja) 2019-02-15 2023-05-30 株式会社リコー 情報処理装置、制御方法、およびプログラム

Also Published As

Publication number Publication date
JP5348120B2 (ja) 2013-11-20

Similar Documents

Publication Publication Date Title
JP4677214B2 (ja) パニックダンプ採取のためのプログラム、方法、及び機構
JP5176837B2 (ja) 情報処理システム及びその管理方法、制御プログラム並びに記録媒体
KR101201186B1 (ko) 데이터를 기억 장치에 기록하기 위한 방법 및 시스템
KR102136906B1 (ko) Bpram을 이용한 운영체제의 레이아웃 및 실행
JP5120664B2 (ja) サーバシステム及びクラッシュダンプ採取方法
US8595552B2 (en) Reset method and monitoring apparatus
CN104254840A (zh) 在计算机系统中的存储器转储和分析
WO2017059721A1 (zh) 一种信息存储方法和装置、及服务器
US9715267B2 (en) Method for switching operating systems and electronic apparatus
JP2010092127A (ja) コンピュータ装置、プロセッサ診断方法、及びプロセッサ診断制御プログラム
JP5609242B2 (ja) 情報処理装置及びメモリダンプ採取方法
JP2007133544A (ja) 障害情報解析方法及びその実施装置
CN109271206B (zh) 一种异常现场的内存压缩和保存方法
CN108628726B (zh) Cpu状态信息记录方法和装置
US20130007439A1 (en) Multicore processor system, computer product, and notification method
JP5348120B2 (ja) パニックダンプ採取のためのプログラム、方法、機構
JP2010092125A (ja) コンピュータ装置、メモリ診断方法、及びメモリ診断制御プログラム
US20050033952A1 (en) Dynamic scheduling of diagnostic tests to be performed during a system boot process
KR102090977B1 (ko) 정보 처리장치 및 리소스 관리방법
CN114741119A (zh) 系统的启动方法、装置、计算机设备和存储介质
CN113703823A (zh) 一种bmc固件升级方法、装置、电子设备及存储介质
JP5948416B2 (ja) 情報処理装置、情報保存処理プログラム及び情報保存処理方法
KR101420026B1 (ko) 부팅 프로세스 중에 파일들을 로딩하기 위한 방법, 장치 및 컴퓨터 판독가능 저장 매체
US20230350755A1 (en) Coordinated operating system rollback
CN116860546A (zh) 一种日志保存方法、车载设备、存储介质及芯片

Legal Events

Date Code Title Description
A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20120821

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20121018

A02 Decision of refusal

Free format text: JAPANESE INTERMEDIATE CODE: A02

Effective date: 20130305

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20130524

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

Free format text: JAPANESE INTERMEDIATE CODE: A911

Effective date: 20130603

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: 20130723

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20130805

R150 Certificate of patent or registration of utility model

Ref document number: 5348120

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