(57)【特許請求の範囲】
【請求項１】
コンピュータ本体を監視して障害調査用資料及び前記コンピュータ本体を制御するための制御情報を含むデータを格納する揮発性メモリを有する監視装置のリセット方法であって、
前記監視装置内で異常が発生すると、前記監視装置のプロセッサコア及び前記プロセッサコアが使用するレジスタはリセットされるが前記揮発性メモリはリセットされないソフトウェアリセット中に誤動作する可能性がある、前記監視装置内の第１のハードウェアをディセーブル状態に制御する工程と、
前記監視装置内のハードウェアからの割り込みをマスクして前記ソフトウェアリセットを実行する工程と、
前記監視装置内の第２のハードウェアがディセーブル状態であると、前記監視装置のハードウェアリセットが実行されたと判断して前記揮発性メモリを初期化する工程と、
前記第２のハードウェアがイネーブル状態であると、前記ソフトウェアリセットが実行されたと判断して前記揮発性メモリを初期化する工程をスキップする工程と、
前記監視装置の監視機能を実現するための処理を実行するプロセッサプログラムを再起動する工程
を前記プロセッサコアに実行させる、リセット方法。
【請求項２】
前記ソフトウェアリセットを実行する工程は、前記監視装置内の周辺プロセッサはリセットせず、
前記プロセッサプログラムを再起動する工程は、前記揮発性メモリに前記データが保持された状態で前記プロセッサプログラムを最初から実行して前記監視装置のソフトウェアが再起動された状態とする、請求項１記載のリセット方法。
【請求項３】
前記監視装置のソフトウェアは、オペレーティングシステムに含まれるカーネル、前記カーネルを前記揮発性メモリに読み込み実行するブートプログラム、及び前記プロセッサプログラムを有し、
前記ソフトウェアリセットを実行する工程は、前記カーネルにより実行される、請求項１又は２記載のリセット方法。
【請求項４】
前記ソフトウェアリセットを実行する工程は、前記異常が前記監視装置内の内部矛盾であると前記カーネル内のルーチンを呼び出して前記ルーチンにより実行され、前記異常が前記監視装置内のハードウェアの異常であると前記カーネル内のマシンチェックハンドラによりハードウェアリセットを行うことなくマシンチェック割り込みを発生して実行される、請求項３記載のリセット方法。
【請求項５】
コンピュータ本体を監視するプロセッサコアと、
前記プロセッサコアによりコンピュータ本体を監視して得られた障害調査用資料及び前記コンピュータ本体を制御するための制御情報を含むデータを格納する揮発性メモリを備えた監視装置であって、
前記プロセッサコアは、
前記監視装置内で異常が発生すると、前記プロセッサコア及び前記プロセッサコアが使用するレジスタはリセットされるが前記揮発性メモリはリセットされないソフトウェアリセット中に誤動作する可能性がある前記監視装置内の第１のハードウェアをディセーブル状態に制御する手段と、
前記監視装置内のハードウェアからの割り込みをマスクして前記ソフトウェアリセットを実行する手段と、
前記監視装置内の第２のハードウェアがディセーブル状態であると、前記監視装置のハードウェアリセットが実行された判断して前記揮発性メモリを初期化する手段と、
前記第２のハードウェアがイネーブル状態であると、前記ソフトウェアリセットが実行されたと判断して前記揮発性メモリを初期化する手段による初期化をスキップする手段と、
前記監視装置の監視機能を実現するための処理を実行するプロセッサプログラムを再起動する手段を有する、監視装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ハードウェアの状態を保存したまま監視装置をリセットするリセット方法、及びそのようなリセット方法を用いる監視装置に関する。本発明は、コンピュータにリセット方法を実行させるコンピュータプログラム、及びそのようなコンピュータプログラムを格納したコンピュータ読み取り可能な記憶媒体にも関する。
【背景技術】
【０００２】
コンピュータ本体で異常が発生すると、ハードウェアリセットが行われる。一般的なハードウェアリセットは、ＣＰＵ（Central Processing Unit）等のプロセッサのコアと、メモリコントローラやＬＡＮ（Local Area Network）コントローラ等の周辺プロセッサを含むシステムボード全体にリセットをかけ、コンピュータ本体を形成するシステムボード上の各部を初期状態に設定する。障害解析に使用するトレース（又は、動作履歴）等の障害情報は、変更頻度が高いので揮発性メモリに保持されるが、揮発性メモリがハードウェアリセットにより初期状態に設定されてしまうと、揮発性メモリはリフレッシュされないので揮発性メモリに保持されたデータが壊れてしまう。【０００３】
又、障害情報を保存する方法としては、異常が起きたコンピュータ本体の代わりにサービスプロセッサ（ＳＶＰ：Service Processor）と呼ばれる監視装置にメモリダンプを実行させる方法がある。しかし、サービスプロセッサ自身で異常が発生した場合には、サービスプロセッサ自身が障害情報を保存することはできない。このため、サービスプロセッサで障害が発生した場合には、サービスプロセッサから障害調査用資料を取り出して解析することで障害の原因を特定する作業が必要となる。尚、上記の障害とは、サービスプロセッサのオペレーティングシステム（ＯＳ：Operating System）として動作している例えばLinux（登録商標）ＯＳがパニックリブート（Panic Reboot）を実行するような状況を言う。【０００４】
従来は、サービスプロセッサで発生した障害に関する障害情報を取得できない場合がある。具体的には、サービスプロセッサのＯＳがパニックリブートを実行してサービスプロセッサが再起動された後に、揮発性メモリに保持された障害情報等のデータの保存が保障されていないために、データが壊れてしまう場合がある。【０００５】
汎用コンピュータであれば、揮発性メモリに保持されたデータを不揮発性メモリやハードディスクに保存するバックアップを行う。しかし、サービスプロセッサには、コストを抑えるために高価な不揮発性メモリやハードディスクが設けられていない場合が多く、不揮発性メモリが設けられていても非常に限られた記憶容量の不揮発性メモリが用いられている。このため、サービスプロセッサにおいては、揮発性メモリにデータを保存する必要がある。書き換え回数が多いデータは揮発性メモリに保存してサービスプロセッサのリブート後にもアクセス可能とする要望がある一方、揮発性メモリに保持されたデータは電源切断では消えてもサービスプロセッサのリブートでは壊れずに残るようにする要望がある。
【先行技術文献】
【特許文献】
【０００６】
【特許文献１】特開平８−２１２１１３号公報
【特許文献２】特開平１−１５９７３９号公報
【特許文献３】特開平９−３３０２５３号公報
【非特許文献】
【０００７】
【非特許文献１】MPC8379E PowerQUICC II Pro Integrated Host Processor Family Reference Manual
【発明の概要】
【発明が解決しようとする課題】
【０００８】
従来の監視装置では、監視装置で異常が発生してハードウェアリセットが行われると、揮発性メモリに保持された障害情報等のデータが監視装置の再起動により壊れてしまうという問題があった。【０００９】
そこで、本発明は、ハードウェアリセットの機能を使わずに、監視装置をソフトウェアのみでリセット可能なリセット方法及び監視装置を提供することを目的とする。
【課題を解決するための手段】
【００１０】
本発明の一観点によれば、コンピュータ本体を監視して障害調査用資料及び前記コンピュータ本体を制御するための制御情報を含むデータを格納する揮発性メモリを有する監視装置のリセット方法であって、前記監視装置内で異常が発生すると、前記監視装置のプロセッサコア及び前記プロセッサコアが使用するレジスタはリセットされるが前記揮発性メモリはリセットされないソフトウェアリセット中に誤動作する可能性がある、前記監視装置内の第１のハードウェアをディセーブル状態に制御する工程と、前記監視装置内のハードウェアからの割り込みをマスクして前記ソフトウェアリセットを実行する工程と、前記監視装置内の第２のハードウェアがディセーブル状態であると、前記監視装置のハードウェアリセットが実行されたと判断して前記揮発性メモリを初期化する工程と、前記第２のハードウェアがイネーブル状態であると、前記ソフトウェアリセットが実行されたと判断して前記揮発性メモリを初期化する工程をスキップする工程と、前記監視装置の監視機能を実現するための処理を実行するプロセッサプログラムを再起動する工程を前記プロセッサコアに実行させるリセット方法が提供される。
【００１１】
本発明の一観点によれば、コンピュータ本体を監視するプロセッサコアと、前記プロセッサコアによりコンピュータ本体を監視して得られた障害調査用資料及び前記コンピュータ本体を制御するための制御情報を含むデータを格納する揮発性メモリを備えた監視装置であって、前記プロセッサコアは、前記監視装置内で異常が発生すると、前記プロセッサコア及び前記プロセッサコアが使用するレジスタはリセットされるが前記揮発性メモリはリセットされないソフトウェアリセット中に誤動作する可能性がある前記監視装置内の第１のハードウェアをディセーブル状態に制御する手段と、前記監視装置内のハードウェアからの割り込みをマスクして前記ソフトウェアリセットを実行する手段と、前記監視装置内の第２のハードウェアがディセーブル状態であると、前記監視装置のハードウェアリセットが実行された判断して前記揮発性メモリを初期化する手段と、前記第２のハードウェアがイネーブル状態であると、前記ソフトウェアリセットが実行されたと判断して前記揮発性メモリを初期化する手段による初期化をスキップする手段と、前記監視装置の監視機能を実現するための処理を実行するプロセッサプログラムを再起動する手段を有する監視装置が提供される。
【発明の効果】
【００１２】
開示のリセット方法及び監視装置によれば、ハードウェアのリセット機能を使わずに、監視装置をソフトウェアのみでリセット状態に設定することができる。
【図面の簡単な説明】
【００１３】
【図１】本発明の一実施例における監視装置とコンピュータ本体を示すブロック図である。
【図２】サービスプロセッサ内のソフトウェア構成を説明する図である。
【図３】ソフトウェアリセットを説明するフローチャートである。
【図４】サービスプロセッサ内のメモリマップを説明する図である。
【図５】サービスプロセッサの通常動作を説明するフローチャートである。
【図６】Linuxカーネル内の処理を説明するフローチャートである。
【図７】ブートプログラム内の処理を説明するフローチャートである。
【発明を実施するための形態】
【００１４】
開示のリセット方法及び監視装置では、監視装置で異常が発生すると、揮発性メモリに保持されたデータを残したままソフトウェアリセットをかける。監視装置のハードウェアによっては、揮発性メモリに保持されたデータを残したままハードウェアリセットをかけられる機能を有するが、ソフトウェアリセットはこのような機能を有さないハードウェアに対して行われる。
【００１５】
揮発性メモリには、障害発生時に残す障害調査用資料（又は、障害情報）を含むデータの他、監視装置が監視するコンピュータ本体を制御するための制御情報も格納されている。コンピュータ本体を制御するための制御情報は、例えば各種電圧値、ファン回転数等の管理パラメータを含む。監視装置は、一定時間毎に監視装置のハードウェアから障害情報を読み出して異常値に達していないか否かを判定する処理を行う。
【００１６】
これにより、監視装置のハードウェアのリセット機能を使わずに、ソフトウェアリセットのみで監視装置をリセット状態に設定することができる。
【００１７】
以下に、開示のリセット方法及び監視装置の各実施例を図面と共に説明する。
【実施例】
【００１８】
図１は、本発明の一実施例における監視装置とコンピュータ本体を示すブロック図である。監視装置を形成するサービスプロセッサ（ＳＶＰ：Service Processor）１は、図１に示す如く接続されたＭＰＵ（Micro Processor Unit）１１、メモリコントローラ１２、揮発性メモリ１３、不揮発性メモリ１４、及び本体制御インタフェース１５を有する。揮発性メモリ１３は、例えばＳＤＲＡＭ（Synchronous Dynamic Random Access Memory）又はＤＤＲ（Double Data Rate）メモリ等で形成されている。不揮発性メモリ１４は、ＮＯＲ型フラッシュメモリ又はＮＡＮＤ型フラッシュメモリ等で形成されている。本体制御インタフェース１５は、例えばＪＴＡＧインタフェース、Ｉ２Ｃインタフェース、ＬＡＮインタフェース等のハードウェア制御用インタフェースで形成されており、コンピュータ本体２と接続されている。コンピュータ本体２は、例えばＣＰＵとメモリを有する汎用コンピュータで形成されている被監視対象装置である。つまり、コンピュータ本体２は、ＳＶＰ１により監視される。【００１９】
ここでは説明の便宜上、ＳＶＰ１のオペレーティングシステム（ＯＳ：Operating System）はLinux（登録商標）ＯＳであるものとする。又、障害とは、ＳＶＰ１で動作しているLinuxＯＳが例えばパニックリブート（Panic Reboot）を実行するような状況を言うものとする。更に、後述するLinux カーネル（Kernel）は、階層型に設計されたLinuxＯＳの中核となり、コンピュータ本体２のリソースの管理、及びＳＶＰ１のハードウェア（又は、ハードウェアコンポーネント）とソフトウェア（又は、ソフトウェアコンポーネント）のやり取りの管理を行う。【００２０】
図２は、ＳＶＰ１内のソフトウェア構成を説明する図である。ＳＶＰ１内のソフトウェアは、LinuxＯＳに含まれるLinuxカーネル２１、ブートプログラム（Boot Program）２２、及びサービスプロセッサ（ＳＶＰ）プログラム２３を有する。Linuxカーネル２１は、パニックルーチン（Panic Routine）２１１及びマシンチェック割り込みハンドラ２１２を含む。パニックルーチン２１１は、後述するソフトウェアリセットを実行する処理を含む。マシンチェック割り込みハンドラ２１２は、ＳＶＰ１のハードウェアで異常を検出した際もハードウェアリセットを行うことなくマシンチェック割り込みを発生し、パニックルーチン２１１と同様にソフトウェアリセットを行わせる。ブートプログラム２２は、Linuxカーネル２１を揮発性メモリ１３に読み込み実行する。ブートプログラム２２は、診断パターンの書き込みと読み込みを揮発性メモリ１３に対して実行するメモリ診断プログラム２２１を含む。ＳＶＰプログラム２３は、ＳＶＰ１の監視機能を実現するための各種処理を実行する。【００２１】
不揮発性メモリ１４に使用可能なＮＯＲ型フラッシュメモリは、例えば１０万回程度の書き換え回数に上限があり、書き換え動作が遅く高価であるため、大記憶容量のＮＯＲ型フラッシュメモリをＳＶＰ１に搭載することはＳＶＰ１のコストを抑える必要上難しい。そこで、不揮発性メモリ１４に使用可能なＮＯＲ型フラッシュメモリは、主にＳＶＰ１の制御プログラムを格納しておくのに使用する。一方、不揮発性メモリ１４に使用可能なＮＡＮＤ型フラッシュメモリは、安価であるため、大記憶容量のＮＡＮＤ型フラッシュメモリをＳＶＰ１に搭載することが可能である。しかし、不揮発性メモリ１４に使用可能なＮＡＮＤ型フラッシュメモリは、例えば３０００回から１０万回程度の書き換え回数に上限があり、頻繁に書き換えるデータを格納するのには適していない。【００２２】
ＳＶＰ１のLinuxＯＳに含まれるLinuxカーネル２１の中では、ＳＶＰ１のハードウェアを制御する各プログラムが動作している。ＳＶＰ１は、コンピュータ本体２のハードウェアを監視して、コンピュータ本体２のハードウェアから各種電圧値やファン回転数等の管理パラメータを含む制御情報を例えば５秒毎といった一定時間毎に読み込んで揮発性メモリ１３に格納する。【００２３】
ＳＶＰ１は、ＳＤＲＡＭやＤＤＲメモリで形成された揮発性メモリ１３をカーネル管理領域とカーネル管理外領域に分けて使用し、カーネル管理外領域に上記障害調査資料、及び各種電圧値やファン回転数等の管理パラメータを含む制御情報を格納する。図４と共に後述するが、管理パラメータを含む制御情報を格納するのにカーネル管理領域を使用しないのは、以下の理由による。第１に、Linuxカーネル２１は、仮想記憶方式で仮想アドレス空間と物理アドレス空間を変換するための複雑なテーブルを用いた周知の制御を行うからである。第２に、Linuxカーネル２１は、Linuxカーネル２１の起動時に揮発性メモリ１３を初期化するので、カーネル管理外領域に対しては物理アドレスでアクセスすれば良くアクセスの管理が簡単である。このため、揮発性メモリ１３の初期化はブートプログラム２２が行うが、ブートプログラム２２がリブートの時に揮発性メモリ１３を初期化をしないようにブートプログラム２２を変更する方が、Linuxカーネル２１を変更するよりも簡単なためである。【００２４】
ＳＶＰ１において内部矛盾等の異常が発生してＳＶＰ１自身をリブートする場合、Linuxカーネル２１内のパニックルーチン２１１が呼び出される。このパニックルーチン２１１によりＳＶＰ１内（例えば、ＭＰＵ１１内）の周知のハードウェアレジスタ（図示せず）にリセット指示を書き込むことでハードウェアリセットが発生するが、本実施例ではハードウェアリセットが発生しないようにする。つまり、ＳＶＰ１のソフトウェアがＳＶＰ１をリセット状態に制御することで、ハードウェアリセットをかけずにＳＶＰ１のソフトウェアのみにリセットがかかった状態となる。【００２５】
図３は、ソフトウェアリセットを説明するフローチャートである。図３中、ステップＳ１〜Ｓ５は、Linuxカーネル２１内のパニックルーチン２１の処理であり、ステップＳ６〜Ｓ８は、ブートプログラム２２の処理である。【００２６】
ここでは説明の便宜上、揮発性メモリ１３に動作履歴となるトレース（又は、障害調査資料）や、ＳＶＰ１のハードウェアを監視するための各種電圧情報やファン回転数等の管理パラメータを含む制御情報を書き込みながらＳＶＰ１が動作しているものとする。図３において、ＳＶＰ１で内部矛盾等の異常が発生すると、ステップＳ１ではLinuxカーネル２１内のパニックルーチン２１１が呼び出される。【００２７】
ステップＳ２では、Linuxカーネル２１内のパニックルーチン２１１にてＷＤＴ（Watch Dog Timer）等の、ソフトウェアリセット中に誤動作する可能性があるハードウェアをディセーブル（Disable）状態に制御する。ＷＤＴは、プログラムが正常に実行されているか否かを監視するのに用いられるＭＰＵ１１内に設けられた周知のタイマである。【００２８】
ソフトウェアリセット中に、ＷＤＴにより更にリセットがかかってしまっては、ダブルパニックの状態になって正常な動作を行えない。ソフトウェアリセット中は、割り込みを受けても正しく処理できないので、ステップＳ３では、ＳＶＰ１のハードウェアからの割り込みをマスクする割り込みマスク処理を行う。ＳＶＰ１のハードウェアからの割り込みは、ＭＰＵ１１内のＰＩＣ（Programmable Interrupt Controller）の割り込み許可ビットをオフにすることでマスク可能である。ＰＩＣ自体は周知であり、ＭＰＵ１１に対するの割り込みを許可するか否かを制御する。【００２９】
ステップＳ４では、Linuxカーネル２１内のパニックルーチン２１１によりアドレッシングモードを変更するアドレスモード変更処理を行う。通常、Linuxカーネル２１は論理アドレス空間で動作しているが、ステップＳ４ではアドレッシングモードを物理アドレスモードに変更する。物理アドレスモードに変更する理由は、ブートプログラム２２が物理アドレスモードで動作するからである。Linuxカーネル２１も、Linuxカーネル２１自身がＭＰＵ１１内のＭＭＵ（Memory Management Unit）を初期化するまでは、物理アドレスモードで動作する。ＭＭＵ自体は周知であり、ＭＰＵ１１によ揮発性メモリ１３及び不揮発性メモリ１４の利用状況を管理する。【００３０】
図４は、ＳＶＰ１内のメモリマップを説明する図である。図４に示すように、揮発性メモリ１３の揮発性メモリ領域は、カーネル管理領域とカーネル管理外領域に分けられている。カーネル管理領域は、Linuxカーネル２１の論理アドレス空間と、仮想アドレス空間を含む。論理アドレス空間は、text領域、data領域、bss領域等を含む。一方、仮想アドレス空間は、動的組み込みドライバ、ユーザプロセス等を含む。仮想アドレス空間はＭＭＵにより管理され、メモリ領域の確保に使用される基本関数malloc等で割り当てられる。カーネル管理外領域は、障害調査資料、及び管理パラメータを含む制御情報を含む。カーネル管理外領域は、Linuxカーネル２１からはＩ／Ｏ空間に見えるものであり、ＳＶＰ１のリブート時に初期化せずに残す部分である。又、不揮発性メモリ１４の不揮発性メモリ領域には、ブート風呂グラム２２が格納されている。ブートプログラム２２は、Linuxカーネル２１を0x0番地から展開して0x0番地から実行する。【００３１】
カーネル物理アドレス（又は、カーネル領域アドレス）と物理アドレスとの対応は単純であり、論理アドレスから「0xC000_0000」を減算することにより物理アドレスが得られる。しかし、仮想アドレスはLinuxカーネル２１が割り当てるため、1対1では対応しておらず、アドレスを変換するためのテーブルが必要となる。ソフトウェアリセットは、物理アドレスに変換しやすい論理アドレス空間で実行させたいので、この例では、モジュールをLinuxカーベル２１に登録するプログラムinsmodによる動的組み込みには対応しないこととする。アドレスモードの変更は、ＭＰＵ１１内のマシンステートレジスタ（ＭＳＲ：Machine State Register）の内容を変更することによって行う。ＭＳＲ自体は周知であり、ＭＰＵ１１のアドレスモードを示すのに用いるレジスタであり、上記のハードウェアレジスタとは異なる。【００３２】
ステップＳ５では、Linuxカーネル２１内のパニックルーチン２１１により、ＭＰＵ１１内のプロセッサコアが使用するレジスタのみを初期化（即ち、クリア）するレジスタ初期化処理を行う。初期化するレジスタは、非特許文献１のFigure 7-2に示された「e300 Programming Model - Registers」の表からも選定可能である。この例で初期化されるレジスタには、スーパバイザレジスタ（Supervisor Register）が含まれるので、アセンブラで特権命令を使用すれば良い。スーパバイザレジスタ自体は周知であり、ＭＰＵ１１が演算を実行する際に用いるレジスタであり、上記のハードウェアレジスタとは異なる。【００３３】
ステップＳ６では、Linuxカーネル２１からブートプログラム２２の開始アドレスへジャンプする。開始アドレスは、例えば「0xFFF0_0100」であり、ＭＰＵ１１内のプログラムカウンタ（図示せず）のカウントをジャンプさせることで求められる。ブートプログラム２２は、揮発性メモリ１３を初期化する機能を有する。又、ステップＳ６では、ブートプログラム２２は揮発性メモリ１３を初期化する前にメモリコントローラ１２を参照し、メモリコントローラ１２がディセーブル（Disable）状態であるか否かを判定する。メモリコントローラ１２がディセーブル状態でありステップＳ６の判定結果がＹＥＳであると、ハードウェアリセットがかかったと判断して（即ち、ハードウェア初期状態と認識して）処理はステップＳ７へ進む。ステップＳ７では、ブートプログラム２２が揮発性メモリ１３を初期化する初期化処理を行う。【００３４】
一方、メモリコントローラ１２がイネーブル（Enable）状態でありステップＳ６の判定結果がＮＯであると、ブートプログラム２２はソフトウェアリセットがかかった判断してステップＳ７の揮発性メモリ１３の初期化処理と診断処理をスキップする処理を行う。【００３５】
ステップＳ８では、ブートプログラム２２がLinuxカーネル２１を起動し、Linuxカーネル２１は、ＳＶＰプログラム２３を再起動する。再起動されたＳＶＰプログラム２３は、揮発性メモリ１３のカーネル管理外領域にあるデータに再度アクセスする。この場合、カーネル管理外領域にデータが保持されているので、ＳＶＰプログラム２３は初期化やフォーマットを行う必要がなく、直ちに所望のデータをアクセスすることができる。【００３６】
以上により、ＭＰＵ１１のプロセッサコアのみがソフトウェアリセットによりリセットされ、メモリコントローラ１２等の周辺プロセッサはリセットされない状態でソフトウェアのプログラムが最初から実行され、ソフトウェアのみが再起動された状態となる。周辺プロセッサ及び揮発性メモリ１３はリセットされないので、周辺プロセッサ及び揮発性メモリ１３のデータは残ったままとなり、ソフトウェアのリセット後に、再度そのデータにアクセスすることができる。【００３７】
尚、図３のソフトウェアリセットでは、ＳＶＰ１で内部矛盾等の異常が発生すると、ステップＳ１ではLinuxカーネル２１内のパニックルーチン２１１が呼び出される。しかし、ＳＶＰ１内のハードウェアの異常を検出し、ハードウェアリセットではなくマシンチェック割り込みを発生するステップＳ１ＡをステップＳ１の代わりに実行するようにしても良い。つまり、ＳＶＰ１で内部矛盾等の異常が発生した場合に限らず、ＳＶＰ１内のハードウェアの異常を検出した場合にもハードウェアリセットを行わないように、マシンチェック割り込みを発生するようにしても良い。この場合、マシンチェック割り込みハンドラ２１２は、ＳＶＰ１のハードウェアで異常が検出されるとハードウェアリセットを行うことなくマシンチェック割り込みを発生し、パニックルーチン２１１と同様にソフトウェアリセットを行わせる。【００３８】
次に、ＳＶＰ１の通常動作、Linuxカーネル２１内の処理、及びブートプログラム２２の処理の流れを、図５〜図７と共に説明する。図５は、ＳＶＰ１の通常動作を説明するフローチャート、図６は、Linuxカーネル２１内の処理を説明するフローチャート、図７は、ブートプログラム２２内の処理を説明するフローチャートである。【００３９】
図５において、ステップＳＴ１では、ＳＶＰ１は一定時間を待つ処理を実行する。ステップＳＴ２では、ＳＶＰ１はコンピュータ本体２内のハードウェアを監視する処理を実行し、処理はステップＳＴ１へ戻る。これにより、コンピュータ本体２内のハードウェアは、一定時間毎に監視され、障害調査用資料及び制御情報が揮発性メモリ１３に格納される。又、ＳＶＰ１内で内部矛盾等の異常が発生、或いは、ＳＶＰ１内のハードウェアの異常が検出されると、異常通知をLinuxカーネル２１に対して行う。【００４０】
図６のLinuxカーネル２１の処理は、ＳＶＰ１で内部矛盾等の異常が発生、或いは、ＳＶＰ１内のハードウェアの異常が検出されると、ＳＶＰ１からの異常通知に応答して開始される。ステップＳＴ２１では、ＷＤＴ等のソフトウェアリセット中に誤動作する可能性があるハードウェアがイネーブル状態であるか否かを判定する。ステップＳＴ２１の判定結果がＹＥＳであると、ステップＳＴ２２では、ＳＶＰ１のハードウェアからの割り込みをマスクする上記の如き割り込みマスク処理を行う。ステップＳＴ２１の判定結果がＮＯ、或いは、ステップＳＴ２２の後、ステップＳＴ２３では、ＳＶＰ１内のハードウェアの異常が検出されて異常通知としてＳＶＰ１からハードウェア割り込みが発生しているか否かを判定する。ステップＳＴ２３の判定結果がＹＥＳであると、ステップＳＴ２４では、ＳＶＰ１のハードウェアからの割り込みをマスクする上記の如き割り込みマスク処理を行う。ステップＳＴ２３の判定結果がＮＯ、或いは、ステップＳＴ２４の後、ステップＳＴ２５では、Linuxカーネル２１内のパニックルーチン２１１によりアドレッシングモードを変更する。又、ステップＳＴ２６では、Linuxカーネル２１内のパニックルーチン２１１によりＭＰＵ１１内のプロセッサコアが使用するレジスタのみを初期化（即ち、クリア）する上記の如き初期化処理を行う。ステップＳＴ２７では、処理が図７に示すブートプログラム２２の処理へ移行する。【００４１】
図７のブートプログラム２２の処理は、Linuxカーネル２１により起動される。図７において、ステップＳＴ３１では、ブートプログラム２２がLinuxカーネル２１により起動される。ステップＳＴ３２では、ＳＶＰ１のメモリコントローラ１２がディセーブル状態であるか否かを判定する。ステップＳＴ３２の判定結果がＹＥＳであると、ステップＳＴ３３では、揮発性メモリ１３を初期化する上記の如き初期化処理を行い、揮発性メモリ１３内がクリアされる。ステップＳＴ３２の判定結果がＮＯ、或いは、ステップＳＴ３３の後、ステップＳＴ３４では、ＳＶＰプログラム２３が起動される。これにより、起動されたＳＶＰプログラム２３は、揮発性メモリ１３のカーネル管理外領域にある障害調査資料や制御情報等のデータにアクセスすることができる。この場合、カーネル管理外領域にデータが保持されているので、初期化やフォーマットを行う必要がなく、ＳＶＰプログラム２３は直ちに所望のデータをアクセスすることができる。【００４２】
尚、上記実施例では、ＳＶＰ１のＯＳがLinuxＯＳである場合について説明したが、ＯＳはLinuxに限定されるものではないことは言うまでもない。【００４３】
又、本発明は、コンピュータにリセット方法を実行させるプログラム、及びそのようなプログラムを格納したコンピュータ読み取り可能な記憶媒体にも適用可能である。【００４４】
コンピュータ本体を監視して障害調査用資料及び前記コンピュータ本体を制御するための制御情報を含むデータを格納する揮発性メモリを有する監視装置のリセット方法を前記監視装置のプロセッサコアに実行させるコンピュータプログラムは、前記監視装置内で異常が発生すると、前記プロセッサコアはリセットされるが前記揮発性メモリはリセットされないソフトウェアリセット中に誤動作する可能性がある前記監視装置内のハードウェアをディセーブル状態に制御する手順と、前記ハードウェアからの割り込みをマスクして前記プロセッサコアが使用するレジスタのみを初期化する前記ソフトウェアリセットを実行する手順と、前記監視装置のハードウェアリセットがかると前記揮発性メモリを初期化する手順と、前記ハードウェアがイネーブル状態であり前記ソフトウェアリセットがかかると前記揮発性メモリの初期化をスキップする手順と、前記監視装置の監視機能を実現するための処理を実行するプロセッサプログラムを再起動する手順を前記プロセッサコアに実行させるコンピュータプログラムであっても良い。【００４５】
更に、コンピュータ読み取り可能な記憶媒体は、上記コンピュータプログラムをコンピュータ読み取り可能に格納した記憶媒体であれば、記憶媒体の種類は特に限定されない。【００４６】
以上、開示のリセット方法及び監視装置を実施例により説明したが、本発明は上記実施例に限定されるものではなく、本発明の範囲内で種々の変形及び改良が可能であることは言うまでもない。
【符号の説明】
【００４７】
１      ＳＶＰ
２      コンピュータ本体
１１      ＭＰＵ
１２      メモリコントローラ
１３      揮発性メモリ
１４      不揮発性メモリ
１５      本体制御インタフェース
２１      Linuxカーネル
２２      ブートプログラム
２３      ＳＶＰプログラム
２１１        パニックルーチン
２１２      マシンチェック割り込みハンドラ
２２１      メモリ診断プログラム
【図１】
0005418597.tif 000002
【図２】
0005418597.tif 000003
【図３】
0005418597.tif 000004
【図４】
0005418597.tif 000005
【図５】
0005418597.tif 000006
【図６】
0005418597.tif 000007
【図７】
0005418597.tif 000008