JP5120664B2

JP5120664B2 - サーバシステム及びクラッシュダンプ採取方法

Info

Publication number: JP5120664B2
Application number: JP2009159717A
Authority: JP
Inventors: 豊平田
Original assignee: NEC Corp
Current assignee: NEC Corp
Priority date: 2009-07-06
Filing date: 2009-07-06
Publication date: 2013-01-16
Anticipated expiration: 2029-07-06
Also published as: US8489932B2; US20110004780A1; JP2011014075A

Description

本発明は、サーバシステムに関し、特に、サーバシステムに組み込まれたＢＭＣＦＷ（組み込みLinux（登録商標）等）のクラッシュダンプを採取するクラッシュダンプ採取方法に関するものである。

サーバシステムとは、基幹系システムに利用されるコンピュータシステムのことであり、サーバシステムのハードウェアを直接制御するソフトウェアであるファームウェアがサーバシステム内に組み込まれる。

エンタープライズ向けのサーバシステムには、複数のＣＥＬＬ（パーソナルコンピュータのマザーボードに相当するベースボード）を搭載することが可能で、1つ以上のＣＥＬＬを束ねた状態でホストＯＳ（オペレーティングシステム）を動作させることができる。ＣＥＬＬ自身を制御するため、それぞれのＣＥＬＬ上にＭＧＭＴ（マネージメントボード）が搭載されており、ＭＧＭＴ上でファームウェア（ＢＭＣＦＷと呼ぶ）が動作している。ＭＧＭＴの障害に対してもシステム運用を続行するため、ＭＧＭＴが二重化される場合もある。

図６は従来のサーバシステムに搭載されるＣＥＬＬの一例を示すブロック図である。なお、図６では１つのＣＥＬＬ１００を表しており、１つのＭＧＭＴ１０１を有する。ＭＧＭＴ１０１は様々なハードウェアコンポーネントから構成されるマネージメントボードであり、図６にはＢＭＣＦＷ１０２が動作するために必要となるハードウェアコンポーネントの一部を示す。

図６の例ではＦＬＡＳＨＲＯＭ（不揮発性のフラッシュメモリ）１０４に格納されているＢＭＣＦＷ１０２が、ＭＧＭＴ１０１のパワーオンと共にＳＰ（サービスプロセッサ）１０３により起動され、ＢＭＣＦＷ１０２がソフトウェア動作を開始する。ＳＰ１０３はＢＭＣ（ベースボード・マネジメント・コントローラ）とも呼ばれ、ＭＧＭＴを制御する中枢となるマイクロコントローラであり、ＣＰＵ（プロセッサ）や各種コネクタインターフェイス（シリアルやＬＡＮ、ＵＳＢポート等）を備えている。

ＢＭＣＦＷ１０２のオペレーティングシステム（組み込みLinux等）はメモリ１０４上へ展開され、メモリ１０４上でプログラム動作を開始する。メモリ１０４はＳＤＲＡＭ（シンクロナスＤＲＡＭ）とも呼ばれ、ＳＰ１０３のリセットやＭＧＭＴ１０１の電源切断によりメモリ１０４の内容は消去され、保証されなくなる。

また、ＰＬＤ（Programmable Logic Device ；プログラム可能な半導体デバイス）１０５を利用してハードウェアによりＢＭＣＦＷ１０２のストール監視を行い、ストール（ＢＭＣＦＷ１０２の完全停止状態）を検出した場合には、ＰＬＤ１０５がＭＧＭＴ１０１のリセットを行い、ＢＭＣＦＷ１０２の再起動を行う。

図７は図６に示す従来システムの処理の流れを示すフローチャートである。図６に示すＢＭＣＦＷ１０２は組み込みLinuxであり、カーネルと呼ばれるオペレーティングシステム上でアプリケーションプログラムが動作する形態となっている。カーネル内部で障害が発生すると（図７のステップ１００）、カーネルが停止する（図７のステップ１０１）。

ＰＬＤ１０５は常時ＢＭＣＦＷ１０２を監視しており、一定時間ＢＭＣＦＷ１０２からの応答がなかった場合には、ＢＭＣＦＷ１０４が完全停止してしまったものと判断する（図７のステップ１０２）。ＰＬＤ１０５による当該機能のことをＷＤＴ（番犬タイマー、ウォッチドッグタイマー）と呼ぶ。

