(57)【要約】【課題】確実にＲＡＩＤコントローラを復旧できる制御方法を提供する。【解決手段】制御システムは、ＲＡＩＤコントローラが動作不能な状態であることを検出する検出部と、前記検出部が、前記ＲＡＩＤコントローラが動作不能な状態であることを検出すると、前記ＲＡＩＤコントローラへのバスリセット信号の発行を指示する外部リセット指示部と、を備える。【選択図】図６
2019164578.tif 000002
【特許請求の範囲】
【請求項１】
ＲＡＩＤコントローラが動作不能な状態であることを検出する検出部と、
前記検出部が、前記ＲＡＩＤコントローラが動作不能な状態であることを検出すると、前記ＲＡＩＤコントローラが接続されたバスへのバスリセット信号の発行を指示する外部リセット指示部と、
を備える制御システム。
【請求項２】
前記検出部は、前記ＲＡＩＤコントローラが記憶するデータおよび前記ＲＡＩＤコントローラのファームウェアを初期化する内部リセット処理を実行してから所定の時間が経過しても、前記ＲＡＩＤコントローラから前記内部リセット処理の完了の応答が無い場合、前記ＲＡＩＤコントローラが動作不能な状態であると判定する、
請求項１に記載の制御システム。
【請求項３】
前記内部リセット処理を実行する内部リセット処理部、
をさらに備え、
前記内部リセット処理部は、前記ＲＡＩＤコントローラに対してＩＯ処理の命令を発行してから所定の時間が経過しても、前記ＩＯ処理の完了の応答が無い場合、前記内部リセット処理を実行する、
請求項２に記載の制御システム。
【請求項４】
前記外部リセット指示部による前記バスリセット信号の発行の指示に基づいて、前記ＲＡＩＤコントローラに接続された所定のバスを通じて前記バスリセット信号を発行する個別バスリセット処理部、
をさらに備える請求項１から請求項３の何れか１項に記載の制御システム。
【請求項５】
ＲＡＩＤコントローラと前記バスリセット信号を送受信するバスで接続されたバスコントローラと、
前記ＲＡＩＤコントローラを制御するデバイスドライバと、
前記バスコントローラを制御するオペレーティングシステムと、
を備え、
前記デバイスドライバが、前記検出部を備え、
前記オペレーティングシステムが、前記外部リセット指示部を備え、
請求項１から請求項４の何れか１項に記載の制御システム。
【請求項６】
ＲＡＩＤコントローラと、
前記ＲＡＩＤコントローラが接続されたバスと、
請求項１から請求項４の何れか１項に記載の制御システムと、
を備え、
前記制御システムがソフトウェアで構成される、情報処理装置。
【請求項７】
ＲＡＩＤコントローラと、
前記ＲＡＩＤコントローラの動作を制御するデバイスドライバと
前記ＲＡＩＤコントローラが接続されたバスを制御するバスコントローラと、
前記バスコントローラを制御するオペレーティングシステムと、
請求項５に記載の制御システムと、
を備える情報処理装置。
【請求項８】
ＲＡＩＤコントローラが動作不能な状態であることを検出するステップと、
前記ＲＡＩＤコントローラが動作不能な状態であることが検出されると、前記ＲＡＩＤコントローラが接続されたバスへのバスリセット信号の発行を指示するステップと、
を有する制御方法。
【請求項９】
オペレーティングシステムの稼働中にＲＡＩＤコントローラの応答遅れを検出すると、
前記ＲＡＩＤコントローラが記憶するデータおよび前記ＲＡＩＤコントローラのファームウェアの初期化を実行し、
前記初期化が失敗した場合、前記オペレーティングシステムを稼働したまま、前記ＲＡＩＤコントローラについて、ハードウェアの初期化処理を実行する、
ＲＡＩＤコントローラの復旧方法。
【請求項１０】
コンピュータを、
ＲＡＩＤコントローラが動作不能な状態であることを検出する手段、
前記ＲＡＩＤコントローラが動作不能な状態であることが検出されると、前記ＲＡＩＤコントローラが接続されたバスへのバスリセット信号の発行を指示する手段、
として機能させるためのプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、制御システム、情報処理装置、制御方法、ＲＡＩＤコントローラの復旧方法及びプログラムに関する。
【背景技術】
【０００２】
ハードディスクの故障によるデータの損失防止や入出力処理の性能向上のためにＲＡＩＤ（Redundant Array of Inexpensive Disks）技術が用いられる。ＲＡＩＤを適用した一般的なシステムについて、図８を用いて説明する。図８に示す情報処理装置１００Ａは、ＩＯコントローラとしてＲＡＩＤコントローラ３を備えている。ＲＡＩＤコントローラ３は、ファームウェア３１とコントローラチップ３２を備えている。ファームウェア３１は、ＲＡＩＤ技術に必要な機能を有したソフトウェアである。ファームウェア３１は、コントローラチップ３２の動作を制御する。コントローラチップ３２は、ＲＡＩＤコントローラ３のＩＯ処理を実行する。ＲＡＩＤコントローラ３には、ＨＤＤ（ハードディスク）３３〜３５が接続されている。ＨＤＤ３３〜３５は、データの冗長性を補償する1つの論理ディスクを構成している。
【０００３】
ＯＳ（operating system）１は、オペレーティングシステムである。ＯＳ１は、情報処理装置１００Ａで実行されるアプリケーション等の発行するＩＯ命令を実行し、ＨＤＤ（hard disk drive）３３〜３５で構成される論理ディスクへの書き込みや読み出しを実行する。ドライバ４は、ＯＳ１上で稼働するＲＡＩＤコントローラ３のデバイスドライバである。ＯＳ１およびドライバ４はソフトウェアである。ＯＳ１およびドライバ４は、情報処理装置１００Ａが備えるＣＰＵ（central processing unit）５がＯＳ１、ドライバ４に対応するプログラムを論理ディスクから読み出して実行することにより、その機能を発揮する。
【０００４】
ドライバ４は、ストール監視タイマ４１と、内部リセット処理部４２とを備える。ストール監視タイマ４１は、ＩＯ命令を実行する際にタイマを起動させて、所定の時間内にＲＡＩＤコントローラ３から応答が返ってくるかどうかを監視する。所定の時間内に応答がない場合、ＲＡＩＤコントローラ３が動作不能に陥ったことを意味する。内部リセット処理部４２は、ＲＡＩＤコントローラ３から所定の時間内に応答が返ってこない場合、コントローラチップ３２を直接制御して、コントローラチップ３２のリセットを行う。この処理を、内部リセット処理と呼ぶ。内部リセット処理部４２がコントローラチップ３２に対し内部リセット処理を実行すると、コントローラチップ３２は、初期化され、動作を再開する。すなわち、内部リセット処理部４２は、ＲＡＩＤコントローラ３が動作不能に陥った場合の復旧の機能を備える。
【０００５】
次にＩＯ処理の流れについて説明する。情報処理装置１００Ａにおいて、ＯＳ１がＩＯ命令を発行すると、ドライバ４がそのＩＯ命令を受け取る。ドライバ４は当該ＩＯ命令を、ファームウェア３１に出力してＩＯの実行を要求する。その際、ストール監視タイマ４１は、タイマを起動して要求したＩＯに対する応答が、所定の時間内に返ってくるか否か監視を行う。正常時、ファームウェア３１はＩＯを処理し、所定時間以内にドライバ４に応答を返す。この場合、ストール監視タイマ４１の時間監視は正常に終了する。しかし、ＲＡＩＤコントローラ３に何らかの予期せぬ事態が発生した場合、ファームウェア３１は、ＩＯ処理を実行できずにドライバ４に対して応答できない状態となる。この状態をストール状態という。この場合、ドライバ４は、ＲＡＩＤコントローラ３からの応答を待ち続ける。しかし、ストール監視タイマ４１が監視する所定時間を経過してもドライバ４は応答を受け取ることがない。このような状態になるとドライバ４は、ファームウェア３１が動作不能の状態に陥っていると判定する。すると、内部リセット処理部４２は、内部リセット処理を実行し、ＲＡＩＤコントローラ３の復旧を試みる。
【０００６】
内部リセット処理が実行されると、ＲＡＩＤコントローラ３のレジスタやキャッシュに残るデータが初期化される。これにより、ファームウェア３１を含めＲＡＩＤコントローラ３がリセットされる。通常であれば、ＲＡＩＤコントローラ３の内部リセット処理は正常に完了し、ＩＯ処理が正常に実行できる状態に復旧する。すると、ドライバ４は、応答なしとなったＩＯ要求のリトライ等を行う。すると、ＩＯ処理が再開し、当該ＩＯ命令が正常に実行される。これにより、情報処理装置１００は、正常稼働を継続することができる。
【０００７】
関連する技術として、特許文献１には、ＯＳからディスクアレイの制御装置のデバイスドライバに対して、ハード的に初期化するリセット指示が発行されると、デバイスドライバがそのリセット信号をソフトウェア的なリセットコマンドに変換してディスクアレイの制御装置のファームウェアに送信するディスクアレイの制御方法について記載がある。特許文献１に記載の制御方法によると、ファームウェアのキャッシュ等が記憶するデータを消滅させることなくディスクアレイ制御装置のリセットが可能となる。
【０００８】
また、特許文献２には、汎用的なインタフェースで接続されたホスト機器とデバイス機器の各々に専用インタフェース回路を設け、それらの専用インタフェース回路間を専用線で接続する制御システムが記載されている。この制御システムでは、例えば、デバイス機器がハングアップすると、ホスト機器からデバイス機器へ、専用線を通じてリセット信号を発行し、デバイス機器を再起動させる。
【０００９】
また、特許文献３には、ネットワークシステムにおいて、動作が停止している機器に対してリセット信号を送信し、その機器を復旧させるネットワーク接続装置について記載がある。
【先行技術文献】
【特許文献】
【００１０】
【特許文献１】特開２００１−１０９５８８号公報
【特許文献２】特開２００３−１３１９５６号公報
【特許文献３】特開２００４−１９３８６５号公報
【発明の概要】
【発明が解決しようとする課題】
【００１１】
通常は、ＲＡＩＤコントローラ３がストール状態に陥っても、内部リセット処理の実行により、正常な状態に復旧する。ところが、内部リセット処理部４２が、内部リセット処理を実行しても、ＲＡＩＤコントローラ３を正常に復旧できない場合がある。この場合、ドライバ４は、ＲＡＩＤコントローラ３の復旧を待機し続けることになり、待ち状態から抜けられない。この状態になると、情報処理装置１００は、ＯＳ１からのＩＯ命令が処理できない。例えば、当該ＩＯ命令がオペレーティングシステムとして中核部分の処理に関するものであったとすると、システム自体がストール状態となり、システム運用に大きな支障をきたす可能性がある。
特許文献１〜３には内部リセット処理が失敗したときに、ＲＡＩＤコントローラを復旧させる技術は開示されていない。
【００１２】
そこでこの発明は、上述の課題を解決する制御システム、情報処理装置、制御方法、ＲＡＩＤコントローラの復旧方法及びプログラムを提供することを目的としている。
【課題を解決するための手段】
【００１３】
本発明の一態様によれば、ＲＡＩＤコントローラが動作不能な状態であることを検出する検出部と、前記検出部が、前記ＲＡＩＤコントローラが動作不能な状態であることを検出すると、前記ＲＡＩＤコントローラが接続されたバスへのバスリセット信号の発行を指示する外部リセット指示部と、を備える制御システムである。
【００１４】
本発明の一態様によれば、ＲＡＩＤコントローラと、前記ＲＡＩＤコントローラが接続されたバスと、上記の制御システムと、を備え、前記制御システムがソフトウェアで構成される、情報処理装置である。
【００１５】
本発明の一態様によれば、ＲＡＩＤコントローラが動作不能な状態であることを検出するステップと、前記ＲＡＩＤコントローラが動作不能な状態であることが検出されると、前記ＲＡＩＤコントローラが接続されたバスへのバスリセット信号の発行を指示するステップと、を有する制御方法である。
【００１６】
本発明の一態様によれば、オペレーティングシステムの稼働中にＲＡＩＤコントローラの応答遅れを検出すると、前記ＲＡＩＤコントローラが記憶するデータおよび前記ＲＡＩＤコントローラのファームウェアの初期化を実行し、前記初期化が失敗した場合、前記オペレーティングシステムを稼働したまま、前記ＲＡＩＤコントローラについて、ハードウェアの初期化処理を実行する、ＲＡＩＤコントローラの復旧方法である。
【００１７】
本発明の一態様によれば、コンピュータを、ＲＡＩＤコントローラが動作不能な状態であることを検出する手段、前記ＲＡＩＤコントローラが動作不能な状態であることが検出されると、前記ＲＡＩＤコントローラが接続されたバスへのバスリセット信号の発行を指示する手段、として機能させるためのプログラムである。
【発明の効果】
【００１８】
本発明の制御システム、情報処理装置、制御方法及びプログラムによれば、ＲＡＩＤコントローラを確実に復旧することができる。
【図面の簡単な説明】
【００１９】
【図１】本発明の一実施形態による情報処理装置の構成の一例を示す図である。
【図２】本発明の一実施形態によるＩＯ処理の流れを説明する第１の図である。
【図３】本発明の一実施形態によるＩＯ処理の流れを説明する第２の図である。
【図４】本発明の一実施形態によるＩＯ処理の流れを説明する第３の図である。
【図５】本発明の一実施形態によるＩＯ処理の流れを説明する第４の図である。
【図６】本発明の一実施形態による制御システムの最小構成を示す図である。
【図７】本発明の一実施形態による情報処理装置の最小構成を示す図である。
【図８】一般的な情報処理装置の構成の一例を示す図である。
【図９】一般的なＩＯ処理において内部リセット処理に失敗した場合の処理の流れを説明する図である。
【発明を実施するための形態】
【００２０】
＜実施形態＞
以下、本発明のＲＡＩＤコントローラの制御システムを備える情報処理装置について図１〜図７を参照して説明する。
図１は、本発明の一実施形態による情報処理装置の構成の一例を示す図である。
情報処理装置１００は、図１に示すようにＯＳ１と、バス制御部２と、ＲＡＩＤコントローラ３と、ＨＤＤ３３〜３５と、ドライバ４と、ＣＰＵ５を備える。図８を参照して説明した構成については、説明を省略する。
ＯＳ１は、オペレーティングシステムである。ＯＳ１は、情報処理装置１００で実行されるアプリケーション等の発行するＩＯ命令を実行し、ＨＤＤ３３〜３５で構成される論理ディスクへの書き込みや読み出しを実行する。ＯＳ１は、バスリセット指示部１１を備える。バスリセット指示部１１は、ＲＡＩＤコントローラ３が接続されているバスをリセットするバスリセット信号の発行を、当該バスを制御するバス制御部２へ指示する。
【００２１】
バス制御部２は、情報処理装置１００の内部バスを制御する。バス制御部２は、例えばＰＣＩ Ｅｘｐｒｅｓｓコントローラである。バス制御部２は、個別バスリセット処理部２１を備えている。個別バスリセット処理部２１は、指定されたバスを個別にリセットすることができる。バスの個別リセットは、当該バスに接続されたコントローラをハードウェアごとリセットすることを意味する。ドライバ４による内部リセット処理が、ＲＡＩＤコントローラ３を制御するソフトウェアによるＲＡＩＤコントローラ３の内部的な状態を初期化する処理（ＲＡＩＤコントローラ３が記憶するレジスタやキャッシュのデータの初期化、ファームウェア３１の初期化など）であるのに対し、バスリセットは、ＲＡＩＤコントローラ３の外部からのリセット命令である。バスリセット信号が発行されると、ＲＡＩＤコントローラ３自体が再起動する。本実施形態では、内部リセット処理でＲＡＩＤコントローラが復旧できないときに外部的なリセット信号であるバスリセット信号が発行してＲＡＩＤコントローラ３を復旧させる。バス制御部２は、専用バス２２を介してＲＡＩＤコントローラ３のバスＩ／Ｆ（インタフェース）３６に接続されている。個別バスリセット処理部２１が、バスＩ／Ｆ３６に対してバスリセット信号を発行すると、ＲＡＩＤコントローラ３が電源投入時と同様のプロセスを経て初期化される。なお、専用バス２２やバスＩ／Ｆ３６は、物理的にはもともと存在するものであって、本実施形態のバスリセット信号の通信のために新たに設けられたものでは無い。バス制御部２は、個々のバスにバスリセット信号を発行する機能を備えており、専用バス２２やバスＩ／Ｆ３６は、バス制御部２の機能に基づき、それぞれバスリセット信号用のバスおよびインタフェースとして設定されている。
【００２２】
ＲＡＩＤコントローラ３は、ファームウェア３１と、コントローラチップ３２と、を備える。ＲＡＩＤコントローラ３には、ＨＤＤ３３〜３５が接続されており、これらのディスクでＲＡＩＤが組まれ、１つの論理ディスクを構成している。
【００２３】
ドライバ４は、ストール監視タイマ４１と、内部リセット処理部４２と、外部リセット要求部４３と、を備える。ストール監視タイマ４１は、ＩＯ要求に対するＲＡＩＤコントローラ３からの応答時間を監視する。内部リセット処理部４２は、ＩＯ要求に対する応答が遅れたときに内部リセット処理を実行する。外部リセット要求部４３は、内部リセット処理が失敗したときに、バス制御部２からバスＩ／Ｆ３６へバスリセット信号の発行するようにＯＳ１に要求する。
【００２４】
外部リセット要求部４３がバスリセット信号の発行を要求すると、ＯＳ１のバスリセット指示部１１が、バスリセット信号の発行をバス制御部２へ指示する。この指示に基づいて、バス制御部２の個別バスリセット処理部２１が専用バス２２上にバスリセット信号を発生させる。ＲＡＩＤコントローラ３は、専用バス２２からバスリセット信号を受けたことにより、ハードウェアを含めた全ての初期化をはじめから行う。バスリセット信号による初期化処理を、外部リセット処理と呼ぶ。外部リセット処理により、ＲＡＩＤコントローラ３が復旧する。ドライバ４は、ＲＡＩＤコントローラ３の復旧後にＩＯ処理を再開する。これにより、情報処理装置１００上で稼働するシステムの動作中に、当該システムの再起動を行うことなく、ＲＡＩＤコントローラ３を復旧させることができる。
【００２５】
次に図２〜図６を用いて、情報処理装置１００におけるＲＡＩＤコントローラ３の制御方法について説明する。
（正常処理）
まず、ＩＯ処理の正常動作について図２を用いて説明する。
図２は、本発明の一実施形態によるＩＯ処理の流れを説明する第１の図である。
まず、ＯＳ１が、ＩＯ命令の実行をドライバ４に対して要求する（ステップ３０１）。ＯＳ１は、ドライバ４からＩＯ命令完了を知らせる応答が届くのを待機する（ステップ３０２）。ドライバ４は、ＯＳ１からＩＯ命令を受信する（ステップ３０３）。すると、ストール監視タイマ４１が、タイマを起動し、当該ＩＯ命令に対する応答が所定の時間内にＲＡＩＤコントローラ３から返されるか時間監視を開始する（ステップ３０４）。一例として、本実施形態では応答を待機する所定時間を１分間と設定する。１分間の間にＲＡＩＤコントローラ３から応答がない場合、ドライバ４はＲＡＩＤコントローラ３が処理不能に陥っていると判定する。
【００２６】
タイマを起動すると、ドライバ４は、ＯＳ１から受信したＩＯ命令について、ＲＡＩＤコントローラ３上で動作しているファームウェア３１にＩＯを要求する発行を行う（ステップ３０５）。ドライバ４は、発行したＩＯが完了したことを示すファームウェア３１からの応答を待機する（ステップ３０６）。
【００２７】
ＲＡＩＤコントローラ３では、ファームウェア３１が、ＩＯの要求を受信する（ステップ３０７）。次にファームウェア３１が、受信したＩＯ処理を行う（ステップ３０８）。ＩＯの実行が完了すると、ファームウェア３１は、ドライバ4に対してＩＯ完了の応答を行う（ステップ３０９）。
【００２８】
ドライバ４は、ファームウェア３１からの応答を受信する（ステップ３１０）。ドライバ４は、後処理等を実行してドライバ４内でのＩＯ処理を完了させる。ＩＯ処理が完了すると、ドライバ４は、ＯＳ１にＩＯ完了の応答を行う（ステップ３１１）。ＯＳ１は、ドライバ４からＩＯ完了の応答を受信する（ステップ３１２）。応答を受信すると、ＩＯ命令の実行は完了となる（ステップ３１３）。
【００２９】
（復旧処理）
次にＲＡＩＤコントローラ３にてＩＯ処理を正常に処理できなった場合の復旧処理について図３を用いて説明する。
図３は、本発明の一実施形態によるＩＯ処理の流れを説明する第２の図である。
ステップ４０１〜ステップ４０８の処理の流れは、図２におけるステップ３０１〜ステップ３０８の動作の流れと同じである。
まず、ＯＳ１が、ＩＯ命令の実行をドライバ４に要求する（ステップ４０１）。ＯＳ１は、ドライバ４からの応答を待つ（ステップ４０２）。ドライバ４は、ＯＳ１からＩＯ命令を受信する（ステップ４０３）。すると、ストール監視タイマ４１が、タイマを起動し、ＩＯ命令に対する応答が返されるまでの時間監視を開始する（ステップ４０４）。ドライバ４は、ＯＳ１からのＩＯ命令に基づいて、ファームウェア３１にＩＯ発行を行う（ステップ４０５）。ドライバ４は、ファームウェア３１からの応答を待機する（ステップ４０６）。一方、ファームウェア３１は、ＩＯ発行を受信（ステップ４０７）し、ＩＯ処理を行う（ステップ４０８）。
【００３０】
ここで、何らかの要因にてＲＡＩＤコントローラ３がＩＯを処理できない状態に陥ったとする（ステップ４０９）。すると、ファームウェア３１は、ＩＯ処理を正常に完了することができない。すなわち、ファームウェア３１は、ドライバ４にＩＯ完了の応答を返すことができない状態に陥る。
【００３１】
一方、ドライバ４では、ステップ４０６の応答待ちの状態が継続する。タイマの起動から１分間が経過すると、タイマがタイムアウトする。するとドライバ４は、ＲＡＩＤコントローラ３が動作不能に陥ったと判定する。ドライバ４は、内部リセット処理部４２に制御を渡し、内部リセット処理の実行を指示する。内部リセット処理部４２は、ＲＡＩＤコントローラ３に搭載されているコントローラチップ３２を直接制御することでコントローラチップ３２のリセット（内部リセット）を行う（ステップ４１１）。その後、ドライバ４は、ＲＡＩＤコントローラ３が再初期化されて復旧するのを待つ（ステップ４１２）。ＲＡＩＤコントローラ３では、コントローラチップ３２に対してリセットが実行される（ステップ４１３）。また、ファームウェア３１の初期化が開始される（ステップ４１４）。ファームウェア３１の初期化処理が全て完了すると（ステップ４１５）、ＲＡＩＤコントローラ３は、ＩＯ処理を実行できる正常な状態に復旧する。ＲＡＩＤコントローラ３は、初期化の完了（内部リセット処理の完了）をドライバ４に応答する。
【００３２】
すると、ドライバ４が、ＲＡＩＤコントローラ３の復旧を認識する（ステップ４１６）。次にドライバ４は、処理ができなかったＩＯ命令を再開するために、再度、ファームウェア３１にステップ４０５と同様のＩＯ発行を行う（ステップ４１７）。ドライバ４は、再発行したＩＯに対する応答を待機する（ステップ４１８）。
【００３３】
ＲＡＩＤコントローラ３では、ファームウェア３１が、再発行されたＩＯの要求を受信する（ステップ４１９）。ファームウェア３１は、受信したＩＯ処理を行う（ステップ４２０）。ＩＯ処理が完了すると、ファームウェア３１は、ドライバ４にＩＯ完了の応答を行う（ステップ４２１）。
【００３４】
ドライバ４は、ファームウェア３１からの応答を受信する（ステップ４２２）。ドライバ４は、後処理等を実行してドライバ４内でのＩＯ処理を完了させる（ステップ４２３）。ＩＯ処理が完了すると、ドライバ４は、ＯＳ１にＩＯ命令完了の応答を行う。ＯＳ１は、ドライバ４から応答を受信する（ステップ４２４）。応答を受信すると、ＩＯ命令の実行は完了となる（ステップ４２５）。
【００３５】
図３のフローチャートに示す処理により、ＲＡＩＤコントローラ３が動作不能に陥ってＩＯ処理が滞った場合にも、ＲＡＩＤコントローラ３を復旧させることができる。これにより、ＩＯ命令を継続して処理し、情報処理装置１００のシステムストールを回避することができる。
【００３６】
（内部リセット失敗時）
次にＲＡＩＤコントローラ３にて内部リセット処理を正常に完了できなった場合の処理について説明する。
比較のためにまず、図９を用いて、一般的なＩＯ処理において内部リセット処理に異常が生じた場合の処理の流れを説明する。
図９に示すステップ５０１〜ステップ５１３までの処理の流れは、図３に示すフローチャートにおけるステップ４０１〜ステップ４１３までの動作の流れと同じである。つまり、ステップ５１３にて、ＲＡＩＤコントローラ３では、コントローラチップ３２に対して内部リセットが実行され、ステップ５１４にてファームウェア３１の初期化処理が開始される。しかし、初期化処理が何等かの要因により正常に動作できないことがある。すると、ＲＡＩＤコントローラ３は、動作不能状態に陥る（ステップＳ５１５）。この場合、ドライバ４では、ＲＡＩＤコントローラ３の復旧待ちの状態が継続する（ステップ５１２）。ＯＳ１についても、ステップ５０１で要求したＩＯ命令は完了せず、ＯＳ１は、ドライバ４からの応答を待ち続ける状態となる。図９で説明するのは、１つのＩＯ命令に関する動作であるが、ＯＳ１が複数のＩＯ命令の実行要求を出している場合、要求されたすべてのＩＯ命令が、応答待ちのまま完了しない状態になる。例えば、そのＩＯ命令がＯＳ１の中核処理を担う場合、システムの処理が停止し、システムストールを招く(ステップ５１６)。
【００３７】
これに対し、本実施形態では、ＲＡＩＤコントローラ３に対する内部リセットが失敗した場合、ＲＡＩＤコントローラ３の接続を制御するバス制御部２からバスリセット信号を発行し、ＲＡＩＤコントローラ３に対してハードウェアの初期化処理が実行されるようにする。ＲＡＩＤコントローラ３に対するハードウェアの初期化処理とは、例えば、情報処理装置１００に電源が投入されたときにＲＡＩＤコントローラ３について実行される初期化処理と同様の処理である。
【００３８】
次に本実施形態における内部リセット処理の失敗時におけるＲＡＩＤコントローラ３の復旧処理について図４，５を用いて説明する。
図４は、本発明の一実施形態によるＩＯ処理の流れを説明する第３の図である。
図４〜図５のフローチャートでは、ＯＳ１、ドライバ４、ＲＡＩＤコントローラ３に加え、ＲＡＩＤコントローラ３のバスＩ／Ｆ３６の処理が加わる。上記のとおりバスＩ／Ｆ３６は、ＲＡＩＤコントローラ３が備えるバスＩ／Ｆのうち、バスリセット信号の受信用に設定されたインタフェースである。また、専用バス２２は、ＲＡＩＤコントローラ３とバス制御部２との間のバスのうち、バスリセット信号の送信用に設定されたバスである。これらは、本実施形態の外部リセット処理のために追加されたハードウェアではない。
【００３９】
ステップ６０１からステップ６１０までの動作の流れは、図３のフローチャートにおけるステップ５０１からステップ４１０までの動作の流れと同じである。
まず、ＯＳ１が、ＩＯ命令の実行をドライバ４に要求する（ステップ６０１）。ＯＳ１は、ドライバ４からのＩＯ完了の応答を待つ（ステップ６０２）。ドライバ４は、ＯＳ１からＩＯ命令を受信する（ステップ６０３）。ＩＯ命令を受信すると、ストール監視タイマ４１は、タイマを起動する（ステップ６０４）。ドライバ４は、ファームウェア３１にＩＯ発行を行う（ステップ６０５）。ドライバ４は、ファームウェア３１からのＩＯ完了の応答を待機する（ステップ６０６）。この間、ストール監視タイマ４１は、タイマの起動から応答までの時間を監視する。ファームウェア３１は、ＩＯの要求を受信（ステップ６０７）し、ＩＯ処理を行う（ステップ６０８）。ここで、ＲＡＩＤコントローラ３がＩＯ命令を処理できない状態に陥るとする（ステップ６０９）。すると、ドライバ４では、ストール監視タイマ４１による時間監視開始からの経過時間が所定時間（例えば１分）を超え、タイムアウトする（ステップS６１０）。
【００４０】
次に本実施形態では、内部リセット処理の実行前に、内部リセット処理が正常に終了するかどうかを監視するために、ストール監視タイマ４１がタイマを起動して時間監視を行う。例えば、ストール監視タイマ４１は、タイムアウトまでの時間に２分間を設定して、タイマを起動する（ステップS６１１）。なお、ファームウェア３１から内部リセット処理完了の応答が２分以内に通知されなかった場合、ドライバ４は、ＲＡＩＤコントローラ３の内部リセット処理が失敗したと判定する。次にドライバ４は、内部リセット処理部４２に制御を渡し、内部リセットの実行を指示する。内部リセット処理部４２は、コントローラチップ３２に対して内部リセット処理を実行する（ステップ６１２）。ドライバ４は、ＲＡＩＤコントローラ３が初期化されて復旧するのを待つ（ステップ６１３）。ＲＡＩＤコントローラ３では、コントローラチップ３２に対してリセットが実行される（ステップ６１４）。すると、ファームウェア３１の初期化が開始される（ステップ６１５）。
【００４１】
ここで、ＲＡＩＤコントローラ３が、動作不能な状態に陥るとする（ステップＳ６１６）。ドライバ４では、ＲＡＩＤコントローラ３の復旧待ちの状態が継続する（ステップ６１３）。やがて２分が経過し、タイマはタイムアウトする（ステップ６１７）。するとドライバ４は、ＲＡＩＤコントローラ３の内部リセット処理による復旧が失敗したと判定する。内部リセット処理が失敗したと判定すると、次にドライバ４は、外部リセット要求部４３に制御を渡し、バスリセット信号の発行を要求するように指示する。外部リセット要求部４３は、ＯＳ１の個別バスリセット処理部２１に、ＲＡＩＤコントローラ３に接続されているバスをリセットするよう要求（外部リセット要求）する（ステップ６１８）。
【００４２】
ＯＳ１では、個別バスリセット処理部２１が外部リセット要求を受信する。個別バスリセット処理部２１は、外部リセット要求部４３からの外部リセット要求に基づいて、バス制御部２が備える個別バスリセット処理部２１に対し、外部リセット要求部４３から要求されたコントローラ、すなわち、本実施形態ではＲＡＩＤコントローラ３が実装されるバスに対するリセットを要求する、バスリセット要求信号を出力する（ステップ６１９）。個別バスリセット処理部２１は、バスリセット要求信号を受信し、指定されたバス（専用バス２２）に対してバスリセット信号を発行する（ステップ６２０）。すると、ＲＡＩＤコントローラ３は、バスＩ／Ｆ３６を通して、バスリセット信号を受信する（ステップ６２１）。
【００４３】
続いて図５の説明に移る。図５は、本発明の一実施形態によるＩＯ処理の流れを説明する第４の図である。
バスリセット信号を受信すると、電源投入時と同等の初期化処理が開始される。例えば、ＲＡＩＤコントローラ３自体の初期化（ハードウェアの初期化）およびファームウェア３１の初期化が実行される（ステップ６２２）。ＲＡＩＤコントローラ３およびファームウェア３１の初期化が正常に終了すると、ＲＡＩＤコントローラ３の初期化が完了する（ステップ６２３）。このとき、ＲＡＩＤコントローラ３は、ＩＯ処理を正常に実行できる状態に復旧している。ファームウェア３１は、ドライバ４に初期化の完了（外部リセット処理の完了）を応答する。
【００４４】
ドライバ４は、この応答を受信し、ＲＡＩＤコントローラ３の復旧を認識する（ステップ６２４）。次にドライバ４は、処理ができなかったＩＯ命令を再開するために再度、ファームウェア３１にステップＳ６０５と同様のＩＯを再発行する（ステップ６２５）。ドライバ４は、再発行したＩＯに対する応答を待機する（ステップ６２６）。
【００４５】
ＲＡＩＤコントローラ３では、ファームウェア３１が、ＩＯの要求を受信する（ステップ６２７）。ファームウェア３１は、受信したＩＯを処理する（ステップ６２８）。ＩＯ処理が完了すると、ファームウェア３１は、ドライバ４へＩＯ完了を応答する（ステップ６２９）。
【００４６】
ドライバ４は、ファームウェア３１から応答を受信する（ステップ６３０）。ドライバ４は、後処理等を実行してドライバ４内でのＩＯ処理を完了させる。ＩＯ処理が完了すると、ドライバ４は、ＯＳ１にＩＯ完了を応答する（ステップ６３１）。ＯＳ１は、ドライバ４からＩＯ完了の応答を受信する（ステップ６３２）。応答を受信すると、ＩＯ命令の実行は完了となる（ステップ６３３）。
【００４７】
上記のように本実施形態によれば、ＲＡＩＤコントローラ３が動作不能となり、さらにソフトウェア的な初期化（内部リセット処理）を行っても、ＲＡＩＤコントローラ３が復旧することができず、完全に制御を失った場合でも、ＲＡＩＤコントローラ３をハードウェアレベルで初期化する外部リセット処理を実行することができる。これにより、ＲＡＩＤコントローラ３を確実に復旧させることができる。また、システムストールを回避して、システムの運用を維持することができる。また、外部リセット処理は、ＯＳ１の稼働中に、システム（情報処理装置１００で稼働するＯＳ１等）の再起動を行うことなく実行することができるため、システムの稼働を継続することができる。
【００４８】
また、上記のように本実施形態の外部リセット処理は、ＲＡＩＤコントローラ３が接続されているバスＩ／Ｆ３６からのリセット指示の入力、すなわち、外部からのリセット指示の入力をソフトウェア的に駆動する。外部リセット処理の実行には、新たなハードウェアの追加は必要ではなく、外部リセット要求部４３のドライバ４への実装、バスリセット指示部１１のＯＳ１への実装、を追加し、バス制御部２（個別バスリセット処理部２１）が連携して動作するように適切な設定を行うだけで実現が可能である。
【００４９】
図６は、本発明の一実施形態による制御システムの最小構成を示す図である。
図６に示すように制御システム１０は、少なくとも検出部１０１と、外部リセット指示部１０２とを備える。
検出部１０１は、ＲＡＩＤコントローラが動作不能な状態であることを検出する。
外部リセット指示部１０２は、検出部１０１が、ＲＡＩＤコントローラが動作不能な状態であることを検出すると、ＲＡＩＤコントローラが接続されたバスへのバスリセット信号の発行を指示する。バスリセット信号とは、ＲＡＩＤコントローラの動作を制御するデバイスドライバを介さずに、ＲＡＩＤコントローラが接続されたバスのバスコントローラによって発行されるリセット信号である。バスリセット信号が発行されると、当該バスに接続されたコントローラ（本実施形態ではＲＡＩＤコントローラ）は、ハードウェアレベルの初期化が実行される。ハードウェアレベルの初期化とは、ＲＡＩＤコントローラを搭載した情報処理装置に対する電源投入時に実行される初期化処理である。
上記の一実施形態の図４のステップ６１７におけるドライバ４によるＲＡＩＤコントローラ３の内部リセットによる復旧が成功しなかったと判定する機能は、判定部の一例であるまた、ＯＳ１が備えるバスリセット指示部１１は、外部リセット指示部１０２の一例である
【００５０】
図７は、本発明の一実施形態による情報処理装置の最小構成を示す図である。
図７に示すように情報処理装置１００Ｂは、少なくとも制御システム１０とＲＡＩＤコントローラ３とを備える。制御システム１０は、ＲＡＩＤコントローラ３の動作を制御するデバイスドライバと、ＲＡＩＤコントローラ３が接続されたバスを制御するバスコントローラと、バスコントローラを制御するオペレーティングシステムと、を備える。さらにデバイスドライバが検出部１０１を備え、オペレーティングシステムが外部リセット指示部１０２を備える。そして、デバイスドライバの検出部１０１が、ＲＡＩＤコントローラ３が動作不能な状態であることを検出すると、オペレーティングシステムの外部リセット指示部１０２が、バスコントローラへバスリセット信号の発行を指示する。バスコントローラは、バスリセット信号をＲＡＩＤコントローラ３へ発行する。
上記の一実施形態における情報処理装置１００は、情報処理装置１００Ｂの一例である。
【００５１】
その他、本発明の趣旨を逸脱しない範囲で、上記した実施の形態における構成要素を周知の構成要素に置き換えることは適宜可能である。また、この発明の技術範囲は上記の実施形態に限られるものではなく、本発明の趣旨を逸脱しない範囲において種々の変更を加えることが可能である。例えば、ＲＡＩＤコントローラ３の応答が遅延する場合、内部リセット処理を行わずに、外部リセット処理を行うようにしてもよい。
【符号の説明】
【００５２】
１・・・ＯＳ
２・・・バス制御部
３・・・ＲＡＩＤコントローラ
２１・・・個別バスリセット処理部
２２・・・専用バス
３・・・ＲＡＩＤコントローラ
３１・・・ファームウェア
３２・・・コントローラチップ
３３〜３５・・・ＨＤＤ
３６・・・バスＩ／Ｆ
４・・・ドライバ
４１・・・ストール監視タイマ
４２・・・内部リセット処理部
４３・・・外部リセット要求部
１０・・・制御システム
１０１・・・検出部
１０２・・・外部リセット指示部
１００、１００Ａ、１００Ｂ・・・情報処理装置
【図１】
2019164578.tif 000003
【図２】
2019164578.tif 000004
【図３】
2019164578.tif 000005
【図４】
2019164578.tif 000006
【図５】
2019164578.tif 000007
【図６】
2019164578.tif 000008
【図７】
2019164578.tif 000009
【図８】
2019164578.tif 000010
【図９】
2019164578.tif 000011