(57)【要約】【課題】入出力（Ｉ／Ｏ）エラーをハンドリングするための方法及びシステムを提供する。【解決手段】本発明に係る方法は、システムの入出力（Ｉ／Ｏ）リンクのパリティエラーをハンドリングするための方法であって、前記リンクは、前記システムの複数のデバイスによって共有され、前記方法は、前記システムのコンフィギュレーションの期間中に１つ又は２つ以上のエラーについてデバイスをチェックするステップと、１つ又は２つ以上のエラーが検出された場合に、前記デバイスがコンフィギュレーションされることを制限し、前記チェックするステップを別のデバイスについて繰り返すステップと、エラーから回復する能力について前記デバイスを検査するステップと、前記デバイスが前記エラーから回復する能力を有する場合に、前記デバイスを第１のモードでコンフィギュレーションするステップとを含む方法。【選択図】図１
2008262538.tif 000002
【特許請求の範囲】
【請求項１】
システムの入出力（Ｉ／Ｏ）リンクのパリティエラーをハンドリングするための方法であって、
前記リンクは、
前記システムの複数のデバイスによって共有され、
前記方法は、
前記システムのコンフィギュレーションの期間中に１つ又は２つ以上のエラーについてデバイスをチェックするステップと、
１つ又は２つ以上のエラーが検出された場合に、前記デバイスがコンフィギュレーションされることを制限し、前記チェックするステップを別のデバイスについて繰り返すステップと、
エラーから回復する能力について前記デバイスを検査するステップと、
前記デバイスが前記エラーから回復する能力を有する場合に、前記デバイスを第１のモードでコンフィギュレーションするステップと
を含む方法。
【請求項２】
前記デバイスを検査するステップが、
前記デバイスが前記エラーから回復する能力を有しないと判断した場合に、前記システムの起動時間優先度に従って前記デバイスを第２のモードでコンフィギュレーションすること
をさらに含む、請求項１に記載の方法。
【請求項３】
前記デバイスを検査するステップは、
前記デバイスのソフトウェアコードの有効性を確認するステップを含み、
前記ソフトウェアコードは、
前記デバイスのオペレーションを駆動するコードである、
請求項１に記載の方法。
【請求項４】
前記デバイスをコンフィギュレーションするステップは、
前記デバイスに識別子を供給するステップを含み、
前記識別子は、
コンフィギュレーションのモードを示すように構成されている、
請求項１に記載の方法。
【請求項５】
前記デバイスをコンフィギュレーションするステップは、
前記デバイスに識別子を供給するステップを含み、
前記識別子は、コンフィギュレーションのモードを示すように構成されている、
請求項２に記載の方法。
【請求項６】
システムの入出力（Ｉ／Ｏ）リンク上のパリティエラーをハンドリングするための方法であって、
前記リンクは前記システムの複数のデバイスによって共有され、
前記方法は、
前記システムのランタイムの期間中にエラーについてデバイスをチェックするステップと、
前記デバイスについて遭遇したエラーを示す数の値がしきい値よりも大きい場合には前記デバイスを分離して削除し、前記チェックするステップを別のデバイスについて繰り返すステップと、
前記デバイスの回復プロセスを起動するステップと、
前記回復プロセスの結果を報告するステップと
を含む方法。
【請求項７】
前記回復プロセスを起動するステップは、
前記リンクに結合される１つ又は２つ以上のデバイスをサスペンドするステップと、
前記デバイスが結合されているリンクをリセットするステップと、
前記リンクに結合される１つ又は２つ以上のデバイスをレジュームするステップと
を含む、請求項６に記載の方法。
【請求項８】
前記システムは、
複数のオペレーティングシステムを含み、
前記デバイスを分離して削除するステップは、
前記デバイスを共有する前記オペレーティングシステムの詳細を収集するステップと、
前記デバイスを分離して削除している間、前記デバイスを使用する前記オペレーティングシステムのそれぞれを調整して更新するステップと
を含む、請求項６に記載の方法。
【請求項９】
前記回復プロセスを起動するステップは、
前記デバイスを共有する前記オペレーティングシステムの詳細を収集することと、
前記回復プロセスを実行している間、前記デバイスを使用する前記オペレーティングシステムのそれぞれを調整して更新することと
を含む、請求項８に記載の方法。
【請求項１０】
前記チェックするステップは、
前記エラーをエラーイベントキューイングモジュールにリストすることと、
前記リストされたエラーに従って前記個数をカウントすることと
を含む、請求項６に記載の方法。
【請求項１１】
前記調整して更新するステップは、
ハイパーバイザによって実行される、
請求項８に記載の方法。
【請求項１２】
前記調整して更新するステップは、
ハイパーバイザによって実行される、
請求項９に記載の方法。
【請求項１３】
前記チェックするステップは、
健全性チェッカデーモンによって定期的に実行される、
請求項６に記載の方法。
【請求項１４】
前記チェックするステップは、
前記デバイスのデバイスドライバを使用して実行される、
請求項６に記載の方法。
【請求項１５】
コンピュータシステムであって、
処理部と、
前記処理部に結合され、システムの入出力（Ｉ／Ｏ）リンク上のパリティエラーをハンドリングするためのコードを記憶するメモリであって、
前記コードは、
前記システムの前記Ｉ／Ｏリンク上のパリティエラーをハンドリングするための方法を前記処理部に実行させ、
前記Ｉ／Ｏリンクは、前記システムの複数のデバイスによって共有され、
前記コードは、
前記システムのコンフィギュレーションの期間中にエラーについてデバイスをチェックするステップと、
エラーが検出された場合に、前記デバイスがコンフィギュレーションされることを制限し、前記チェックするステップを別のデバイスについて繰り返すステップと、
エラーから回復する能力について前記デバイスを検査するステップと、
前記デバイスが前記エラーから回復する能力を有する場合に、前記デバイスを第１のモードでコンフィギュレーションするステップと
を含む
メモリとを備える、コンピュータシステム。
【請求項１６】
コンピュータシステムであって、
処理部と、
前記処理部に結合され、システムの入出力（Ｉ／Ｏ）リンク上のパリティエラーをハンドリングするためのコードを記憶するメモリであって、
前記コードは、
前記システムの前記Ｉ／Ｏリンク上のパリティエラーをハンドリングするための方法を前記処理部に実行させ、
前記Ｉ／Ｏリンクは、前記システムの複数のデバイスによって共有され、
前記コードは、
前記システムのランタイムの期間中にエラーについてデバイスをチェックするステップと、
前記デバイスについて遭遇したエラーを示す数の値がしきい値よりも大きい場合には、前記デバイスを分離して削除し、前記チェックするステップを別のデバイスについて繰り返すステップと、
前記デバイスの回復プロセスを起動するステップと、
前記回復プロセスの結果を報告するステップと
を含む
メモリとを備える、コンピュータシステム。
【請求項１７】
前記システムは、
複数のオペレーティングシステムをハンドリングするようにコンフィギュレーションされている、
請求項１６に記載のコンピュータシステム。
【請求項１８】
コンピュータシステムと共に動作可能なコンピュータ可読媒体であって、
前記コンピュータ可読媒体には、前記コンピュータシステムによってサポートされるアーキテクチャシミュレータ環境と共に動作可能な命令が記憶され、
前記媒体は、
システムの入出力（Ｉ／Ｏ）リンク上のパリティエラーをハンドリングするための命令を含み、
前記Ｉ／Ｏリンクは、
前記システムの複数のデバイスによって共有され、
前記命令は、
方法を実行するように構成され、
前記方法は、
前記システムのコンフィギュレーションの期間中にエラーについてデバイスをチェックするステップと、
エラーが検出された場合に、前記デバイスがコンフィギュレーションされることを制限し、前記チェックするステップを別のデバイスについて繰り返すステップと、
エラーから回復する能力について前記デバイスを検査するステップと、
前記デバイスが前記エラーから回復する能力を有する場合に、前記デバイスを第１のモードでコンフィギュレーションするステップと
を含む、コンピュータ可読媒体。
【請求項１９】
請求項１８に記載のコンピュータ可読媒体を備える製品。
【請求項２０】
コンピュータシステムと共に動作可能なコンピュータ可読媒体であって、
前記コンピュータ可読媒体には、前記コンピュータシステムによってサポートされるアーキテクチャシミュレータ環境と共に動作可能な命令が記憶され、
前記媒体は、
システムの入出力（Ｉ／Ｏ）リンク上のパリティエラーをハンドリングするための命令を含み、
前記Ｉ／Ｏリンクは、
前記システムの複数のデバイスによって共有され、
前記命令は、
方法を実行するように構成され、
前記方法は、
前記システムのランタイムの期間中にエラーについてデバイスをチェックするステップと、
前記デバイスについて遭遇したエラーを示す数の値がしきい値よりも大きい場合には前記デバイスを分離して削除し、前記チェックするステップを別のデバイスについて繰り返すステップと、
前記デバイスの回復プロセスを起動するステップと、
前記回復プロセスの結果を報告するステップと
を含む、コンピュータ可読媒体。
【請求項２１】
請求項２０に記載のコンピュータ可読媒体を備える製品。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明の実施の形態は、入出力（Ｉ／Ｏ）エラーをハンドリングするための方法及びシステムに関する。
【背景技術】
【０００２】
Ｉ／Ｏリンク（相互接続）は、Ｉ／Ｏデバイスをホストシステムに接続するリンクである。Ｉ／Ｏリンクは、１つのオペレーティングシステム内又は複数のオペレーティングシステム間のいずれでもいくつかのハードウェアモジュール及び／又はソフトウェアモジュールによって共有可能である。このような共有リンク上のＩ／Ｏエラーは、そのリンクを共有するモジュールに影響を与える場合がある。エラーは、ホストシステムのコンフィギュレーションの期間中に導入される場合もあるし、ホストシステムのランタイムの期間中に導入される場合もある。機能不良のＩ／Ｏデバイスがある場合、又は、Ｉ／Ｏデバイス、及び／若しくは、デバイス／システムを制御するソフトウェアモジュールがＩ／Ｏエラーをハンドリングする能力を有しない場合に、Ｉ／Ｏエラーをハンドリングしてホストシステムの機能不良を回避することが重大となる場合がある。Ｉ／Ｏリンク上のＩ／Ｏデバイスのいずれかによって導入されたエラーは、ホストシステムをクラッシュさせるのに十分なほど重大である場合がある。
【発明の開示】
【発明が解決しようとする課題】
【０００３】
本発明は、入出力（Ｉ／Ｏ）エラーをハンドリングするための方法及びシステムを提供する。
【課題を解決するための手段】
【０００４】
本発明の一形態は、システムの入出力（Ｉ／Ｏ）リンクのパリティエラーをハンドリングするための方法であって、Ｉ／Ｏリンクは、システムの複数のデバイスによって共有され、本方法は、システムのコンフィギュレーションの期間中に１つ又は２つ以上のエラーについてデバイスをチェックするステップと、１つ又は２つ以上のエラーが検出された場合に、デバイスがコンフィギュレーションされることを制限し、チェックするステップを別のデバイスについて繰り返すステップと、エラーから回復する能力についてデバイスを検査するステップと、デバイスがエラーから回復する能力を有する場合に、デバイスを第１のモードでコンフィギュレーションするステップを含む方法である。  
【０００５】
次に、添付図面を参照して本発明の実施形態を単なる例として説明する。
【発明を実施するための最良の形態】
【０００６】
本発明のさまざまな実施形態の以下の詳細な説明では、添付図面が参照される。添付図面は、この詳細な説明の一部を成し、添付図面には、本発明を実施できる特定の実施形態が例示として示されている。これらの実施形態は、本発明の実施を当業者に可能にするように十分詳細に説明されている。本発明の範囲から逸脱することなく、他の実施形態を利用することができ、変更を行うことができるということが理解されるべきである。したがって、以下の詳細な説明は、限定の意味で解釈されるべきではなく、本発明の範囲は、添付の特許請求の範囲によってのみ規定される。
【０００７】
図１は、本主題の一実施形態によるシステムのコンフィギュレーションの期間中のシステムの共有Ｉ／Ｏリンク上のパリティエラーをハンドリングするための方法を示すフローチャート１００を示している。Ｉ／Ｏリンクは、複数のＩ／Ｏデバイスによって共有されている。本方法によれば、ステップ１１０において、システムのコンフィギュレーションが進行している間、デバイスが、エラーについてチェックされる。ステップ１２０において、デバイスが何らかのエラーを有するかどうかが判断され、ステップ１２０においてエラーに遭遇している場合、デバイスはコンフィギュレーションされず（ステップ１８０）、チェックを行うステップ１１０が、別のデバイスについて繰り返される。ステップ１２０においてエラーに遭遇していない場合、ステップ１３０において、デバイスのソフトウェアコードの有効性が確認される。ソフトウェアコードの有効性を確認することによって、デバイスが機能不良でないことが保証される。有効性確認のステップは、システムのハンドリングする能力及びＩ／Ｏデバイスと通信する能力を判断するステップを含む。ステップ１４０において、デバイスは、エラーから回復する能力について検査される。デバイスがその能力を有する場合、ステップ１６０において、デバイスは第１のモードでコンフィギュレーションされる。
【０００８】
この第１のモードは、高可用性（ＨＡ）モードとして識別される。ステップ１４０における検査の結果が、デバイスがその能力を有しないことを提供するものである場合、ステップ１５０において、システム優先度がチェックされ、システム優先度が、デバイスが望ましいデバイスであることを示している場合には、デバイスは、第２のモードでコンフィギュレーションされる（ステップ１７０）。この第２のモードは、非高可用性（非ＨＡ）モードとして識別される。システム優先度が、デバイスが望ましいデバイスであることを示していない場合には、デバイスはコンフィギュレーションされない（ステップ１８０）。コンフィギュレーションステップの遂行している間、識別子をデバイスに供給することができる。この識別子は、コンフィギュレーションのモードを示すことができる。上記ステップは、リンク上の各デバイスについて繰り返され、システムの各リンクについて繰り返される。
【０００９】
本方法は、ハードウェア、関連付けられたソフトウェア、並びにそれらハードウェア及びソフトウェアのエラー（複数可）からの回復能力の有効性確認をデバイスのコンフィギュレーションの期間中に達成する。また、本方法は、機能不良のデバイスがコンフィギュレーションされることも防止する。本方法は、エラー回復能力を有しないデバイスの非ＨＡモードでのコンフィギュレーションを可能にするので有利である。非ＨＡモードでのデバイスのコンフィギュレーションによって、デバイスがエラーから回復する能力を有することに関係なく、システム稼動時間が依然として影響を受けないままであり、改善されることさえあることが保証されるだけでなく、エラーからの高速な復旧も可能になる。エラーからの高速な復旧は、リンク上にエラーが発生している場合には、非ＨＡモードでコンフィギュレーションされたデバイス（複数可）を優先的にチェックできることから可能である。非ＨＡモードでコンフィギュレーションされたデバイスは、エラーから回復する能力を有しないものとしてすでに識別されているので、したがって、それらデバイスの１つ又は２つ以上は、エラーに遭遇していた確率が高い。非ＨＡモードでコンフィギュレーションされたデバイスを優先的にチェックすることによって、非ＨＡモードでコンフィギュレーションされたデバイスでエラーに遭遇した場合にチェック時間が削減され、したがって、リンク上のすべてのデバイスをチェックするのに必要な取り組み／時間が削減される。
【００１０】
本主題の別の態様によれば、システムのランタイムの期間中の共有リンク上のパリティＩ／Ｏエラーをハンドリングするための方法が提供される。本方法の実施態様を示すブロック図３００が図３に示され、本方法を実施するために従うステップ２００が図２に示されている。３桁から成る参照符号において、その符号の最上位桁の数字は、その参照符号を配置することができる図面の番号を示していることに留意すべきである。本方法によれば、ステップ２０４において、エラー回復システムが、リンク上のＩ／Ｏエラーをチェックするための健全性チェッカデーモンを起動する。このシステムは、健全性チェッカデーモンを定期的に起動することができる。ステップ２０６において、リンク上のすべてのデバイスがアクセス可能であるかどうかをチェックするポーリングが実行され、アクセス可能である場合には、次のリンクが、ステップ２０６のポーリングのために選択される（ステップ２０８）。リンク上の或るデバイスがアクセス不能であるか又はエラーを有することが判明した場合、ステップ２１０において、そのリンクのエラーに対応するエラーイベントがキューイングされる。ステップ２１２において、エラーイベントに遭遇したことを知らせる通知が、エラー回復システムへ供給される。ステップ２１４において、デバイスについてキューイングされたエラーイベントの個数が、システムが許容できる値よりも多いかどうかがチェックされる。多い場合には、ステップ２１６において、デバイスは分離されて削除され、回復オペレーションは終了する（ステップ２３０）。多くない場合には、ステップ２１８において、デバイスは一時的にサスペンドされる。ステップ２２０において、Ｉ／Ｏリンクはリセットされ、デバイスはレジュームされる。その後のステップ２２４において、デバイスがアクセス可能であるかどうかがチェックされる。アクセス可能でない場合には、ステップ２２６において、デバイスはサスペンドされ、リンクはリセットされる。アクセス可能である場合には、ステップ２２８において、デバイスは正常に機能することが認められる。ステップ２３０において、回復オペレーションは終了する。
【００１１】
図３は、本主題の一実施形態によるＩ／Ｏエラーをハンドリングするための方法を実施するエラー回復モジュール３００のブロック図を示している。
【００１２】
エラー回復モジュール３００は、ハードウェア部３５０を有する。ハードウェア部３５０は、デバイス１、デバイス２、デバイス３、デバイス４、及びデバイス５の複数のデバイスを含む。これらのデバイスは、リンク１、リンク２、リンク３、及びリンク４の複数のＩ／Ｏリンクを介してシステムに結合されている。エラー回復モジュール３００は、エラー回復システムドライバ３０２、健全性チェッカデーモン３０４、エラーイベントキューイングモジュール３１０、及び複数のデバイスドライバ３０６を有するソフトウェアモジュールである。各デバイスドライバ３０６は、ハードウェア部３５０の１つのデバイスに対応する。エラーが、回復能力を有するデバイスで発生すると、そのエラーの発生後、デバイス上で実行されることが意図されているすべての書き込みオペレーションは、オペレーションがないものとして取り扱われ、デバイスから実行されることが意図されているすべての読み出しオペレーションは、既知のエラーコードとしてシステムに返される。
【００１３】
システムのオペレーティングシステム（ＯＳ）は、ソフトウェアモジュール（図示せず）を使用してデバイスドライバモジュール３０６にアクセスすることによってエラーを検出することができる。このソフトウェアモジュールは、ＯＳとバンドルすることができる。ソフトウェアモジュールが、デバイスから読み出しを行っている間に既知のエラーと遭遇した場合、ソフトウェアモジュールは、エラーイベントキューイングモジュール３１０にエラーイベントをリストすることもできる。エラーイベントキューイングモジュール３１０は、ハンドリングされていないすべてのエラーをリストに入れて、エラー回復を起動するように構成されている。或いは、ＯＳは、健全性チェッカデーモン３０４を使用してエラーを検出することができる（線５に図示）。
【００１４】
この健全性チェッカデーモンは、システムのＯＳによって制御される。ＯＳは、健全性チェッカデーモンを定期的に実行することができ、その結果、エラーが検出されずに放置される機会は最小限にされる。エラーが、健全性チェッカデーモン３０４により、又は、デバイスドライバ３０６を介してＯＳにより検出されると、健全性チェッカデーモン３０４／デバイスドライバ３０６は、エラーイベントをエラーイベントキューイングモジュール３１０にキューイングする。
【００１５】
これは、図３の線１、２及び線３'、５'によって示されている。健全性チェッカデーモン３０４が存在することによって、たとえ、Ｉ／Ｏリンクに接続されたＩ／Ｏデバイスを制御するＯＳソフトウェアモジュールがエラーを判断できない場合であっても、Ｉ／Ｏエラーは、タイミング良く確実に検出されるようになり、また、確実に検出されて訂正されるようになる。さらに、エラーイベントキューイングモジュール３１０によって、あらゆるエラーの見落としの危険も迂回の危険もなく複数のエラーのハンドリングが可能になる。
【００１６】
エラーイベントキューイングモジュール３１０は、或るエラーイベントが複数回リストされないことを確実にするようにも構成されている。これは、２つの異なるデバイスが、リンク上の１つエラーイベントを報告した時に発生し得る。同じリンク上の２重／多重のエラーイベントを廃棄することによって、同じリンク上で発生したエラーについての回復を複数起動しないことにより、エラーハンドリングを効率的に管理することが可能になる。また、エラーイベントキューイングモジュール３１０は、多重のエラーイベントが、異なるＩ／Ｏリンク上で発生した場合に、ＯＳがそれらイベントを同時にハンドリングすることを可能にすることによってシステムの応答性を改善する。エラー回復システムドライバ３０２は、エラーイベントキューイングモジュール３１０から１つ又は２つ以上のエラーイベントを受け取る。これは、図３の線３によって示されている。
【００１７】
エラー回復システムドライバ３０２は、エラーイベントを受け取ると、Ｉ／Ｏリンクに接続されているすべてのデバイスを特定する。最初のステップにおいて、システムドライバ３０２は、そのリンク上のＩ／Ｏデバイスを制御するすべてのＯＳモジュール（すなわち、デバイスドライバモジュール）を共通の「サスペンド」モードにする。これは、線４及び５によって示されている。これによって、デバイスは、そのデバイスを使用しているＯＳにアクセス不能となる。このステップによって、回復プロセスが進行している間、さらに新しいエラーの発生の防止が助けられる。エラー回復システムドライバ３０２は、次に、エラーから回復するためのさらなるステップを起動する。エラーが発生したリンクのリセットオペレーションが行われて、エラーがクリアされるか、又は、他のオペレーション（複数可）が行われる場合がある。これら他のオペレーションは、リンクを再び機能させるために必要とされる場合がある。
【００１８】
これは、図３の線６によって示されている。さらに、エラー回復システムドライバ３０２は、リンクの再初期化及びコンフィギュレーションを行うことによって、正常なオペレーションのためにリンクを準備する。リンクが再初期化されると、関連付けられたデバイスドライバ３０６のレジュームオペレーションが行われ（図３の線７を参照）、これによって、リンクの正常な機能がレジュームされる。
【００１９】
このエラー回復方法は、デバイスを共有するすべてのオペレーティングシステムについてデバイスをサスペンドするステップを含み、このサスペンドするステップの後に回復オペレーション及びＯＳモジュールをレジュームすることが続くので、本方法は、複数のオペレーティングシステムを使用するシステムにも使用することができる。すべてのソフトウェアモジュールを共通の「サスペンド」状態にすることによって、回復が進行中である間、ＯＳモジュールがＩ／Ｏデバイス（複数可）にアクセスすることを防止することが助けられる。これは、本方法が、異なる物理スロットに配置されているが同じＩ／Ｏリンクを共有するＩ／Ｏデバイスを回復するのに適用できることを意味する。本主題のこの態様は、図４及び図５を参照してより詳細に解説される。
【００２０】
システムは、２重／多重エラーを効率的にハンドリングできることにも留意すべきである。これは、数字及びプライム記号（たとえば、３'）で番号を付けられた線を使用して図３に示されている。健全性チェッカデーモン３０４がＩ／Ｏエラーを検出した時（２'として示す（marked））。エラーは、線３'を介してキューイングされる。エラー回復システムドライバ３０２は、エラーイベントキューイングモジュール３１０にすでに登録されているのと同じリンク上のエラーがある場合、これを２重エラーとして識別することができる。同じリンク上のエラーは、健全性チェッカデーモン３０４を介して登録されている場合もあるし、そのリンクにアクセスする他の或るデバイスによって登録されている場合もある。このようなあらゆる２重エラーが廃棄される。これによって、同じリンクについて登録されたエラーの多重回復動作が防止される。
【００２１】
さらに、システムは、異なるソースからの複数のエラーイベントをハンドリングすることもできる。これは、デバイス１を有するリンク上で検出されたエラー、及び、デバイス３を有するリンク上でデバイスドライバ３によって検出されたエラー（４'として示す）の回復オペレーションによって示されている。デバイスドライバ３によって検出されたエラーは、線５'を介してエラーイベントキューイングモジュール３１０にキューイングされる。デバイス１のエラー回復が完了すると、すなわち、線８によって示される命令が実行されるとすぐに、デバイス３のエラーについてエラーイベントキューイングモジュール３１０にキューイングされたエラーイベントのエラー回復オペレーションが実行される。
【００２２】
上述した方法は、Ｉ／Ｏデバイス及びオンライン交換オペレーションをサポートするデバイスドライバモジュールに対して実施することができる。オンライン交換オペレーションでは、デバイスへのすべてのアクセスをサスペンドし、デバイスを初期化してシステムの正常な機能をレジュームするのにモジュールを使用することができる。
【００２３】
本方法の別の態様によれば、本方法は、複数のオペレーティングシステムが、Ｉ／Ｏ資源を共有する１つのシステム上で実行されるハイパーバイザ環境で実施することができる。ハイパーバイザ環境では、Ｉ／Ｏリンクが、異なるＯＳインスタンスで実行されているさまざまなＩ／Ｏソフトウェアモジュール間で共有されている場合、このようなリンク上のＩ／Ｏエラーから回復するために、そのＩ／Ｏリンクを共有する異なるＯＳインスタンスのさまざまなＩ／Ｏソフトウェアモジュール間の同期が必要とされる。このようなシステムでは、本方法は、ハイパーバイザ環境を提供する。このハイパーバイザ環境では、エラー回復ステップの調整を行う共通のハイパーバイザモジュールが設けられる。このハイパーバイザモジュールは、Ｉ／Ｏリンクを共有する異なるＯＳインスタンスで実行されているすべてのＩ／Ｏソフトウェアモジュールに、回復オペレーションを遂行する要求を渡し、そのオペレーションの結果を得る。すべてのＩ／Ｏソフトウェアモジュールが、Ｉ／Ｏリンクを回復するために必要なステップ（たとえば、ソフトウェアモジュール及びＩ／Ｏデバイスの「サスペンド」、Ｉ／Ｏリンクの「リセット」、並びにソフトウェアモジュール及びデバイスの「レジューム」等）を完了すると、ハイパーバイザモジュールは、各ＯＳインスタンスのエラー回復システムドライバモジュールに問い合わせて、Ｉ／Ｏデバイスがアクセス可能であるかどうかを確認する。この問い合わせに基づいて、Ｉ／Ｏデバイスがアクセス可能である場合には、エラー回復オペレーションは成功としてマーキングされる。ハイパーバイザ環境における回復方法の詳細な説明は、図５を参照して以下でより詳細に説明される。本方法を実施するために従うステップは、図４に示されている。
【００２４】
図４は、ハイパーバイザ環境で方法を実施している間に従うステップを示すフロー図４００を示している。ステップ４１０において、各ＯＳインスタンスの健全性チェッカモジュール及びデバイスドライバが、それらの各Ｉ／Ｏリンクをポーリングし、エラーに遭遇した場合には、１つ又は２つ以上のエラーイベントを各エラーイベントキューイングモジュールにキューイングする。このステップにおいて、ハイパーバイザモジュールは、各ＯＳインスタンスのエラーイベントキューをチェックする。ステップ４１２において、リンク上のエラーカウントがチェックされる。ステップ４１２で得られた結果に基づいて、エラーカウントがしきい値よりも大きい場合には、ハイパーバイザモジュールは、デバイスの詳細とリンクを共有する各ＯＳインスタンスのエラー回復システムドライバに削除イベントを送る。ステップ４１６において、各ＯＳインスタンスのエラー回復システムドライバは、デバイスドライバと調整して、デバイスを分離する。次に、制御はステップ４１８において渡され、デバイスの回復プロセスを終了する。エラーカウントがしきい値の範囲内にある場合、ステップ４２０において、ハイパーバイザモジュールは、リンクを通じてデバイスを共有しているすべてのＯＳインスタンスについての情報を収集する。ステップ４２２において、ハイパーバイザモジュールは、デバイスとリンクを共有するすべてのＯＳインスタンスのエラー回復システムドライバモジュールへサスペンドイベントを送る。ステップ４２４において、各ＯＳインスタンスエラー回復システムドライバは、デバイスドライバモジュールへサスペンドイベントを送って、エラー回復システムドライバによって制御されるＩ／Ｏデバイスをサスペンドする。ステップ４２６において、ハイパーバイザモジュールは、リンクのリセットオペレーションを行う。ステップ４２８において、ハイパーバイザモジュールは、デバイスとリンクを共有する各ＯＳインスタンスのエラー回復システムドライバモジュールへレジュームイベントを送る。
【００２５】
ステップ４３０において、各ＯＳインスタンスのエラー回復システムドライバは、レジュームイベントをデバイスドライバモジュールへ送って、デバイスをレジュームする。各ＯＳインスタンスのデバイスドライバモジュールは、ドライバによって制御されたデバイスをレジュームする。ステップ４３２において、ハイパーバイザモジュールは、各ＯＳインスタンスのエラー回復システムドライバに問い合わせて、デバイスがアクセス可能であるかどうかをチェックする。ステップ４３４において、各ＯＳインスタンスのエラー回復システムドライバは、ハイパーバイザモジュールの問い合わせをチェックする。デバイスがアクセス可能でない場合、ステップ４３６において、デバイスがアクセス可能でないことを検出したＯＳインスタンスのエラー回復システムドライバによって、回復失敗信号がハイパーバイザモジュールへ渡され、ハイパーバイザモジュールは、すべてのＯＳインスタンスのエラー回復システムドライバへサスペンドイベントを送り、リンクのリセットオペレーションを行う。次に、制御は、ステップ４４０において、エラー回復プロセスの完了を示すために転送される。ＯＳインスタンスのそれぞれのエラー回復システムドライバ（複数可）によってデバイスがアクセス可能であることが判明した場合、ステップ４３８において、信号がそれに従ってハイパーバイザへ送られ、デバイスの正常な機能がレジュームされる。次に、制御は、ステップ４４０においてエラー回復プロセスの完了を示すために転送される。
【００２６】
図５は、ハイパーバイザ環境についての本方法の実施５００の一例のブロック図をより詳細に示している。図５は、２つのＯＳインスタンス５１２及び５１２'を示している。しかしながら、当業者には、図５に示すハイパーバイザ環境は、３つ以上のＯＳインスタンスについて本方法を実施するように拡張可能であることが十分理解されよう。ハイパーバイザ環境は、２つのＯＳインスタンス５１２と５１２'との間を調整するハイパーバイザモジュール５１０を有する。ＯＳインスタンス５１２及び５１２'のそれぞれは、エラーイベントキューイングモジュール５１８及び５１８'、エラー回復システムドライバ５２０及び５２０'、健全性チェッカデーモン５２２及び５２２'、並びにデバイスドライバ５２４及び５２４'をそれぞれ有する。ＯＳインスタンス５１２及び５１２'の双方は、ハードウェアモジュール５５０を共有する。ハードウェア５５０は、デバイス１、デバイス２、デバイス３、デバイス４、及びデバイス５を含む。デバイス１はリンク１に結合され、デバイス２はリンク２に結合されている。デバイス３及びデバイス４はリンク３に結合され、デバイス５はリンク４に結合されている。本方法の実施態様は、以下でより詳細に説明される。
【００２７】
この技法の実施態様の以下の説明は、主として、２つのＯＳインスタンス５１２と５１２'との間で共有されるリンク３を参照する。リンク３は、２つのデバイス、すなわち、ＯＳインスタンス５１２における５２４のデバイスドライバ３によって制御されるデバイス３、及び、ＯＳインスタンス５１２'における５２４'のデバイスドライバ４によって制御されるデバイス４を有する。
【００２８】
各ＯＳインスタンス５１２及び５１２'の健全性チェッカデーモン５２２及び５２２'は、各ＯＳインスタンスの一部として、すべてのＩ／Ｏリンク上のＩ／Ｏエラー状態を定期的にチェックする。対応するデバイスを制御するデバイスドライバモジュール５２４及び５２４'のそれぞれは、その正常に機能している期間中にＩ／Ｏエラー状態を検出することもできる。この図は、ＯＳインスタンス５１２のデバイスドライバ３が、リンク３にアクセスしている間にエラーコードに遭遇する状況を示している。この段階は、図５に１として示され、ＯＳインスタンス５１２'の５２４'のデバイスドライバ４は、同じ共有リンク上のデバイス４にアクセスしている間にエラーに遭遇する（図５に１'として示す）。
【００２９】
ＯＳインスタンス５１２における５２４のデバイスドライバ３は、エラーイベントキューイングモジュール５１８にエラーイベントをキューイングし（２として示す）、ＯＳインスタンス５１２'の５２４'のデバイスドライバ４は、エラーイベントキューイングモジュール５１８'にエラーイベントをキューイングする（２'として示す）。ハイパーバイザモジュール５１０は、各エラーイベントキューイングモジュール５１８及び５１８'にリストされていた場合があるあらゆるエラーについて、ＯＳインスタンス５１２及び５１２'のそれぞれのエラーイベントキューイングモジュール５１８及び５１８'をチェックする。ハイパーバイザモジュール５１０は、１つ又は２つ以上のエラーがエラーイベントキューイングモジュール５１８にリストされていると判断した場合、エラーイベントの供給を受ける（３及び３'として示す）。ハイパーバイザモジュール５１０は、エラーイベントキューイングモジュール５１８／５１８'からエラーイベントを受け取ると、エラーに遭遇したリンクを共有しているＯＳインスタンスに関する詳細を求める。ハイパーバイザモジュール５１０は、すべてのＯＳインスタンスを見つけると、そのリンクをデバイス情報と共有するＯＳインスタンスのそれぞれのエラー回復システムドライバ５２０及び５２０'へサスペンドイベントを送る（４及び４'として示す）。
【００３０】
ＯＳインスタンス５１２及び５１２'のそれぞれのエラー回復システムドライバ５２０及び５２０'のそれぞれは、対応するＯＳインスタンスにおける５２４及び５２４'の各制御デバイスドライバへサスペンドイベントを送って、デバイス（複数可）をサスペンドする（５及び５'として示す）。各ＯＳインスタンス５１２及び５１２'のデバイスドライバ５２４及び５２４'（この例では、ＯＳインスタンス５１２のデバイスドライバ３及びＯＳインスタンス５１２'のデバイスドライバ４）は、それらによって制御される対応するデバイス（デバイス４及びデバイス３）をサスペンドする（６及び６'として示す）。このステップによって、共有リンク及びデバイスを使用しているすべてのＯＳインスタンスは、共通のサスペンドモードで機能不良のリンク／デバイスを見つけ、ＯＳインスタンスのいずれによってもそのリンクへアクセスは行われないことが確実にされる。次に、ハイパーバイザモジュール５１０は、エラーが発生したリンクのリセットを行うことにより、又は、リンクを再び機能させるために行うことが必要とされ得る他のオペレーションを行うことにより、エラー回復のステップに従う（７として示す）。リンクのリセットが成功すると、ハイパーバイザモジュール５１０は、サスペンドされたデバイスの正常なオペレーションをレジュームする命令を、対応するエラー回復システムドライバ５２０及び５２０'へ発行する（８及び８'として示す）。各ＯＳインスタンスのエラー回復システムドライバ５２０及び５２０'は、デバイスドライバ５２４及び５２４'へレジュームイベントを送って、デバイスをレジュームする（９及び９'として示す）。各ＯＳインスタンスのデバイスドライバ５２４及び５２４'は、それによって制御されるデバイスをレジュームする。このステップは、デバイスの再初期化及び正常なオペレーションのためにデバイスを準備することを伴うことができる（１０及び１０'として示す）。
【００３１】
本方法の別の態様によれば、本方法は、（回復プロセスにおける繰り返されるエラーにより）回復プロセスが無限ループとならないことを保証するメカニズムをサポートするエラー回復システムドライバ（５２０及び５２０'）を提供する。回復プロセスの終了時に、エラー回復システムドライバ（５２０及び５２０'）は、Ｉ／Ｏリンクの状態を検証する。Ｉ／Ｏリンクがエラー状態にあり、回復オペレーションが成功しなかったことを示している場合、エラー回復システムドライバ（５２０及び５２０'）は、そのリンク上のＩ／Ｏデバイスを制御するすべてのデバイスドライバ（５２４及び５２４'）をサスペンドする。一態様によれば、Ｉ／Ｏリンクが、自動回復が失敗したこのような状態にある場合、手動の回復プロセスを使用してＩ／Ｏリンクを回復することができる。この手動の回復プロセスは、Ｉ／Ｏデバイスのオンライン交換（ＯＬＲ）機能に酷似している。手動の回復プロセスでは、ユーザは、機能不良のＩ／Ｏデバイスを適切に機能するＩ／Ｏデバイスと交換して、システムをリブートする必要なくＩ／Ｏデバイスを再起動するオプションを提供される。
【００３２】
本方法の別の態様は、特定のＩ／Ｏデバイスのユーザが、回復プロセスを停止する前に、指定された時間区間内における繰り返されるＩ／Ｏエラーの最大回数のしきい値を指定することを可能にする。本方法／システムのさらに別の態様によれば、しきい値の決定又はデフォルトのしきい値の設定を行うことができる。さらに別の態様によれば、指定された時間区間における繰り返されるＩ／Ｏエラーの回数がしきい値の範囲内にある場合に、ソフトウェアには、各デバイスをチェックするメカニズムが提供される。この回数がしきい値を超えた場合、ソフトウェアは、そのデバイスに対して削除プロセスを起動する。このようなデバイスは、特別なタグが付けられて、その後のすべてのシステムリブートにおいて分離され、それによって、そのＩ／ＯデバイスからのＩ／Ｏエラーのさらなる発生の可能性がなくなる。ユーザは、機能不良のデバイスを、システムに対して適切に機能するデバイスと交換した後、システムコンフィギュレーションにデバイスを追加するオンライン追加（ＯＬＡ）オペレーションを使用することができる。
【００３３】
図１、図２、及び図４に示すフローチャートは、例示の実施形態において実質的に連続して配列されたステップを含むが、この主題の他の実施形態は、複数のプロセッサ、或いは、２つ又は３つ以上の仮想マシン又はサブプロセッサとして編成された単一のプロセッサを使用して、２つ又は３つ以上のステップを並列に実行することができる。その上、さらに他の実施形態は、２つ又は３つ以上の相互接続された特定のハードウェアモジュールであって、関連した制御信号及びデータ信号がそれらモジュール間で及びそれらモジュールを通じて通信される、ハードウェアモジュールとしてステップを実施することもできるし、特定用途向け集積回路の一部としてステップを実施することもできる。したがって、この例示のプロセスフロー図は、ソフトウェアの実施態様、ファームウェアの実施態様、及び／又はハードウェアの実施態様に適用することができる。
【００３４】
この解説は、図１、図２、及び図５を参照して説明した方法を実行できるコンピュータシステムをさらに提供する。この解説は、命令を含むコンピュータ可読媒体をさらに提供する。この命令は、コンピュータシステムで実行される場合、図１、図２、及び図５を参照して説明した方法を実施する。この解説は、コンピュータ可読媒体を含む製品をさらに提供する。
【００３５】
システムの入出力（Ｉ／Ｏ）リンク上のエラーをハンドリングするための方法及びシステムが提供される。リンクは、システムの複数のデバイスによって共有されている。本方法は、複数のオペレーティングシステムを有するシステム上でのエラーのハンドリングをサポートする。システムのコンフィギュレーションの期間中のエラーハンドリングの方法は、システムのコンフィギュレーションの期間中にエラーについてデバイスをチェックするステップと、エラーが検出された場合に、そのデバイスがコンフィギュレーションされることをサスペンドするステップとを含む。また、本方法は、エラーから回復するデバイスの能力を検査するステップと、デバイスがエラーから回復する能力を有する場合には、デバイスを第１のモードでコンフィギュレーションし、そうでない場合には、第２のモードでデバイスをコンフィギュレーションするか又はデバイスをコンフィギュレーションしないステップとを含む。さらに、エラーのハンドリングは、システムのランタイムの期間中も行うことができる。それを行うために、チェックするステップの後に、そのデバイスについて遭遇したエラーを示す数の値がしきい値よりも大きい場合には、デバイスを分離して削除するステップが続く。そうでない場合には、本方法は、デバイスの回復プロセスを起動して、回復プロセスの結果を報告するステップを提供する。
【００３６】
上記技法は、プロセッサによって制御される装置を使用して実施することができる。この場合、プロセッサには、上記技法の一態様を構成するコンピュータプログラムの形の命令が提供される。このようなコンピュータプログラムは、コンピュータ可読命令としてストレージ媒体に記憶することができ、その結果、ストレージ媒体は、本主題のさらなる態様を構成する。
【００３７】
上記説明は、限定的なものではなく、例示であることが意図されている。他の多くの実施形態が当業者には明らかであろう。したがって、この主題の範囲は、添付の特許請求の範囲が権利を有する均等物の全範囲と共に、添付の特許請求の範囲によって決定されるべきである。
【００３８】
本明細書に示すように、本主題は、さまざまな方法、回路、Ｉ／Ｏデバイス、システム、及び関連付けられた命令を有するマシンアクセス可能媒体を含む製品を含めて、多数の異なる実施形態で実施することができる。
【００３９】
当業者には、他の実施形態が容易に明らかであろう。これらの要素、アルゴリズム、オペレーションのシーケンスはすべて、特定の要件に応じて変えることができる。図１に示す方法に関して上述したオペレーションは、本明細書で図示して説明したものとは異なる順序で行うことができる。
【００４０】
図１〜図５は、単に具象描写したものに過ぎず、一律の縮尺で描かれていない。その一定の比率は誇張されている場合がある一方、他のものは最小にされている場合がある。図１〜図５は、当業者が理解でき且つ適切に実行できる、主題のさまざまな実施形態を示している。
【００４１】
本発明の実施形態の上記詳細な説明では、開示を能率化するために、さまざまな特徴が単一の実施形態において共にグループ化されている。この開示方法は、本発明の特許を請求する実施形態が、各請求項に明確に列挙されたものよりも多くの特徴を必要とするという意図を反映しているものと解釈されるべきではない。それとは逆に、添付の特許請求の範囲が反映しているように、独創的な発明は、開示された単一の実施形態のすべての特徴よりも少ない特徴に存在している。したがって、添付の特許請求の範囲は、これによって、本発明の実施形態の詳細な説明に組み込まれ、各請求項は、それ自体で、個々の好ましい実施形態として存在する。
【図面の簡単な説明】
【００４２】
【図１】本主題の一実施形態によるシステムのコンフィギュレーションの期間中のＩ／Ｏエラーをハンドリングするための方法を示すフローチャートである。
【図２】本主題の一実施形態によるシステムのランタイムの期間中のＩ／Ｏエラーをハンドリングするための方法を示すフローチャートである。
【図３】本主題の一実施形態によるＩ／Ｏエラーをハンドリングするための方法を実施するためのブロック図である。
【図４】本主題によるハイパーバイザ環境でＩ／Ｏエラーをハンドリングするための方法を実施している間に従うステップを示す一例のフロー図である。
【図５】本主題の一実施形態によるハイパーバイザ環境でＩ／Ｏエラーをハンドリングするための方法を実施するブロック図である。
【符号の説明】
【００４３】
３０２・・・エラー回復システムドライバ
３０４・・・健全性チェッカデーモン
３０６・・・デバイスドライバ
３１０・・・エラーイベントキューイングモジュール
３５０・・・ハードウェア部
２、３'、５'・・・エラーイベント
３・・・エラーイベントの供給
４、５・・・サスペンド
６・・・Ｉ／Ｏリンクのリセット
７、８・・・レジューム
５１０・・・ハイパーバイザモジュール
５１２、５１２'・・・ＯＳインスタンス
５１８、５１８'・・・エラーイベントキューイングモジュール
５２０、５２０'・・・エラー回復システムドライバ
５２２、５２２'・・・健全性チェッカデーモン
５２４、５２４'・・・デバイスドライバ
５５０・・・ハードウェア
１、１'、２、２'・・・エラーイベント
３、３'・・・エラーイベントの供給
４、４'、５、５'、６、６'・・・サスペンド
７・・・Ｉ／Ｏリンクのリセット
８、８'、９、９'、１０、１０'・・・レジューム
【図１】
2008262538.tif 000003
【図２】
2008262538.tif 000004
【図３】
2008262538.tif 000005
【図４】
2008262538.tif 000006
【図５】
2008262538.tif 000007
【外国語明細書】
METHOD AND SYSTEM FOR HANDLING INPUT/OUTPUT (I/O) ERRORS
Background of the Invention
An I/O link (interconnect) is a link that connects I/O devices to a host system. The I/O link can be shared by several hardware and/or software modules either within an operating system or across multiple operating systems. An I/O error on such shared link may impact the modules sharing that link. An error may be introduced during configuration of the host system or during run time of the host system. If there is a malfunctioning I/O device or if an I/O device and/or a software module controlling the devices/system do not have capability to handle I/O errors then it may become critical to handle I/O error to avoid malfunctioning of the host system. An error introduced by any of the I/O device on the I/O link may be critical enough to cause a host system crash.
Brief Description of the Drawings
Embodiments of the invention will now be described, by way of example only, with reference to the accompanying drawings in which:
FIG. 1 is a flowchart illustrating a method for handling I/O errors during configuration of a system according to an embodiment of the present subject matter; 
FIG. 2 is a flow diagram a method for handling I/O errors during runtime of a system according to an embodiment of the present subject matter; 
FIG. 3 is a block diagram for implementing a method for handling I/O errors according to an embodiment of the present subject matter;
FIG. 4 is an example flow diagram depicting steps followed while implementing a method for handling I/O errors in a hypervisor environment according to present subject matter, and;
FIG. 5 is a block diagram for implementing a method for handling I/O errors in a hypervisor environment according to an embodiment of the present subject matter.
Detail Description of the subject matter
In the following detailed description of the various embodiments of the invention, reference is made to the accompanying drawings that form a part hereof, and in which are shown by way of illustration specific embodiments in which the invention may be practiced.  These embodiments are described in sufficient detail to enable those skilled in the art to practice the invention, and it is to be understood that other embodiments may be utilized and that changes may be made without departing from the scope of the present invention.  The following detailed description is, therefore, not to be taken in a limiting sense, and the scope of the present invention is defined only by the appended claims. 
FIG. 1 shows a flowchart 100 illustrating a method for handling parity errors on a shared I/O link of a system during configuration of the system according to an embodiment of the present subject matter. The I/O link is being shared by a plurality of I/O devices. According to the method at step 110 while configuration of the system is in process, a device is checked for an error. At step 120, it is determined whether the device has any error and the device is not configured (step 180), if an error is encountered at step 120 and the step 110 of checking in repeated for another device. If no error is encountered at step 120, then at step 130 a software code of the device is validated. Validating the software code ensures that the device is not malfunctioning. The step of validation includes the step of determining, the system capabilities to handle and communicate with the I/O device. At step 140, the device is examined for the capabilities for recovering from errors. If the device has the capabilities then at step 160, the device is configured in a first mode. 
The first mode is identified as a High Availability (HA) mode. If result of the examination at step 140 provides that the device does not have the capabilities, then at step 150 the system priorities are checked and if the system priority shows that the device is a desirable device then the device is configured (step 170) in a second mode, the second mode is identified as a non- High Availability (Non-HA) mode. Else the device is not configured (step 180). While performing configuration step an identifier may be supplied to the device, which identifier may be an indicative of the mode of configuration. Above steps are repeated for each device on the link and for each link in the system.
This method achieves validation of the hardware, associated software and their capabilities of recovering from error/s during the configuration of a device. This method also prevents a malfunctioning device from being configured. This method is advantageous because it allows configuration of devices that do not have error recovery capabilities in a non-HA mode. Configuration of devices in non-HA mode not only ensures that the system uptime remain unaffected or even improves irrespective of the devices having capabilities to recover from errors, but also, enables speedy resuming from an error. The speedy resuming from error is possible because, in case of occurrence of an error on a link, the device/s configured in non-HA mode may be checked on a priority basis. Since the devices configured in non-HA mode have already been identified for not having capabilities to recover from errors and therefore there is a high probability that one or more of them may have encountered the errors.  Checking for devices configured in non-HA mode on priority basis reduces the checking time if an error is occurred in a device configured in the non-HA mode and therefore, reduces efforts/time required for checking all the devices on the link.
According to another aspect of the subject matter a method is provided for handling parity I/O errors on a shared link during run time of a system. A block diagram 300 depicting implementation of the method is shown in FIG. 3 and steps 200 followed for implementing the method are shown in FIG. 2. It should be noted that in a reference numeral comprising three digits, the most significant number of the numeral indicates the FIG. number in which the reference numeral may be located. According to the method at step 204 an error recovery system initiates a health checker daemon for checking for I/O errors on a link. The system may initiate the health checker daemon periodically. At step 206 a poll is run to check if all the devices on a link are accessible if so, then next link is selected (step 208) for the poll of step 206. If a device on a link is found to be non-accessible or having errors then at step 210 an error event corresponding to the error of the link is queued. At step 212 a notice is served to the error recovery system notifying that an error event has been encountered. At step 214 it is checked if number of error events queued for a device is more than a value that can be tolerated by the system, if so, then at step 216 the device is isolated and deleted and the recovery operation ends (step 230). Else at step 218 the device is suspended temporarily. At step 220 the I/O link is reset and the device is resumed. In the subsequent step 224 it is checked if the device is accessible, if not, then the device is suspended and the link is reset at step 226. Else at step 228 the device is allowed to function normally. At step 230 the recovery operation ends. 
FIG. 3 shows a block diagram of an error recovery module 300 for implementing a method for handling I/O errors according to an embodiment of the present subject matter.  
The error recovery module 300 has a hardware section 350. The hardware section 350 includes a plurality of devices Device 1, Device 2, Device 3, Device 4 and Device 5. These devices are coupled to a system via a plurality of I/O links link1, link2, link3 and link4. The error recovery module 300 is a software module that has an error recovery system driver 302, health checker daemon 304, an error event queuing module 310 and a plurality of device drivers 306, each device driver 306 corresponds to a device of the hardware section 305. When an error occurs in a device that has a capability to recover, after occurrence of the error all write operations that are intended to be executed on the device are treated as no operations and all the read operations intended to be executed from the device are returned to the system as known error codes. 
An Operating System (OS) of the system can detect the error by accessing the device driver module 306 using a software module (not shown). The software module may be bundled with the OS. If the software module encounters a known error while reading from the device and it may also list the error event in the error event queuing module 310. The error event queuing module 310 is configured for enlisting all the unhandled errors and for initiating error recovery. Alternatively, the OS can detect the error using health checker daemon 304 (shown in line 5). 
This health checker daemon is controlled by the OS of the system. The OS may run the health checker daemon periodically, so that, chances of an error remains undetected are minimal.  When an error is detected by the health checker daemon 304 or by the OS via device driver 306, the health checker daemon 304 / device driver 306 queues the error event in the error event queuing module 310. 
This is depicted by lines 1, 2 and lines 3', 5' in the FIG. 3. Presence of health checker daemon 304 ensures that I/O errors are detected in a timely manner, and also ensures that I/O errors are detected and corrected even if the OS software modules controlling the I/O devices connected to the I/O link are not able to determine the error. Further, the error event queuing module 310 allows handling of multiple errors without any risk of dropping or bypassing any error. 
The error event queuing module 310 is also configured for ensuring that an error event is not listed multiple times, this may occur when two different devices report an error event on a link. Dropping of duplicate/multiple error events on the same link allows managing the error handling efficiently by not initiating multiple recovering for the errors occurring on the same link. The error event queuing module 310 also improves the systems' responsiveness by enabling the OS to handle multiple error events at the same time, if the events occur on different I/O links. The error recovery system driver 302 receives one or more error events from the error event queuing module 310. This is depicted by line 3 in FIG. 3. 
On receipt of an error event the error recovery system driver 302 identifies  all devices  that  are  connected  to  the  I/O  link.  At a first step the system driver 302 brings all the OS modules controlling the I/O devices  (i.e., Device  Driver  Modules)  on  that  link  to  a  common "suspended"  mode which is depicted by lines 4 and 5. This makes the device inaccessible to an OS by which the device is being used. This step helps in preventing occurrence of any further new error while the recovery process is in progress. The error recovery system driver 302 then initiates further steps for recovering from the error. A reset operation for the link on which the error has occurred is performed to clear the error or other operation/s may be performed, which operations may be required for making the link functional again. 
This is depicted by line 6 in the FIG.3. The error recovery system driver 302 further prepares the line for normal operation by re-initializing and configuring the link. Once the link has been re-initialized, a resume operation of associated device drivers 306 is performed (refer line 7 in the FIG. 3) and this resumes normal functioning of the link.    
The error recovery method can also be used for the systems using multiple operating systems as the method includes the step suspending the device for all the operating systems sharing the device and this step of suspending is followed by a recovery operation and resuming the OS modules. Bringing all software modules to a common "suspended" state helps in preventing OS modules from accessing I/O device(s) while the recovery is in progress. This means that the method can be applied to recover I/O devices located in different physical slots but sharing the same I/O link. This aspect of the present subject matter will be discussed in more details with reference to FIG. 4 and FIG. 5.
It should also be noted that, that the system can handle duplicate/multiple error efficiently. This has been depicted in the FIG. 3 using lines numbered with a number and a prime sign (e.g. 3'). When the health checker daemon 304 detected an I/O error (marked as 2'). The error gets queued via line 3'. The error recovery system driver 302 may identify this as a duplicate error if the error on the same link as already been registered in the error event queuing module 310. The error on the same link might have been registered via the health cheker daemon 304 or by some other device accessing the link. Any such duplicate error is dropped; this prevents multiple recovery action for the errors registered for the same link. 
Further, the system can handle multiple error events from different sources; this is depicted by the recovery operation for an error detected on a link having Device1 and an error detected by the Device Driver 3 (marked as 4') on a link having Device3. The error detected by the Device Driver 3 is queued on in the error event queuing module 310 via line 5'. Once the error recovery of the Device1 is over, that is, the instructions depicted by line 8 are executed, the error recovery operation for the error event queued in the error event queuing module 310 for the error of the Device 3 is executed.    
Above described method may be implemented for I/O devices and device driver modules that support online replacement operation. For online replacement operation the modules may be used for suspending all accesses to a device and initializing the device to resume normal functioning of the system.
According to another aspect to the method, the method may be implemented in a hypervisor environment where multiple operating systems run on a system sharing the I/O resources. In a hypervisor environment, if an I/O link is shared between various I/O software modules running in different OS instances, in order to recover from I/O error on such a link, a synchronization between various I/O software modules in different OS instances sharing the I/O link is required. For such systems the method provides a hypervisor environment, where a common hypervisor module is provided which does the co-ordination of the error recovery steps. The hypervisor module passes the request to perform recovery operation to all I/O software modules running in different OS instances sharing the I/O link and obtains the results of the operation. Once all the I/O software modules complete the required steps for recovering the I/O link (e.g. "suspending" software modules and I/O devices, "resetting" the I/O link and "resuming" the software modules and devices etc.) the hypervisor module enquires the error recovery system driver module in each OS instance to confirm whether I/O device is accessible. Based on the enquiry if the I/O device is accessible, then the error recovery operation is marked as success. The detailed description of the recovery method in a hypervisor environment is explained below in more detail with the reference to FIG. 5. The steps followed for implementing the method is shown in FIG. 4. 
FIG. 4 shows a flow diagram 400 depicting the steps followed while implementing the method in a hypervisor environment. At step 410 a health checker module and device drivers of each OS instance polls their respective I/O links and queues one or more error events -if encountered in respective error event queuing module. At this step a hypervisor module checks the error event queues in each OS instance. At step 412 an error count on a link is checked. Based on the result obtained at step 412, if the error count is greater than a threshold value then the hypervisor module sends delete event to an error recovery system driver of each OS instances sharing the link with the device details. At step 416 error recovery system driver of each OS instance co-ordinates with the device driver to isolate the device. The control is then passed at step 418 to end the recovery process for the device. If the error count is within threshold value then, at step 420 the hypervisor module gathers information about all the OS instances that are sharing the device through the link. At step 422 the hypervisor module sends suspend event to error recovery system driver module of all the OS instances sharing the line with the device. At step 424, the error recovery system driver of each OS instance sends suspend event to device driver module to suspend I/O device controlled by the error recovery system driver. At step 426, the hypervisor module performs a reset operation of the link. At step 428, hypervisor module sends resume event to error recovery system driver module in each OS instance sharing the link with the device. 
At step 430 error recovery system driver of each OS instance sends resume event to the device driver module to resume the device. The device driver module in each OS instance resumes the device controlled by the driver. At step 432, the hypervisor module enquires the error recovery system driver of each OS instance to check if the device is accessible. At step 434, the error recovery system driver of each OS instance checks for the query of the hypervisor module. If the device is not accessible then at step 436 a recovery failed signal is passed to the hypervisor module by the error recovery system driver of the OS instances that detects that the device is not accessible, and the hypervisor module sends suspend even to error recovery system driver on all OS instances and performs a reset operation for the link. The control is then transferred to indicate completion of error recovery process at step 440. If the device is found accessible by the error recovery system driver/s of each of OS instances then, at step 438, a signal is sent to the hypervisor accordingly and normal function of the device is resumed. The control is then transferred to indicate completion of error recovery process at step 440.
FIG. 5 shows a block diagram of an example of implementation 500 of the method for a hypervisor environment in more detail. The FIG. 5 depicts two OS instances 512 and 512' however, a person skilled in the art will appreciate that the hypervisor environment depicted in the FIG.5 can be extended to implement the method for more than two OS instances. The hypervisor environment has a hypervisor module 510 that coordinates between the two OS instances 512 and 512'. Each of the OS instances 512 and 512' respectively has an error event queuing module 518 and 518', an error recovery system driver 520 and 520', health checker daemon 522 and 522' and device drivers 524 and 524'. Both the OS instances 512 and 512' share a hardware module 550. The hardware 550 includes Device 1, Device2, Device 3, Device 4 and Device 5. The Device 1 and Device 2 are coupled to link 1 and link 2, respectively. The Device 3 and Device 4 are coupled to link 3 and the Device 5 is coupled to link 4. The implementation of the method will be explained in more detail in what follows below. 
The following explanation of the implementation of the technique largely refers to the link3 which is shared between the two OS instances 512 and 512'. The link 3 has two devices namely: Device 3 controlled by device driver 3 of 524 in OS instance 512; and Device 4 controlled by device driver 4 of 524' in OS instance 512'. 
The Health checker daemon 522 and 522' of each OS instance 512 and 512' periodically checks for I/O error condition on all I/O links as part of respective OS instance. Each of the device driver modules 524 and 524' controlling corresponding devices also can detect I/O error condition during its normal functioning. The diagram depicts a situation where the device driver 3 of OS instance 512 encounters an error code while accessing the link 3. This stage is marked as 1 in FIG.5 and the device driver 4 of 524' of OS instance 512' encounters an error while accessing Device 4 on the same shared link (Marked as 1' in the FIG.5). 
The device driver 3 of 524 in OS instance 512 queues an error event to the Error event queuing module 518 (Marked as 2) and device driver 4 of 524' of OS instance 512' queues an error event in the error event queuing module 518'(Marked as 2'). The hypervisor module 510 checks the error event queuing module 518 and 518' of each of the OS instance 512 and 512' for any error that might have been listed in the respective error event queuing modules 518 and 518'. If the hypervisor module 510 determines that one or more errors are listed in the error event queuing module 518 then the hypervisor module 510 is served the error event (marked as 3 and 3'). On receiving an error event from the error event queuing module 518/518' the hypervisor module 510 determine details regarding the OS instances that are sharing the link on which the error has been encountered. Upon finding the all OS instances, the hypervisor module 510 sends a suspend event to the error recovery system driver 520 and 520' of each the OS instances sharing the link with the device information (Marked as 4 and 4'). 
Each of the error recovery system drivers 520 and 520' of each of the OS instance 512 and 512'send the suspend event to respective controlling device drivers of 524 and 524' in corresponding OS instance to suspend the device/s (Marked as 5 and 5'). The device drivers 524 and 524' of each OS instance 512 and 512' (in this example device driver 3 of OS instance 512 and device driver 4 of OS instance 512') suspend corresponding devices (Device 4 and Device 3) controlled by them (marked as 6 and 6'). This step ensures that all the OS instances in using the shared links and devices find the malfunctioning link/devices in a common suspended mode and no access is made to that link by any of the OS instances. The hypervisor module 510 then follows steps for error recovery by performing a reset of the link on which the error occurred or by performing other operations that might be required to perform for making the link functional again (Marked as 7).  Once the link is successfully reset, the hypervisor module 510 issues instruction to resume normal operation of the suspended device to the corresponding error recovery system drivers 520 and 520' (Marked as 8 and 8'). The error recovery system drivers 520 and 520' of each OS instance sends resume event to device drivers 524 and 524' to resume the device (Marked as 9 and 9'). The device drivers 524 and 524' of each OS instance resumes device controlled by it. This step may involve re-initialization of the device and preparing the device for normal operation (Marked as 10 and 10').
According to another aspect of the method, the method provides error recovery system drivers (520 and 520') that supports a mechanism to ensure that the recovery process does not result in an infinite loop (due to repeated errors in the recovery process).  At the end of the recovery process, the error recovery system drivers (520 and 520') verifies the state of the I/O link. If the I/O link is in an error state, indicating that the recovery operation has not succeeded, the error recovery system drivers (520 and 520') suspend all the Device Drivers (524 and 524') controlling I/O devices on that link. According to an aspect, if the I/O link is in such a state, where automatic recovery has failed, then the I/O link may be recovered using a manual recovery process, which is very much similar to the Online Replacement (OLR) functionality for I/O devices. In the manual recovery process, the user is provided the option to replace the malfunctioning I/O device with a properly functioning I/O device and restart the I/O device without having to reboot the system.
Another aspect of the method enables a user of a particular I/O device to specify a threshold value for the maximum number of repeated I/O errors in a specified time interval, before stopping the recovery process. According to a further aspect of the method/system is capable of determining a threshold value or setting a default threshold value. According to yet a further aspect, software is provided with a mechanism that checks for each device, if the number of repeated I/O errors in a specified time intervals are within the threshold value. In case the number exceeds the threshold value then the software initiates a deleting process for the device. Such devices are specially tagged and  are  isolated  on  all  further  system reboots  thereby  eliminating  the  possibility  of  any  further generation of I/O errors from that I/O device. A user can use Online Addition (OLA) operation to add the device to the system configuration, after replacing the malfunctioning device with a properly functioning device to the system.
Although the flowcharts shown in FIGS. 1, 2, and 4 include steps, that are arranged substantially serially in the exemplary embodiments, other embodiments of the subject matter may execute two or more steps in parallel, using multiple processors or a single processor organized as two or more virtual machines or sub-processors.  Moreover, still other embodiments may implement the steps as two or more specific interconnected hardware modules with related control and data signals communicated between and through the modules, or as portions of an application-specific integrated circuit.  Thus, the exemplary process flow diagrams are applicable to software, firmware, and/or hardware implementations.
The discussion further provides a computer system that is capable of executing the method described with reference to FIGS. 1, 2 and 5. The discussion further provides a computer readable medium that comprises instruction, the instruction when executed with a computer system implements the method described with reference to FIGS. 1, 2, and 5. The discussion further provides an article that includes the computer readable medium.
According a method and system for handling errors on an Input/Output (I/O) link of a system is provided. The link is being shared by a plurality of devices of the system. The method supports handling of error on a system having plurality of operating systems. The method of error handling during configure of the system includes steps of checking a device for an error during configuration of the system and suspending the device from being configured, if an error is detected. The method also includes the step of examining the device capabilities to recover from errors, and; configuring the device in a first mode if the device has capabilities to recover from errors, else configuring the device in a second more or not configuring the device. Further, the handling of error may also be performed during runtime of the system, for doing so the step of checking is followed by a step of isolating and deleting the device if value of a number indicative of errors encountered for the device is greater than a threshold value. Else the method provide step of initiating a recovery process for the device and reporting result of recovery process.
The above technique can be implemented using an apparatus controlled by a processor where the processor is provided with instructions in the form of a computer program constituting an aspect of the above technique. Such a computer program may be stored in storage medium as computer readable instructions so that the storage medium constitutes a further aspect of the present subject matter.
The above description is intended to be illustrative, and not restrictive. Many other embodiments will be apparent to those skilled in the art. The scope of the subject matter should therefore be determined by the appended claims, along with the full scope of equivalents to which such claims are entitled.
As shown herein, the present subject matter can be implemented in a number of different embodiments, including various methods, a circuit, an I/O device, a system, and an article comprising a machine-accessible medium having associated instructions.
Other embodiments will be readily apparent to those of ordinary skill in the art.  The elements, algorithms, and sequence of operations can all be varied to suit particular requirements.  The operations described-above with respect to the method illustrated in FIG. 1 can be performed in a different order from those shown and described herein. 
FIGS. 1-5 are merely representational and are not drawn to scale. Certain proportions thereof may be exaggerated, while others may be minimized. FIGS. 1-5 illustrate various embodiments of the subject matter that can be understood and appropriately carried out by those of ordinary skill in the art.
In the foregoing detailed description of the embodiments of the invention, various features are grouped together in a single embodiment for the purpose of streamlining the disclosure. This method of disclosure is not to be interpreted as reflecting an intention that the claimed embodiments of the invention require more features than are expressly recited in each claim. Rather, as the following claims reflect, inventive invention lies in less than all features of a single disclosed embodiment. Thus, the following claims are hereby incorporated into the detailed description of the embodiments of the invention, with each claim standing on its own as a separate preferred embodiment.
CLAIMS
1.    A method for handling parity errors in an Input/Output (I/O) link of a system, the link being shared by a plurality of devices of the system, the method comprising the steps of:
checking a device for one or more errors during configuration of the system;
restricting the device from being configured and repeating the step of checking for another device, if one or more errors are detected;
examining the device for capabilities to recover from errors; and
configuring the device in a first mode if the device has the capabilities to recover from the errors. 
2.    The method as claimed in claim 1, further comprising: 
configuring the device in a second mode according to an uptime priority of the system, if the step of examining determines that the device does not have capabilities to recover from errors.
3.     The method as claimed in claim 1 wherein, the step of examining the device includes the step of validating a software code of the device, the software code being a code that drives operation of the device.
4.    The method as claimed in claim 1 wherein, the step of configuring device includes step of supplying an identifier to the device, the identifier being configured to indicate mode of configuration.
5.    The method as claimed in claim 2 wherein, the step of configuring device includes step of supplying an identifier to the device, the identifier being configured to indicate mode of configuration.
6.    A method for handling parity errors on an Input/Output (I/O) link of a system, the link being shared by a plurality of devices of the system, the method comprising the steps of:
checking a device for an error during run time of the system;
isolating and deleting the device if value of a number indicative of errors encountered for the device is greater than a threshold value and repeating the step of checking for another device; 
initiating a recovery process for the device; and
reporting result of recovery process.
7.    The method as claimed in claim 6, wherein the step of initiating a recovery process comprises the steps of:
suspending one or more devices coupled to the link;
resetting a link to which the device is coupled; and 
resuming one or more devices coupled to the link.
8.    The method as claimed in claim 6, wherein the system includes a plurality of operating systems and the step of isolating and deleting the device comprises the steps of;
gathering details of the operating systems sharing the device; and
coordinating and updating each of the operating system that uses the device, while isolating and deleting the device.
9.    The method as claimed in claim 8 wherein, the step of initiating the recovery process comprises:
gathering details of the operating systems sharing the device; and
coordinating and updating each of the operating system that uses the device, while performing recovery process.
10.     The method as claimed in claim 6 wherein, the step of checking comprises:
listing the error in a error event queuing module; and
counting the number according to the listed errors.
11.    The method as claimed in claim 8, wherein the step of coordinating and updating is performed by a hypervisor.
12.    The method as claimed in claim 9, wherein the step of coordinating and updating is performed by a hypervisor.
13.    The method as claimed in claim 6, wherein the step of checking is performed periodically by a health checker daemon. 
14.    The method as claimed in claim 6, wherein the step of checking is performed using a device driver of the device.
15.    A computer system comprising:
a processing unit; and
a memory coupled to the processing unit, the memory having stored therein a code for handling parity errors on an Input/Output (I/O) link of a system, the code causes the processor to perform a method for handling parity errors on an I/O link of a system, the link being shared by a plurality of devices of the system, comprising the steps of:
checking a device for an error during configuration of the system;
restricting the device from being configured and repeating the step of checking for another device, if an error is detected;
examining the device capabilities to recover from errors; and
configuring the device in a first mode if the device has capabilities to recover from errors. 
16.    A computer system comprising:
a processing unit; and
a memory coupled to the processing unit, the memory having stored therein a code for handling parity errors on an Input/Output (I/O) link of a system, the code causes the processor to perform a method for handling parity errors on an I/O link of a system, the link being shared by a plurality of devices of the system, comprising the steps of:
checking a device for an error during run time of the system;
isolating and deleting the device if value of a number indicative of errors encountered for the device is greater than a threshold value and repeating the step of checking for another device; 
initiating a recovery process for the device; and
reporting result of recovery process.
17.    The computer system as claimed in claim 16, wherein the system is configured for handling a plurality of operating system. 
18.    A computer-readable medium operable with a computer system, the computer-readable medium having stored thereon instructions operable with an architectural simulator environment supported by the computer system, the medium comprising:     instructions for handling parity errors on an Input/Output (I/O) link of a system, the link being shared by a plurality of devices of the system, the instructions are configured to execute a method, the method comprising the steps of:
checking a device for an error during configuration of the system;
restricting the device from being configured and repeating the step of checking for another device, if an error is detected;
examining the device capabilities to recover from errors; and
configuring the device in a first mode if the device has capabilities to recover from errors. 
19.     An article comprising the computer readable medium of claim 18.
20.     A computer readable medium operable with a computer system, the computer-readable medium having stored thereon instructions operable with an architectural simulator environment supported by the computer system, the medium comprising: 
instructions for handling parity errors on an Input/Output (I/O) link of a system, the link being shared by a plurality of devices of the system, the instructions are configured to execute a method, the method comprising the steps of:
checking a device for an error during run time of the system;
isolating and deleting the device if value of a number indicative of errors encountered for the device is greater than a threshold value and repeating the step of checking for another device; 
initiating a recovery process for the device; and
reporting result of recovery process.
21.    An article comprising the computer readable medium of claim 20.
Abstract:
A method and system for handling errors on an Input/Output (I/O) link of a system is provided. The link is being shared by a plurality of devices of the system; each device may be shared by one or more operating systems. The method of error handling during configure of the system includes steps of checking a device for an error during configuration of the system and restricting the device from being configured, if an error is detected. The method includes the steps of examining the device capabilities to recover from errors, and; configuring the device in a first mode if the device has capabilities to recover from errors, else configuring the device in a second mode or not configuring the device. Further the handling of error may also be performed during runtime of the system, for doing so the step of checking is followed by a step of isolating and deleting the device if value of a number indicative of errors encountered for the device is greater than a threshold value. Else the method provides step of initiating a recovery process for the device and reporting result of the recovery process.
2008262538.tif 000008
2008262538.tif 000009
2008262538.tif 000010
2008262538.tif 000011
2008262538.tif 000012