ＷＤＴが働くと、ＰＬＤ１０５によりＳＰ１０３に対してリセットが発行され（図７のステップ１０３）、ＢＭＣＦＷ１０２がストール状態から解除され、再起動される（図７のステッフプ１０４）。ＢＭＣＦＷ１０２が起動されると、再びシステムの運用が開始される（図７のステップ１０５）。従来方式では、ＷＤＴを利用することでＢＭＣＦＷ１０２のストール状態を救済することが可能である。

なお、上述のようなサーバシステムに関連する技術としては、特許文献１乃至４に記載された技術がある。

特開２００４−２８０５３８号公報特開２００９−０７５９９２号公報特開昭６２−０５２６４７号公報特表２００８−５４６０７７号公報

上記従来技術では、上述のようにＣＥＬＬ内部にＭＧＭＴが搭載され、ＭＧＭＴを制御するファームウェアを用い、ファームウェアのオペレーティングシステムとして組み込みLinuxを採用しているシステムにおいて、ハードウェアによるファームウェアのストール監視を行い、ストールを検出した場合にはファームウェアに対してリセットを行う。

しかしながら、ハードウェアによるリセットと、通常のパワーオンによるリセットとをファームウェアが区別することができない。また、ファームウェアがストールした際のメモリイメージを採取することができない。そのため、ＢＭＣＦＷストール発生時のハードウェアによるリセットでは、ＢＭＣＦＷストール時の情報を一切残すことができず、ＢＭＣＦＷがストールした要因の調査が行えない。

本発明の目的は、オペレーティングシステムの障害が発生した場合には、障害発生時のメモリ情報を採取しつつ、ＢＭＣＦＷの障害からの復旧を行い、障害解析を可能とすることである。

本発明は、ＣＥＬＬ（パーソナルコンピュータのマザーボードに相当するベースボード）を搭載し、ＣＥＬＬにＭＧＭＴ（マネージメントボード）を有するサーバシステムに関するものである。ＭＧＭＴ上にはＢＭＣＦＷ（ＭＧＭＴを制御するためのマネージメントファームウェア）が動作しており、ＣＥＬＬ上に搭載されているハードウェアの制御を行い、ＢＭＣＦＷのオペレーティングシステムとして、組み込みLinux等を有するものである。

そして、本発明は、ＢＭＣＦＷのオペレーティングシステム自身が内部でソフトウェア処理の矛盾を発見した場合（カーネルパニック）、ハードウェア障害によるＢＭＣＦＷのオペレーティングシステムの動作停止（カーネルストール）が発生した場合には、ＷＤＴによるリセットとソフトリセット（通常のＢＭＣＦＷのリブート）を区別する、ＢＭＣＦＷの構成要素であるブートローダーと組み込みLinux本体のメモリ使用領域を切り離す、メモリイメージの外部ＦＬＡＳＨＲＯＭ等への格納等という方法で解決するものである。
即ち、本発明に係るサーバシステムは、ハードウェアによるファームウェアのストール監視を行い、前記ストール検出後にリセットを行うサーバシステムであって、前記ファームウェアの動作中に処理矛盾が発生した場合に、前記ハードウェアの割り込みを禁止し、前記ファームウェアをセルフ無限ループに陥らせることによって前記ハードウェアによるストール検出に導くための手段と、前記ファームウェアのブートローダーが使用する領域とその他ファームウェアが使用する領域とを有するメモリと、前記ストール検出時のリセットか通常のリセットかのリセット要因を判別し、前記ストール検出によるリセットが発生した場合には、前記メモリのその他ファームウェアが使用する領域の情報を採取する手段と、を備えたことを特徴とする。
また、本発明に係るサーバシステムは、システムのベースボード上に搭載された前記ベースボードを制御するためのマネジメントボードと、前記マネジメントボード上にあって前記ベースボード上のハードウェアを制御する、ソフトウェア構造がブートローダーとLinuxカーネルに分けられたオペレーティングシステムとして組み込みLinuxを有するファームウェアと、前記マネジメントボードを制御する中核となるサービスプロセッサと、前記ブートローダーが使用するメモリ領域と前記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カーネル
５００ＰＬＤ
５０１ＳＰ
５０２リセット要因
５０３リセット線
５０４ＰＬＤアクセスパス

Claims

