(57)【要約】【課題】オペレーティングシステムの障害が発生した場合、障害発生時のメモリ情報を採取し、障害解析を可能とするサーバシステムを提供する。【解決手段】ハードウェアによるＢＭＣＦＷ３０２のストール監視を行い、ストール検出時にはリセットを行う。また、ＢＭＣＦＷ３０２のブートローダー４０１が使用するメモリ領域とLinuxカーネル４０２が使用するメモリ領域を有するメモリ３０４を具備する。そして、ＰＤＬ３０５に保持されているリセット要因に基づいて通常のリセットかストール検出によるリセットかを判別し、ストール検出によるリセットが発生した場合には、メモリ３０４のストール発生時のLinuxカーネルが使用していたメモリ領域の情報を採取する。【選択図】図１
2011014075.tif 000002
【特許請求の範囲】
【請求項１】
ハードウェアによるファームウェアのストール監視を行い、前記ストール検出時にリセットを行う手段と、
前記ファームウェアのブートローダーが使用する領域とその他ファームウェアが使用する領域とを有するメモリと、
前記ストール検出時のリセットか通常のリセットかのリセット要因を判別し、前記ストール検出によるリセットが発生した場合には、前記メモリのその他ファームウェアが使用する領域の情報を採取する手段と、
を備えたことを特徴とするサーバシステム。
【請求項２】
ＣＥＬＬ上に搭載されたＭＧＭＴと、
前記ＭＣＭＴ上にあって前記ＣＥＬＬ上のハードウェアを制御する、ソフトウェア構造がブートローダーとLinuxカーネルに分けられたオペレーティングシステムとして組み込みLinuxを有するＢＭＣＦＷと、
前記ＭＧＭＴを制御する中核となるＳＰと、
前記ブートローダーが使用するメモリ領域と前記Linuxカーネルが使用するメモリ領域とを有するメモリと、
前記ＢＭＣＦＷのストール監視を行い、ストールを検出した場合には、リセットを行い、前記ＢＭＣＦＷを再起動するＰＬＤと、
前記ＢＭＣＦＷの再起動時に前記ＰＬＤに保持されているリセット要因を読み取る手段と、
前記リセット要因に基づき前記ＰＬＤによるＳＰリセットが発生した場合には、前記ストール発生時における前記メモリの前記Linuxカーネルが使用していたメモリ領域の情報を採取する手段と、
を備えたことを特徴とするサーバシステム。
【請求項３】
前記ＢＭＣＦＷは、不揮発性メモリ上に格納されていることを特徴とする請求項２に記載のサーバシステム。
【請求項４】
前記ＰＬＤによるＳＰリセット時には前記メモリの情報は保持されていることを特徴とする請求項２又は３に記載のサーバシステム。
【請求項５】
前記Linuxカーネルが使用していたメモリ領域から採取した情報は前記メモリとは異なる第２のメモリに格納することを特徴とする請求項２乃至４のいずれか１項に記載のサーバシステム。
【請求項６】
ストール監視手段により、ハードウェアによるファームウェアのストール監視を行い、前記ストール検出時にリセットを行う手段と、
前記ファームウェアのブートローダーが使用する領域とその他ファームウェアが使用する領域とを有するメモリとを備えたサーバシステムのクラッシュダンプ採取方法であって、
判別手段により、前記ストール検出時のリセットか通常のリセットかのリセット要因を判別する工程と、
採取手段により、前記ストール検出によるリセットが発生した場合には、前記メモリのその他ファームウェアが使用する領域の情報を採取する工程と、
を含むことを特徴とするクラッシュダンプ採取方法。
【請求項７】
ＣＥＬＬ上に搭載されたＭＧＭＴと、
前記ＭＣＭＴ上にあって前記ＣＥＬＬ上のハードウェアを制御する、ソフトウェア構造がブートローダーとLinuxカーネルに分けられたオペレーティングシステムとして組み込みLinuxを有するＢＭＣＦＷと、
前記ＭＧＭＴを制御する中核となるＳＰと、
前記ブートローダーが使用するメモリ領域と、前記Linuxカーネルが使用するメモリ領域とに分けられたメモリと、を有するサーバシステムのクラッシュダンプ採取方法であって、
ＰＬＤにより、前記ＢＭＣＦＷのストール監視を行い、ストールを検出した場合には、リセットを行い、前記ＢＭＣＦＷを再起動する工程と、
読み取り手段により、前記ＢＭＣＦＷの再起動時に前記ＰＬＤに保持されているリセット要因を読み取る工程と、
情報採取手段により、前記リセット要因に基づき前記ＰＬＤによるＳＰリセットが発生した場合には、前記ストール発生時における前記メモリの前記Linuxカーネルが使用していたメモリ領域の情報を採取する工程と、
を含むことを特徴とするクラッシュダンプ採取方法。
【請求項８】
前記ＢＭＣＦＷは、不揮発性メモリ上に格納されていることを特徴とする請求項７に記載のクラッシュダンプ採取方法。
【請求項９】
前記ＰＬＤによるＳＰリセット時には前記メモリの情報は保持されていることを特徴とする請求項７又は８に記載のクラッシュダンプ採取方法。
【請求項１０】
前記Linuxカーネルが使用していたメモリ領域から採取した情報は前記メモリとは異なる第２のメモリに格納することを特徴とする請求項７乃至９のいずれか１項に記載のクラッシュダンプ採取方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、サーバシステムに関し、特に、サーバシステムに組み込まれたＢＭＣＦＷ（組み込みLinux等）のクラッシュダンプを採取するクラッシュダンプ採取方法に関するものである。
【背景技術】
【０００２】
サーバシステムとは、基幹系システムに利用されるコンピュータシステムのことであり、サーバシステムのハードウェアを直接制御するソフトウェアであるファームウェアがサーバシステム内に組み込まれる。
【０００３】
エンタープライズ向けのサーバシステムには、複数のＣＥＬＬ（パーソナルコンピュータのマザーボードに相当するベースボード）を搭載することが可能で、1つ以上のＣＥＬＬを束ねた状態でホストＯＳ（オペレーティングシステム）を動作させることができる。ＣＥＬＬ自身を制御するため、それぞれのＣＥＬＬ上にＭＧＭＴ（マネージメントボード）が搭載されており、ＭＧＭＴ上でファームウェア（ＢＭＣＦＷと呼ぶ）が動作している。ＭＧＭＴの障害に対してもシステム運用を続行するため、ＭＧＭＴが二重化される場合もある。
【０００４】
図６は従来のサーバシステムに搭載されるＣＥＬＬの一例を示すブロック図である。なお、図６では１つのＣＥＬＬ１００を表しており、１つのＭＧＭＴ１０１を有する。ＭＧＭＴ１０１は様々なハードウェアコンポーネントから構成されるマネージメントボードであり、図６にはＢＭＣＦＷ１０２が動作するために必要となるハードウェアコンポーネントの一部を示す。
【０００５】
図６の例ではＦＬＡＳＨＲＯＭ（不揮発性のフラッシュメモリ）１０４に格納されているＢＭＣＦＷ１０２が、ＭＧＭＴ１０１のパワーオンと共にＳＰ（サービスプロセッサ）１０３により起動され、ＢＭＣＦＷ１０２がソフトウェア動作を開始する。ＳＰ１０３はＢＭＣ（ベースボード・マネジメント・コントローラ）とも呼ばれ、ＭＧＭＴを制御する中枢となるマイクロコントローラであり、ＣＰＵ（プロセッサ）や各種コネクタインターフェイス（シリアルやＬＡＮ、ＵＳＢポート等）を備えている。
【０００６】
ＢＭＣＦＷ１０２のオペレーティングシステム（組み込みLinux等）はメモリ１０４上へ展開され、メモリ１０４上でプログラム動作を開始する。メモリ１０４はＳＤＲＡＭ（シンクロナスＤＲＡＭ）とも呼ばれ、ＳＰ１０３のリセットやＭＧＭＴ１０１の電源切断によりメモリ１０４の内容は消去され、保証されなくなる。
【０００７】
また、ＰＬＤ（Programmable Logic Device ；プログラム可能な半導体デバイス）１０５を利用してハードウェアによりＢＭＣＦＷ１０２のストール監視を行い、ストール（ＢＭＣＦＷ１０２の完全停止状態）を検出した場合には、ＰＬＤ１０５がＭＧＭＴ１０１のリセットを行い、ＢＭＣＦＷ１０２の再起動を行う。
【０００８】
図７は図６に示す従来システムの処理の流れを示すフローチャートである。図６に示すＢＭＣＦＷ１０２は組み込みLinuxであり、カーネルと呼ばれるオペレーティングシステム上でアプリケーションプログラムが動作する形態となっている。カーネル内部で障害が発生すると（図７のステップ１００）、カーネルが停止する（図７のステップ１０１）。
【０００９】
ＰＬＤ１０５は常時ＢＭＣＦＷ１０２を監視しており、一定時間ＢＭＣＦＷ１０２からの応答がなかった場合には、ＢＭＣＦＷ１０４が完全停止してしまったものと判断する（図７のステップ１０２）。ＰＬＤ１０５による当該機能のことをＷＤＴ（番犬タイマー、ウォッチドッグタイマー）と呼ぶ。
【００１０】
ＷＤＴが働くと、ＰＬＤ１０５によりＳＰ１０３に対してリセットが発行され（図７のステップ１０３）、ＢＭＣＦＷ１０２がストール状態から解除され、再起動される（図７のステッフプ１０４）。ＢＭＣＦＷ１０２が起動されると、再びシステムの運用が開始される（図７のステップ１０５）。従来方式では、ＷＤＴを利用することでＢＭＣＦＷ１０２のストール状態を救済することが可能である。
【００１１】
なお、上述のようなサーバシステムに関連する技術としては、特許文献１乃至４に記載された技術がある。
【先行技術文献】
【特許文献】
【００１２】
【特許文献１】特開２００４−２８０５３８号公報
【特許文献２】特開２００９−０７５９９２号公報
【特許文献３】特開昭６２−０５２６４７号公報
【特許文献４】特表２００８−５４６０７７号公報
【発明の概要】
【発明が解決しようとする課題】
【００１３】
上記従来技術では、上述のようにＣＥＬＬ内部にＭＧＭＴが搭載され、ＭＧＭＴを制御するファームウェアを用い、ファームウェアのオペレーティングシステムとして組み込みLinuxを採用しているシステムにおいて、ハードウェアによるファームウェアのストール監視を行い、ストールを検出した場合にはファームウェアに対してリセットを行う。
【００１４】
しかしながら、ハードウェアによるリセットと、通常のパワーオンによるリセットとをファームウェアが区別することができない。また、ファームウェアがストールした際のメモリイメージを採取することができない。そのため、ＢＭＣＦＷストール発生時のハードウェアによるリセットでは、ＢＭＣＦＷストール時の情報を一切残すことができず、ＢＭＣＦＷがストールした要因の調査が行えない。
【００１５】
本発明の目的は、オペレーティングシステムの障害が発生した場合には、障害発生時のメモリ情報を採取しつつ、ＢＭＣＦＷの障害からの復旧を行い、障害解析を可能とすることである。
【課題を解決するための手段】
【００１６】
本発明は、ＣＥＬＬ（パーソナルコンピュータのマザーボードに相当するベースボード）を搭載し、ＣＥＬＬにＭＧＭＴ（マネージメントボード）を有するサーバシステムに関するものである。ＭＧＭＴ上にはＢＭＣＦＷ（ＭＧＭＴを制御するためのマネージメントファームウェア）が動作しており、ＣＥＬＬ上に搭載されているハードウェアの制御を行い、ＢＭＣＦＷのオペレーティングシステムとして、組み込みLinux等を有するものである。
【００１７】
そして、本発明は、ＢＭＣＦＷのオペレーティングシステム自身が内部でソフトウェア処理の矛盾を発見した場合（カーネルパニック）、ハードウェア障害によるＢＭＣＦＷのオペレーティングシステムの動作停止（カーネルストール）が発生した場合には、ＷＤＴによるリセットとソフトリセット（通常のＢＭＣＦＷのリブート）を区別する、ＢＭＣＦＷの構成要素であるブートローダーと組み込みLinux本体のメモリ使用領域を切り離す、メモリイメージの外部ＦＬＡＳＨＲＯＭ等への格納等という方法で解決するものである。
【発明の効果】
【００１８】
本発明によれば、組み込みLinuxのクラッシュダンプ（障害発生時のメモリイメージ）の採取を実現でき、ＢＭＣＦＷのソフトウェア障害やＭＧＭＴハードウェア障害の解析を実現することが可能となる。そのため、システムの運用停止時間を極小に抑えられ、システム運用を続行することが可能となる。
【図面の簡単な説明】
【００１９】
【図１】本発明に係るサーバシステムの一実施形態を示すブロック図である。
【図２】図１のＰＬＤとＳＰとの接続関係を示すブロック図である。
【図３】図１のＢＭＣＦＷのメモリマップを示す図である。
【図４】図１の動作を説明するフローチャートである。
【図５】図１の動作を説明するフローチャートである。
【図６】従来例のサーバシステムを示すブロック図である。
【図７】図６の動作を説明するフローチャートである。
【発明を実施するための形態】
【００２０】
次に、発明を実施するための形態について図面を参照して詳細に説明する。図１は本発明に係るサーバシステムの一実施形態を示すブロック図である。図１の実施形態では図６の従来システムに対してＳＰＩ ＦＬＡＳＨＲＯＭ３０６を追加した点が異なっている。
【００２１】
図１では１つのＣＥＬＬ３００を表しており、１つのＭＧＭＴ３０１を有する。ＭＧＭＴ３０１は様々なハードウェアコンポーネントから構成されるマネージメントボードであり、図１にはＢＭＣＦＷ３０２が動作するために必要となるハードウェアコンポーネントの一部を示す。
【００２２】
図１の実施形態では、ＦＬＡＳＨＲＯＭ（不揮発性のフラッシュメモリ）に格納されているＢＭＣＦＷ３０２が、ＭＧＭＴ３０１のパワーオンと共に、ＳＰ（サービスプロセッサ）３０３により起動され、ＢＭＣＦＷ３０２が動作を開始する。ＢＭＣＦＷ３０２のオペレーティングシステム（組み込みLinux）は、メモリ３０４上へ展開され、メモリ３０４上で動作を行う。
【００２３】
メモリ３０４はＳＤＲＡＳＭ（シンクロナスＤＲＡＭ）とも呼ばれ、ＳＰ３０３のリセットやＭＧＭＴ３０１の電源切断により、メモリ３０４の内容は消去され、保証されなくなる。ＰＬＤ（Programmable Logic Device ；プログラム可能な半導体デバイス）３０５を利用してハードウェアによるＢＭＣＦＷ３０２のストール監視を行い、ストール（ＢＭＣＦＷ３０２が期待外の動作停止していること）を検出した場合には、ＰＬＤ３０５はＭＧＭＴ３０１のリセットを行い、ＢＭＣＦＷ３０２の再起動を行う。
【００２４】
ＳＰＩ ＦＬＡＳＨＲＯＭ３０６は、ＳＰ３０３とＳＰＩ（シリアル・ペリフェラル・インターフェイス）で接続されるＦＬＡＳＨＲＯＭであり、ＢＭＣＦＷ３０２がクラッシュダンプ（メモリイメージ）を格納するデバイスである。
【００２５】
図２は図１におけるＢＭＣＦＷ３０２のメモリマップの一例を示す。ＢＭＣＦＷ３０２はＦＬＡＳＨＲＯＭ３０２のＲＯＭ領域から読み込まれ、メモリ３０４で実装されるＲＡＭ領域へ展開され、メモリ３０４上で動作する。ＢＭＣＦＷ３０２は組み込みLinuxという特質上、ソフトウェア構造がブートローダー４０１とLinuxカーネル（その他ファームウェア）４０２に分かれている。
【００２６】
ＢＭＣＦＷ３０２の起動時に最初にブートローダー４０１が実行され、その次にLinuxカーネル４０２が実行される。ＢＭＣＦＷ３０２からはメモリ３０４はアドレスゼロ番地に配置されているように見えており、ブートローダー４０１とLinuxカーネル４０２は自身の動作のためにメモリ３０４を使用する。
【００２７】
クラッシュダンプ採取を実現するために、図２のメモリマップ４００において、ブートローダー４０１とLinuxカーネル４０２のメモリ使用領域（メモリマップ）を分けている。メモリマップ４００は、例えば、メモリ３０４の搭載容量が１２８ＭＢであると仮定しており、アドレス番地はゼロ番地（0000_0000h）から最終番地（0800_0000h）までとしている。
【００２８】
図２において、ブートローダー４０１は、例えば、メモリアドレス（0000_0000h）から（000F_FFFFh）までの１ＭＢを使用し、Linuxカーネル４０２は、例えば、メモリアドレス（0010_0000h）から（07FF_FFFFh）までの１２７ＭＢを使用する。図２に示すようにメモリマップを分けることで、ブートローダー４０１とLinuxカーネル４０２の使用するメモリ領域が干渉しなくなる。
【００２９】
図３は図１のＳＰ３０３とＰＬＤ３０５との接続関係を示す図である。ＳＰ５００（図１のＳＰ３０３に対応する）はサービスプロセッサ（ベースボード・マネジメント・コントローラ）を表しており、ＢＭＣＦＷを動作させる中枢となる制御コントローラである。ＰＬＤ５０１（図１のＰＬＤ３０５に対応する）はＳＰ５００上で動作するＢＭＣＦＷのストール監視を行うためのプログラム可能な半導体デバイスであり、ＢＭＣＦＷのストール状態を検出すると、リセット線５０３を通じてＰＬＤ５０１からＳＰ５００に対してリセットを発行する。
【００３０】
上述のようにこの仕組みをＷＤＴ（番犬タイマー）と呼ぶ。ＳＰ５００上で動作するＢＭＣＦＷはＰＬＤアクセスパス５０４を通じてＰＬＤ５０１内にあるリセット要因５０２を読み取ることで、ＢＭＣＦＷは通常のリセットか、ＷＤＴによるリセットかを認識することができる。
【００３１】
次に、図１〜図３及び図４、図５を参照して、本実施形態の動作を詳細に説明する。図４及び図５は本実施形態の動作を説明するフローチャートである。図１に示すサーバシステムにおいて、ＣＥＬＬ３００上のＭＧＭＴ３０１は電源が投入されると、ＳＰ３０３の制御プロセッサが、ＦＬＡＳＨＲＯＭに格納されているＢＭＣＦＷ３０２を起動する。
【００３２】
ＢＭＣＦＷ３０２はプログラムコードをメモリ３０４へ移し、メモリ３０４上でプログラムを実行するという形態をとる。ＢＭＣＦＷ３０２のオペレーティングシステムは組み込みLinuxであり、ソフトウェア構造が図２に示すようにブートローダー４０１とLinuxカーネル４０２の２つに分かれている。
【００３３】
BMCFW３０２の起動時には最初にブートローダー４０１が起動され、図２のメモリマップ４００に従ってメモリ３０４の先頭1MB（0000_0000h〜00F_FFFFh）をブートローダー４０１の動作用メモリ領域として使用する。ブートローダー４０１はLinuxカーネル４０２を立ち上げるために必要となるハードウェア（ＭＧＭＴ３０１）の初期化を行い、Linuxカーネル４０２を起動する。Linuxカーネル４０２は図２のメモリマップ４００に従いメモリ３０４の１２７ＭＢ（0010_0000h〜07FF_FFFFh）をLinuxカーネル４０２の動作用メモリ領域として使用する。
【００３４】
次に、図４及び図５のフローチャートを参照してＢＭＣＦＷにおけるソフトウェア障害発生時の、クラッシュダンプ採取にいたるまでの処理の流れを説明する。まず、組み込みLinuxであるＢＭＣＦＷ３０２の動作中にLinuxカーネル４０２のカーネル内部処理において何らかの矛盾（Oops）を発見した場合には、当該矛盾箇所のみを切り離し、カーネルの動作を続行する。
【００３５】
この仕組みをOops発生による処理という（図４のステップ６００）。ファームウェアとしての組み込みLinuxを考慮すると、システムの運用を正常状態に復帰させるため、Oops発生から復旧する必要があるため、Oops発生後にカーネルパニック処理に移行する（図４のステップ６０２）。
【００３６】
また、組み込みLinuxであるＢＭＣＦＷの動作中にLinuxカーネル４０２のカーネル内部処理においてカーネルの動作ができない致命的な障害を検出した場合には、カーネルパニック発生とみなし（図４のステップ６０１）、カーネルパニック処理に移行する（図４のステップ６０２）。
【００３７】
カーネルパニック処理は（図４のステップ６０２）、ＢＭＣＦＷのソフトウェア動作を完全停止（ストール状態）させるため、ハードウェアからの割り込みをすべて禁止し、無限ループへ入ることによりカーネルストール状態（図４のステップ６０３）に遷移する。カーネルストール状態に遷移すると、ＢＭＣＦＷは完全停止状態となり、ＰＬＤ３０５によるストール監視が働き（図４のステップ６０４）、一定時間後にＰＬＤ３０５によりＳＰ３０３がリセットされる（図４のステップ６０５）。
【００３８】
ＰＬＤ３０５によりＳＰ３０３がリセットされると、ＢＭＣＦＷのストール状態は解除され、再びＢＭＣＦＷが起動される（図４のステップ６０６）。ＢＭＣＦＷが起動されると、最初にブートローダー４０１が起動され（図４のステップ６０７）、図３のＰＬＤ５０１が内部に保持しているリセット要因５０２をＰＬＤアクセスパス５０４を通して読み取る（図４のステップ６０８）。
【００３９】
図４のステップ６０８は図５のステップ７００に続いており、まず、ブートローダー４０１はリセット要因５０２を読み出すことにより、ＰＬＤ３０５によるＳＰリセットが発生したのかどうかが分かる（図５のステップ７００）。ＰＬＤ３０５によるＳＰリセットが発生していない場合には（ステップ７００がＮＯ）、障害が発生していない通常の起動であるため、ブートローダー４０１はLinuxカーネル４０２の起動へ遷移する（図５のステップ７０３）。
【００４０】
一方、ＰＬＤ３０５によるＳＰリセットが発生した場合には（ステップ７００がＹＥＳ）、ＢＭＣＦＷがストールしていたことを示すため、ブートローダー４０１はLinuxカーネル４０２がカーネルパニック処理に遷移したときのメモリ領域を採取する（クラッシュダンプ採取と呼ぶ）。クラッシュダンプ採取の処理はブートローダー４０１がLinuxカーネル４０２が使用していたメモリ３０４の１２７ＭＢ（0010_0000h〜07FF_FFFFh）のメモリ領域を読み出し（図５のステップ７０１）、図１に示すＳＰＩ ＦＬＡＳＨＲＯＭ３０６へ格納する（図５のステップ７０２）。
【００４１】
ＰＬＤ３０５によるＳＰリセットにおいては、メモリ３０４の電源を落とさないため、メモリ３０４の内容は保持されている。この仕組みにより、Linuxカーネル４０２の起動が始まる前に障害発生時のメモリイメージを採取することができる。クラッシュダンプ採取後は、ブートローダー４０１はLinuxカーネル４０２の起動へ遷移する（図５のステップ７０３）。
【００４２】
Linuxカーネル４０２が起動すると、メモリ３０４の１２７ＭＢ（0010_0000h〜07FF_FFFFh）のメモリ領域を使用して動作を開始する。Linuxカーネル４０２はリセット要因５０２を読み出すことにより、ＰＬＤ３０５によるＳＰリセットが発生したかどうかが分かる（図５のステップ７０４）。
【００４３】
ＰＬＤ３０５によるＳＰリセットが発生していない場合には、障害が発生していない通常の起動であるため、Linuxカーネル４０２はシステムの運用を開始する（図５のステップ７０６）。ＰＬＤ３０５によるＳＰリセットが発生した場合には、ＢＭＣＦＷがストールしていたことを示すため、保守員やオペレータに分かりやすいようにコンソールに表示を行い、障害が発生したことを知らせる（図５のステップ７０５）。その後、Linuxカーネル４０２はシステムの運用を開始する（図５のステップ７０６）。
【００４４】
本実施形態の要点をまとめると以下の通りとなる。
（１）Linuxカーネル４０２のソースコードを改修し、Oops発生時はカーネルパニック扱いとする。
（２）カーネルパニック発生時に確実にＰＬＤ３０５がストールを検出できるようにするため、Linuxカーネル４０２のソースコードを改修し、完全停止状態にする。
（３）ＰＬＤ３０５の機能実現によりストール検出時のリセットと通常のリセットを、リセット要因として区別できるようにする。
（４）ＰＬＤ３０５によるストール検出時のリセットにおいてはメモリの内容が保持されるようにする。
（５）ブートローダー４０１によるクラッシュダンプ採取処理において、ブートローダー４０１自身が、ストール発生時のLinuxカーネル４０２のメモリ領域を破壊しないようにするため、ブートローダー４０１とLinuxカーネル４０２の使用するメモリ領域を分けている。
（６）ブートローダー４０１によるクラッシュダンプ採取処理において、ＳＰ３０３に直結されている外部ＦＬＡＳＨＲＯＭ３０６へストール発生時のメモリイメージを保存するようにする。
（７）クラッシュダンプ採取後にファームウェアの起動を行い、再度システムの運用を開始できるようにする。
【００４５】
以上のように本実施形態では、組み込みLinuxとしてのＢＭＣＦＷにおいてクラッシュダンプの採取が可能となり、障害発生に対する解析を実現できる。即ち、組み込みLinuxのクラッシュダンプ（障害発生時のメモリイメージ）の採取を実現でき、BMCFWのソフトウェア障害やＭＧＭＴハードウェア障害の解析を行うことが可能となる。そのため、システムの運用停止時間を極小に抑えられ、システム運用を続行することが可能となる。
【００４６】
なお、以上の実施形態のサーバシステムは、ハードウェアによっても実現できるが、コンピュータをそのサーバシステムとして機能させるためのプログラムをコンピュータがコンピュータ読み取り可能な記録媒体から読み込んで実行することによっても実現することができる。
【００４７】
また、以上の実施形態のクラッシュダンプ採取方法は、ハードウェアによっても実現できるが、コンピュータにその方法を実行させるためのプログラムをコンピュータがコンピュータ読み取り可能な記録媒体から読み込んで実行することによっても実現することができる。
【符号の説明】
【００４８】
３００  ＣＥＬＬ
３０１  ＭＧＭＴ
３０２  ＢＭＣＦＷ
３０３  ＳＰ
３０４  メモリ
３０５  ＰＬＤ
３０６  ＳＰＩ ＦＬＡＳＨＲＯＭ
４００  メモリマップ
４０１  ブートローダー
４０２  Linuxカーネル
５００  ＰＬＤ
５０１  ＳＰ
５０２  リセット要因
５０３  リセット線
５０４  ＰＬＤアクセスパス
【図１】
2011014075.tif 000003
【図２】
2011014075.tif 000004
【図３】
2011014075.tif 000005
【図４】
2011014075.tif 000006
【図５】
2011014075.tif 000007
【図６】
2011014075.tif 000008
【図７】
2011014075.tif 000009