システムのベースボード上に搭載された前記ベースボードを制御するためのマネジメントボードと、
前記マネジメントボード上にあって前記ベースボード上のハードウェアを制御する、ソフトウェア構造がブートローダーとLinux（登録商標）カーネルに分けられたオペレーティングシステムとして組み込みLinuxを有するファームウェアと、
前記マネジメントボードを制御する中核となるサービスプロセッサと、
前記ブートローダーが使用するメモリ領域と前記Linuxカーネルが使用するメモリ領域とに分けられたメモリと、
前記ファームウェアの動作中に前記Linuxカーネルの処理矛盾が発生した場合に、前記ハードウェアの割り込みを禁止し、前記ファームウェアをセルフ無限ループに陥らせることによって前記ハードウェアによるストール検出に導くための手段と、
前記ハードウェアによる前記ファームウェアのストール監視を行い、前記ファームウェアのストールを検出した場合には、前記サービスプロセッサのリセットを行い、前記ファームウェアを再起動するストール検出手段と、
前記ファームウェアの再起動時に前記ストール検出手段に保持されている、当該ストール検出手段に因る前記サービスプロセッサのリセットが発生したのか、又は、当該ストール検出手段に因らない前記サービスプロセッサのリセットが発生したのかの何れであるかを示すリセット要因を読み取る手段と、
前記リセット要因に基づき前記ストール検出手段に因る前記サービスプロセッサのリセットが発生した場合には、前記ストール発生時における前記メモリの前記Linuxカーネルが使用していたメモリ領域の情報を、前記ブートローダーが前記Linuxカーネル起動前に採取する手段と、
を備えることを特徴とするサーバシステム。
前記ファームウェアは、不揮発性メモリ上に格納されていることを特徴とする請求項１に記載のサーバシステム。
前記ストール検出手段による前記サービスプロセッサのリセット時には前記メモリの情報は保持されていることを特徴とする請求項１又は２に記載のサーバシステム。
前記Linuxカーネルが使用していたメモリ領域から採取した情報は前記メモリとは異なる第２のメモリに格納することを特徴とする請求項１乃至３のいずれか１項に記載のサーバシステム。
システムのベースボード上に搭載された前記ベースボードを制御するためのマネジメントボードと、
前記マネジメントボード上にあって前記ベースボード上のハードウェアを制御する、ソフトウェア構造がブートローダーとLinux（登録商標）カーネルに分けられたオペレーティングシステムとして組み込みLinuxを有するファームウェアと、
前記マネジメントボードを制御する中核となるサービスプロセッサと、
前記ブートローダーが使用するメモリ領域と前記Linuxカーネルが使用するメモリ領域とに分けられたメモリと、を有するサーバシステムのクラッシュダンプ採取方法であって、
ストール検出導入手段により、前記ファームウェアの動作中に前記Linuxカーネルの処理矛盾が発生した場合に、前記ハードウェアの割り込みを禁止し、前記ファームウェアをセルフ無限ループに陥らせることによって前記ハードウェアによるストール検出に導くための工程と、
ストール検出手段により、前記ハードウェアによる前記ファームウェアのストール監視を行い、前記ファームウェアのストールを検出した場合には、前記サービスプロセッサのリセットを行い、前記ファームウェアを再起動する工程と、
読み取り手段により、前記ファームウェアの再起動時に前記ストール検出手段に保持されている、当該ストール検出手段に因る前記サービスプロセッサのリセットが発生したのか、又は、当該ストール検出手段に因らない前記サービスプロセッサのリセットが発生したのかの何れであるかを示すリセット要因を読み取る工程と、
情報採取手段により、前記リセット要因に基づき前記ストール検出手段に因る前記サービスプロセッサのリセットが発生した場合には、前記ストール発生時における前記メモリの前記Linuxカーネルが使用していたメモリ領域の情報を、前記ブートローダーが前記Linuxカーネル起動前に採取する工程と、
を含むことを特徴とするクラッシュダンプ採取方法。
前記ファームウェアは、不揮発性メモリ上に格納されていることを特徴とする請求項５に記載のクラッシュダンプ採取方法。
前記ストール検出手段による前記サービスプロセッサのリセット時には前記メモリの情報は保持されていることを特徴とする請求項５又は６に記載のクラッシュダンプ採取方法。
前記Linuxカーネルが使用していたメモリ領域から採取した情報は前記メモリとは異なる第２のメモリに格納することを特徴とする請求項５乃至７のいずれか１項に記載のクラッシュダンプ採取方法。