JP2008262538A - 入出力（ｉ／ｏ）エラーをハンドリングするための方法及びシステム - Google Patents

Abstract

【課題】入出力（Ｉ／Ｏ）エラーをハンドリングするための方法及びシステムを提供する。
【解決手段】本発明に係る方法は、システムの入出力（Ｉ／Ｏ）リンクのパリティエラーをハンドリングするための方法であって、前記リンクは、前記システムの複数のデバイスによって共有され、前記方法は、前記システムのコンフィギュレーションの期間中に１つ又は２つ以上のエラーについてデバイスをチェックするステップと、１つ又は２つ以上のエラーが検出された場合に、前記デバイスがコンフィギュレーションされることを制限し、前記チェックするステップを別のデバイスについて繰り返すステップと、エラーから回復する能力について前記デバイスを検査するステップと、前記デバイスが前記エラーから回復する能力を有する場合に、前記デバイスを第１のモードでコンフィギュレーションするステップとを含む方法。
【選択図】図１

Description

本発明の実施の形態は、入出力（Ｉ／Ｏ）エラーをハンドリングするための方法及びシステムに関する。

Ｉ／Ｏリンク（相互接続）は、Ｉ／Ｏデバイスをホストシステムに接続するリンクである。Ｉ／Ｏリンクは、１つのオペレーティングシステム内又は複数のオペレーティングシステム間のいずれでもいくつかのハードウェアモジュール及び／又はソフトウェアモジュールによって共有可能である。このような共有リンク上のＩ／Ｏエラーは、そのリンクを共有するモジュールに影響を与える場合がある。エラーは、ホストシステムのコンフィギュレーションの期間中に導入される場合もあるし、ホストシステムのランタイムの期間中に導入される場合もある。機能不良のＩ／Ｏデバイスがある場合、又は、Ｉ／Ｏデバイス、及び／若しくは、デバイス／システムを制御するソフトウェアモジュールがＩ／Ｏエラーをハンドリングする能力を有しない場合に、Ｉ／Ｏエラーをハンドリングしてホストシステムの機能不良を回避することが重大となる場合がある。Ｉ／Ｏリンク上のＩ／Ｏデバイスのいずれかによって導入されたエラーは、ホストシステムをクラッシュさせるのに十分なほど重大である場合がある。

本発明は、入出力（Ｉ／Ｏ）エラーをハンドリングするための方法及びシステムを提供する。

本発明の一形態は、システムの入出力（Ｉ／Ｏ）リンクのパリティエラーをハンドリングするための方法であって、Ｉ／Ｏリンクは、システムの複数のデバイスによって共有され、本方法は、システムのコンフィギュレーションの期間中に１つ又は２つ以上のエラーについてデバイスをチェックするステップと、１つ又は２つ以上のエラーが検出された場合に、デバイスがコンフィギュレーションされることを制限し、チェックするステップを別のデバイスについて繰り返すステップと、エラーから回復する能力についてデバイスを検査するステップと、デバイスがエラーから回復する能力を有する場合に、デバイスを第１のモードでコンフィギュレーションするステップを含む方法である。

次に、添付図面を参照して本発明の実施形態を単なる例として説明する。

本発明のさまざまな実施形態の以下の詳細な説明では、添付図面が参照される。添付図面は、この詳細な説明の一部を成し、添付図面には、本発明を実施できる特定の実施形態が例示として示されている。これらの実施形態は、本発明の実施を当業者に可能にするように十分詳細に説明されている。本発明の範囲から逸脱することなく、他の実施形態を利用することができ、変更を行うことができるということが理解されるべきである。したがって、以下の詳細な説明は、限定の意味で解釈されるべきではなく、本発明の範囲は、添付の特許請求の範囲によってのみ規定される。

図１は、本主題の一実施形態によるシステムのコンフィギュレーションの期間中のシステムの共有Ｉ／Ｏリンク上のパリティエラーをハンドリングするための方法を示すフローチャート１００を示している。Ｉ／Ｏリンクは、複数のＩ／Ｏデバイスによって共有されている。本方法によれば、ステップ１１０において、システムのコンフィギュレーションが進行している間、デバイスが、エラーについてチェックされる。ステップ１２０において、デバイスが何らかのエラーを有するかどうかが判断され、ステップ１２０においてエラーに遭遇している場合、デバイスはコンフィギュレーションされず（ステップ１８０）、チェックを行うステップ１１０が、別のデバイスについて繰り返される。ステップ１２０においてエラーに遭遇していない場合、ステップ１３０において、デバイスのソフトウェアコードの有効性が確認される。ソフトウェアコードの有効性を確認することによって、デバイスが機能不良でないことが保証される。有効性確認のステップは、システムのハンドリングする能力及びＩ／Ｏデバイスと通信する能力を判断するステップを含む。ステップ１４０において、デバイスは、エラーから回復する能力について検査される。デバイスがその能力を有する場合、ステップ１６０において、デバイスは第１のモードでコンフィギュレーションされる。

この第１のモードは、高可用性（ＨＡ）モードとして識別される。ステップ１４０における検査の結果が、デバイスがその能力を有しないことを提供するものである場合、ステップ１５０において、システム優先度がチェックされ、システム優先度が、デバイスが望ましいデバイスであることを示している場合には、デバイスは、第２のモードでコンフィギュレーションされる（ステップ１７０）。この第２のモードは、非高可用性（非ＨＡ）モードとして識別される。システム優先度が、デバイスが望ましいデバイスであることを示していない場合には、デバイスはコンフィギュレーションされない（ステップ１８０）。コンフィギュレーションステップの遂行している間、識別子をデバイスに供給することができる。この識別子は、コンフィギュレーションのモードを示すことができる。上記ステップは、リンク上の各デバイスについて繰り返され、システムの各リンクについて繰り返される。

本方法は、ハードウェア、関連付けられたソフトウェア、並びにそれらハードウェア及びソフトウェアのエラー（複数可）からの回復能力の有効性確認をデバイスのコンフィギュレーションの期間中に達成する。また、本方法は、機能不良のデバイスがコンフィギュレーションされることも防止する。本方法は、エラー回復能力を有しないデバイスの非ＨＡモードでのコンフィギュレーションを可能にするので有利である。非ＨＡモードでのデバイスのコンフィギュレーションによって、デバイスがエラーから回復する能力を有することに関係なく、システム稼動時間が依然として影響を受けないままであり、改善されることさえあることが保証されるだけでなく、エラーからの高速な復旧も可能になる。エラーからの高速な復旧は、リンク上にエラーが発生している場合には、非ＨＡモードでコンフィギュレーションされたデバイス（複数可）を優先的にチェックできることから可能である。非ＨＡモードでコンフィギュレーションされたデバイスは、エラーから回復する能力を有しないものとしてすでに識別されているので、したがって、それらデバイスの１つ又は２つ以上は、エラーに遭遇していた確率が高い。非ＨＡモードでコンフィギュレーションされたデバイスを優先的にチェックすることによって、非ＨＡモードでコンフィギュレーションされたデバイスでエラーに遭遇した場合にチェック時間が削減され、したがって、リンク上のすべてのデバイスをチェックするのに必要な取り組み／時間が削減される。

本主題の別の態様によれば、システムのランタイムの期間中の共有リンク上のパリティＩ／Ｏエラーをハンドリングするための方法が提供される。本方法の実施態様を示すブロック図３００が図３に示され、本方法を実施するために従うステップ２００が図２に示されている。３桁から成る参照符号において、その符号の最上位桁の数字は、その参照符号を配置することができる図面の番号を示していることに留意すべきである。本方法によれば、ステップ２０４において、エラー回復システムが、リンク上のＩ／Ｏエラーをチェックするための健全性チェッカデーモンを起動する。このシステムは、健全性チェッカデーモンを定期的に起動することができる。ステップ２０６において、リンク上のすべてのデバイスがアクセス可能であるかどうかをチェックするポーリングが実行され、アクセス可能である場合には、次のリンクが、ステップ２０６のポーリングのために選択される（ステップ２０８）。リンク上の或るデバイスがアクセス不能であるか又はエラーを有することが判明した場合、ステップ２１０において、そのリンクのエラーに対応するエラーイベントがキューイングされる。ステップ２１２において、エラーイベントに遭遇したことを知らせる通知が、エラー回復システムへ供給される。ステップ２１４において、デバイスについてキューイングされたエラーイベントの個数が、システムが許容できる値よりも多いかどうかがチェックされる。多い場合には、ステップ２１６において、デバイスは分離されて削除され、回復オペレーションは終了する（ステップ２３０）。多くない場合には、ステップ２１８において、デバイスは一時的にサスペンドされる。ステップ２２０において、Ｉ／Ｏリンクはリセットされ、デバイスはレジュームされる。その後のステップ２２４において、デバイスがアクセス可能であるかどうかがチェックされる。アクセス可能でない場合には、ステップ２２６において、デバイスはサスペンドされ、リンクはリセットされる。アクセス可能である場合には、ステップ２２８において、デバイスは正常に機能することが認められる。ステップ２３０において、回復オペレーションは終了する。

図３は、本主題の一実施形態によるＩ／Ｏエラーをハンドリングするための方法を実施するエラー回復モジュール３００のブロック図を示している。

エラー回復モジュール３００は、ハードウェア部３５０を有する。ハードウェア部３５０は、デバイス１、デバイス２、デバイス３、デバイス４、及びデバイス５の複数のデバイスを含む。これらのデバイスは、リンク１、リンク２、リンク３、及びリンク４の複数のＩ／Ｏリンクを介してシステムに結合されている。エラー回復モジュール３００は、エラー回復システムドライバ３０２、健全性チェッカデーモン３０４、エラーイベントキューイングモジュール３１０、及び複数のデバイスドライバ３０６を有するソフトウェアモジュールである。各デバイスドライバ３０６は、ハードウェア部３５０の１つのデバイスに対応する。エラーが、回復能力を有するデバイスで発生すると、そのエラーの発生後、デバイス上で実行されることが意図されているすべての書き込みオペレーションは、オペレーションがないものとして取り扱われ、デバイスから実行されることが意図されているすべての読み出しオペレーションは、既知のエラーコードとしてシステムに返される。

システムのオペレーティングシステム（ＯＳ）は、ソフトウェアモジュール（図示せず）を使用してデバイスドライバモジュール３０６にアクセスすることによってエラーを検出することができる。このソフトウェアモジュールは、ＯＳとバンドルすることができる。ソフトウェアモジュールが、デバイスから読み出しを行っている間に既知のエラーと遭遇した場合、ソフトウェアモジュールは、エラーイベントキューイングモジュール３１０にエラーイベントをリストすることもできる。エラーイベントキューイングモジュール３１０は、ハンドリングされていないすべてのエラーをリストに入れて、エラー回復を起動するように構成されている。或いは、ＯＳは、健全性チェッカデーモン３０４を使用してエラーを検出することができる（線５に図示）。

この健全性チェッカデーモンは、システムのＯＳによって制御される。ＯＳは、健全性チェッカデーモンを定期的に実行することができ、その結果、エラーが検出されずに放置される機会は最小限にされる。エラーが、健全性チェッカデーモン３０４により、又は、デバイスドライバ３０６を介してＯＳにより検出されると、健全性チェッカデーモン３０４／デバイスドライバ３０６は、エラーイベントをエラーイベントキューイングモジュール３１０にキューイングする。

これは、図３の線１、２及び線３'、５'によって示されている。健全性チェッカデーモン３０４が存在することによって、たとえ、Ｉ／Ｏリンクに接続されたＩ／Ｏデバイスを制御するＯＳソフトウェアモジュールがエラーを判断できない場合であっても、Ｉ／Ｏエラーは、タイミング良く確実に検出されるようになり、また、確実に検出されて訂正されるようになる。さらに、エラーイベントキューイングモジュール３１０によって、あらゆるエラーの見落としの危険も迂回の危険もなく複数のエラーのハンドリングが可能になる。

エラーイベントキューイングモジュール３１０は、或るエラーイベントが複数回リストされないことを確実にするようにも構成されている。これは、２つの異なるデバイスが、リンク上の１つエラーイベントを報告した時に発生し得る。同じリンク上の２重／多重のエラーイベントを廃棄することによって、同じリンク上で発生したエラーについての回復を複数起動しないことにより、エラーハンドリングを効率的に管理することが可能になる。また、エラーイベントキューイングモジュール３１０は、多重のエラーイベントが、異なるＩ／Ｏリンク上で発生した場合に、ＯＳがそれらイベントを同時にハンドリングすることを可能にすることによってシステムの応答性を改善する。エラー回復システムドライバ３０２は、エラーイベントキューイングモジュール３１０から１つ又は２つ以上のエラーイベントを受け取る。これは、図３の線３によって示されている。

エラー回復システムドライバ３０２は、エラーイベントを受け取ると、Ｉ／Ｏリンクに接続されているすべてのデバイスを特定する。最初のステップにおいて、システムドライバ３０２は、そのリンク上のＩ／Ｏデバイスを制御するすべてのＯＳモジュール（すなわち、デバイスドライバモジュール）を共通の「サスペンド」モードにする。これは、線４及び５によって示されている。これによって、デバイスは、そのデバイスを使用しているＯＳにアクセス不能となる。このステップによって、回復プロセスが進行している間、さらに新しいエラーの発生の防止が助けられる。エラー回復システムドライバ３０２は、次に、エラーから回復するためのさらなるステップを起動する。エラーが発生したリンクのリセットオペレーションが行われて、エラーがクリアされるか、又は、他のオペレーション（複数可）が行われる場合がある。これら他のオペレーションは、リンクを再び機能させるために必要とされる場合がある。

これは、図３の線６によって示されている。さらに、エラー回復システムドライバ３０２は、リンクの再初期化及びコンフィギュレーションを行うことによって、正常なオペレーションのためにリンクを準備する。リンクが再初期化されると、関連付けられたデバイスドライバ３０６のレジュームオペレーションが行われ（図３の線７を参照）、これによって、リンクの正常な機能がレジュームされる。

このエラー回復方法は、デバイスを共有するすべてのオペレーティングシステムについてデバイスをサスペンドするステップを含み、このサスペンドするステップの後に回復オペレーション及びＯＳモジュールをレジュームすることが続くので、本方法は、複数のオペレーティングシステムを使用するシステムにも使用することができる。すべてのソフトウェアモジュールを共通の「サスペンド」状態にすることによって、回復が進行中である間、ＯＳモジュールがＩ／Ｏデバイス（複数可）にアクセスすることを防止することが助けられる。これは、本方法が、異なる物理スロットに配置されているが同じＩ／Ｏリンクを共有するＩ／Ｏデバイスを回復するのに適用できることを意味する。本主題のこの態様は、図４及び図５を参照してより詳細に解説される。

システムは、２重／多重エラーを効率的にハンドリングできることにも留意すべきである。これは、数字及びプライム記号（たとえば、３'）で番号を付けられた線を使用して図３に示されている。健全性チェッカデーモン３０４がＩ／Ｏエラーを検出した時（２'として示す（marked））。エラーは、線３'を介してキューイングされる。エラー回復システムドライバ３０２は、エラーイベントキューイングモジュール３１０にすでに登録されているのと同じリンク上のエラーがある場合、これを２重エラーとして識別することができる。同じリンク上のエラーは、健全性チェッカデーモン３０４を介して登録されている場合もあるし、そのリンクにアクセスする他の或るデバイスによって登録されている場合もある。このようなあらゆる２重エラーが廃棄される。これによって、同じリンクについて登録されたエラーの多重回復動作が防止される。

さらに、システムは、異なるソースからの複数のエラーイベントをハンドリングすることもできる。これは、デバイス１を有するリンク上で検出されたエラー、及び、デバイス３を有するリンク上でデバイスドライバ３によって検出されたエラー（４'として示す）の回復オペレーションによって示されている。デバイスドライバ３によって検出されたエラーは、線５'を介してエラーイベントキューイングモジュール３１０にキューイングされる。デバイス１のエラー回復が完了すると、すなわち、線８によって示される命令が実行されるとすぐに、デバイス３のエラーについてエラーイベントキューイングモジュール３１０にキューイングされたエラーイベントのエラー回復オペレーションが実行される。

上述した方法は、Ｉ／Ｏデバイス及びオンライン交換オペレーションをサポートするデバイスドライバモジュールに対して実施することができる。オンライン交換オペレーションでは、デバイスへのすべてのアクセスをサスペンドし、デバイスを初期化してシステムの正常な機能をレジュームするのにモジュールを使用することができる。

本方法の別の態様によれば、本方法は、複数のオペレーティングシステムが、Ｉ／Ｏ資源を共有する１つのシステム上で実行されるハイパーバイザ環境で実施することができる。ハイパーバイザ環境では、Ｉ／Ｏリンクが、異なるＯＳインスタンスで実行されているさまざまなＩ／Ｏソフトウェアモジュール間で共有されている場合、このようなリンク上のＩ／Ｏエラーから回復するために、そのＩ／Ｏリンクを共有する異なるＯＳインスタンスのさまざまなＩ／Ｏソフトウェアモジュール間の同期が必要とされる。このようなシステムでは、本方法は、ハイパーバイザ環境を提供する。このハイパーバイザ環境では、エラー回復ステップの調整を行う共通のハイパーバイザモジュールが設けられる。このハイパーバイザモジュールは、Ｉ／Ｏリンクを共有する異なるＯＳインスタンスで実行されているすべてのＩ／Ｏソフトウェアモジュールに、回復オペレーションを遂行する要求を渡し、そのオペレーションの結果を得る。すべてのＩ／Ｏソフトウェアモジュールが、Ｉ／Ｏリンクを回復するために必要なステップ（たとえば、ソフトウェアモジュール及びＩ／Ｏデバイスの「サスペンド」、Ｉ／Ｏリンクの「リセット」、並びにソフトウェアモジュール及びデバイスの「レジューム」等）を完了すると、ハイパーバイザモジュールは、各ＯＳインスタンスのエラー回復システムドライバモジュールに問い合わせて、Ｉ／Ｏデバイスがアクセス可能であるかどうかを確認する。この問い合わせに基づいて、Ｉ／Ｏデバイスがアクセス可能である場合には、エラー回復オペレーションは成功としてマーキングされる。ハイパーバイザ環境における回復方法の詳細な説明は、図５を参照して以下でより詳細に説明される。本方法を実施するために従うステップは、図４に示されている。

図４は、ハイパーバイザ環境で方法を実施している間に従うステップを示すフロー図４００を示している。ステップ４１０において、各ＯＳインスタンスの健全性チェッカモジュール及びデバイスドライバが、それらの各Ｉ／Ｏリンクをポーリングし、エラーに遭遇した場合には、１つ又は２つ以上のエラーイベントを各エラーイベントキューイングモジュールにキューイングする。このステップにおいて、ハイパーバイザモジュールは、各ＯＳインスタンスのエラーイベントキューをチェックする。ステップ４１２において、リンク上のエラーカウントがチェックされる。ステップ４１２で得られた結果に基づいて、エラーカウントがしきい値よりも大きい場合には、ハイパーバイザモジュールは、デバイスの詳細とリンクを共有する各ＯＳインスタンスのエラー回復システムドライバに削除イベントを送る。ステップ４１６において、各ＯＳインスタンスのエラー回復システムドライバは、デバイスドライバと調整して、デバイスを分離する。次に、制御はステップ４１８において渡され、デバイスの回復プロセスを終了する。エラーカウントがしきい値の範囲内にある場合、ステップ４２０において、ハイパーバイザモジュールは、リンクを通じてデバイスを共有しているすべてのＯＳインスタンスについての情報を収集する。ステップ４２２において、ハイパーバイザモジュールは、デバイスとリンクを共有するすべてのＯＳインスタンスのエラー回復システムドライバモジュールへサスペンドイベントを送る。ステップ４２４において、各ＯＳインスタンスエラー回復システムドライバは、デバイスドライバモジュールへサスペンドイベントを送って、エラー回復システムドライバによって制御されるＩ／Ｏデバイスをサスペンドする。ステップ４２６において、ハイパーバイザモジュールは、リンクのリセットオペレーションを行う。ステップ４２８において、ハイパーバイザモジュールは、デバイスとリンクを共有する各ＯＳインスタンスのエラー回復システムドライバモジュールへレジュームイベントを送る。

ステップ４３０において、各ＯＳインスタンスのエラー回復システムドライバは、レジュームイベントをデバイスドライバモジュールへ送って、デバイスをレジュームする。各ＯＳインスタンスのデバイスドライバモジュールは、ドライバによって制御されたデバイスをレジュームする。ステップ４３２において、ハイパーバイザモジュールは、各ＯＳインスタンスのエラー回復システムドライバに問い合わせて、デバイスがアクセス可能であるかどうかをチェックする。ステップ４３４において、各ＯＳインスタンスのエラー回復システムドライバは、ハイパーバイザモジュールの問い合わせをチェックする。デバイスがアクセス可能でない場合、ステップ４３６において、デバイスがアクセス可能でないことを検出したＯＳインスタンスのエラー回復システムドライバによって、回復失敗信号がハイパーバイザモジュールへ渡され、ハイパーバイザモジュールは、すべてのＯＳインスタンスのエラー回復システムドライバへサスペンドイベントを送り、リンクのリセットオペレーションを行う。次に、制御は、ステップ４４０において、エラー回復プロセスの完了を示すために転送される。ＯＳインスタンスのそれぞれのエラー回復システムドライバ（複数可）によってデバイスがアクセス可能であることが判明した場合、ステップ４３８において、信号がそれに従ってハイパーバイザへ送られ、デバイスの正常な機能がレジュームされる。次に、制御は、ステップ４４０においてエラー回復プロセスの完了を示すために転送される。

図５は、ハイパーバイザ環境についての本方法の実施５００の一例のブロック図をより詳細に示している。図５は、２つのＯＳインスタンス５１２及び５１２'を示している。しかしながら、当業者には、図５に示すハイパーバイザ環境は、３つ以上のＯＳインスタンスについて本方法を実施するように拡張可能であることが十分理解されよう。ハイパーバイザ環境は、２つのＯＳインスタンス５１２と５１２'との間を調整するハイパーバイザモジュール５１０を有する。ＯＳインスタンス５１２及び５１２'のそれぞれは、エラーイベントキューイングモジュール５１８及び５１８'、エラー回復システムドライバ５２０及び５２０'、健全性チェッカデーモン５２２及び５２２'、並びにデバイスドライバ５２４及び５２４'をそれぞれ有する。ＯＳインスタンス５１２及び５１２'の双方は、ハードウェアモジュール５５０を共有する。ハードウェア５５０は、デバイス１、デバイス２、デバイス３、デバイス４、及びデバイス５を含む。デバイス１はリンク１に結合され、デバイス２はリンク２に結合されている。デバイス３及びデバイス４はリンク３に結合され、デバイス５はリンク４に結合されている。本方法の実施態様は、以下でより詳細に説明される。

この技法の実施態様の以下の説明は、主として、２つのＯＳインスタンス５１２と５１２'との間で共有されるリンク３を参照する。リンク３は、２つのデバイス、すなわち、ＯＳインスタンス５１２における５２４のデバイスドライバ３によって制御されるデバイス３、及び、ＯＳインスタンス５１２'における５２４'のデバイスドライバ４によって制御されるデバイス４を有する。

各ＯＳインスタンス５１２及び５１２'の健全性チェッカデーモン５２２及び５２２'は、各ＯＳインスタンスの一部として、すべてのＩ／Ｏリンク上のＩ／Ｏエラー状態を定期的にチェックする。対応するデバイスを制御するデバイスドライバモジュール５２４及び５２４'のそれぞれは、その正常に機能している期間中にＩ／Ｏエラー状態を検出することもできる。この図は、ＯＳインスタンス５１２のデバイスドライバ３が、リンク３にアクセスしている間にエラーコードに遭遇する状況を示している。この段階は、図５に１として示され、ＯＳインスタンス５１２'の５２４'のデバイスドライバ４は、同じ共有リンク上のデバイス４にアクセスしている間にエラーに遭遇する（図５に１'として示す）。

ＯＳインスタンス５１２における５２４のデバイスドライバ３は、エラーイベントキューイングモジュール５１８にエラーイベントをキューイングし（２として示す）、ＯＳインスタンス５１２'の５２４'のデバイスドライバ４は、エラーイベントキューイングモジュール５１８'にエラーイベントをキューイングする（２'として示す）。ハイパーバイザモジュール５１０は、各エラーイベントキューイングモジュール５１８及び５１８'にリストされていた場合があるあらゆるエラーについて、ＯＳインスタンス５１２及び５１２'のそれぞれのエラーイベントキューイングモジュール５１８及び５１８'をチェックする。ハイパーバイザモジュール５１０は、１つ又は２つ以上のエラーがエラーイベントキューイングモジュール５１８にリストされていると判断した場合、エラーイベントの供給を受ける（３及び３'として示す）。ハイパーバイザモジュール５１０は、エラーイベントキューイングモジュール５１８／５１８'からエラーイベントを受け取ると、エラーに遭遇したリンクを共有しているＯＳインスタンスに関する詳細を求める。ハイパーバイザモジュール５１０は、すべてのＯＳインスタンスを見つけると、そのリンクをデバイス情報と共有するＯＳインスタンスのそれぞれのエラー回復システムドライバ５２０及び５２０'へサスペンドイベントを送る（４及び４'として示す）。

ＯＳインスタンス５１２及び５１２'のそれぞれのエラー回復システムドライバ５２０及び５２０'のそれぞれは、対応するＯＳインスタンスにおける５２４及び５２４'の各制御デバイスドライバへサスペンドイベントを送って、デバイス（複数可）をサスペンドする（５及び５'として示す）。各ＯＳインスタンス５１２及び５１２'のデバイスドライバ５２４及び５２４'（この例では、ＯＳインスタンス５１２のデバイスドライバ３及びＯＳインスタンス５１２'のデバイスドライバ４）は、それらによって制御される対応するデバイス（デバイス４及びデバイス３）をサスペンドする（６及び６'として示す）。このステップによって、共有リンク及びデバイスを使用しているすべてのＯＳインスタンスは、共通のサスペンドモードで機能不良のリンク／デバイスを見つけ、ＯＳインスタンスのいずれによってもそのリンクへアクセスは行われないことが確実にされる。次に、ハイパーバイザモジュール５１０は、エラーが発生したリンクのリセットを行うことにより、又は、リンクを再び機能させるために行うことが必要とされ得る他のオペレーションを行うことにより、エラー回復のステップに従う（７として示す）。リンクのリセットが成功すると、ハイパーバイザモジュール５１０は、サスペンドされたデバイスの正常なオペレーションをレジュームする命令を、対応するエラー回復システムドライバ５２０及び５２０'へ発行する（８及び８'として示す）。各ＯＳインスタンスのエラー回復システムドライバ５２０及び５２０'は、デバイスドライバ５２４及び５２４'へレジュームイベントを送って、デバイスをレジュームする（９及び９'として示す）。各ＯＳインスタンスのデバイスドライバ５２４及び５２４'は、それによって制御されるデバイスをレジュームする。このステップは、デバイスの再初期化及び正常なオペレーションのためにデバイスを準備することを伴うことができる（１０及び１０'として示す）。

本方法の別の態様によれば、本方法は、（回復プロセスにおける繰り返されるエラーにより）回復プロセスが無限ループとならないことを保証するメカニズムをサポートするエラー回復システムドライバ（５２０及び５２０'）を提供する。回復プロセスの終了時に、エラー回復システムドライバ（５２０及び５２０'）は、Ｉ／Ｏリンクの状態を検証する。Ｉ／Ｏリンクがエラー状態にあり、回復オペレーションが成功しなかったことを示している場合、エラー回復システムドライバ（５２０及び５２０'）は、そのリンク上のＩ／Ｏデバイスを制御するすべてのデバイスドライバ（５２４及び５２４'）をサスペンドする。一態様によれば、Ｉ／Ｏリンクが、自動回復が失敗したこのような状態にある場合、手動の回復プロセスを使用してＩ／Ｏリンクを回復することができる。この手動の回復プロセスは、Ｉ／Ｏデバイスのオンライン交換（ＯＬＲ）機能に酷似している。手動の回復プロセスでは、ユーザは、機能不良のＩ／Ｏデバイスを適切に機能するＩ／Ｏデバイスと交換して、システムをリブートする必要なくＩ／Ｏデバイスを再起動するオプションを提供される。

本方法の別の態様は、特定のＩ／Ｏデバイスのユーザが、回復プロセスを停止する前に、指定された時間区間内における繰り返されるＩ／Ｏエラーの最大回数のしきい値を指定することを可能にする。本方法／システムのさらに別の態様によれば、しきい値の決定又はデフォルトのしきい値の設定を行うことができる。さらに別の態様によれば、指定された時間区間における繰り返されるＩ／Ｏエラーの回数がしきい値の範囲内にある場合に、ソフトウェアには、各デバイスをチェックするメカニズムが提供される。この回数がしきい値を超えた場合、ソフトウェアは、そのデバイスに対して削除プロセスを起動する。このようなデバイスは、特別なタグが付けられて、その後のすべてのシステムリブートにおいて分離され、それによって、そのＩ／ＯデバイスからのＩ／Ｏエラーのさらなる発生の可能性がなくなる。ユーザは、機能不良のデバイスを、システムに対して適切に機能するデバイスと交換した後、システムコンフィギュレーションにデバイスを追加するオンライン追加（ＯＬＡ）オペレーションを使用することができる。

図１、図２、及び図４に示すフローチャートは、例示の実施形態において実質的に連続して配列されたステップを含むが、この主題の他の実施形態は、複数のプロセッサ、或いは、２つ又は３つ以上の仮想マシン又はサブプロセッサとして編成された単一のプロセッサを使用して、２つ又は３つ以上のステップを並列に実行することができる。その上、さらに他の実施形態は、２つ又は３つ以上の相互接続された特定のハードウェアモジュールであって、関連した制御信号及びデータ信号がそれらモジュール間で及びそれらモジュールを通じて通信される、ハードウェアモジュールとしてステップを実施することもできるし、特定用途向け集積回路の一部としてステップを実施することもできる。したがって、この例示のプロセスフロー図は、ソフトウェアの実施態様、ファームウェアの実施態様、及び／又はハードウェアの実施態様に適用することができる。

この解説は、図１、図２、及び図５を参照して説明した方法を実行できるコンピュータシステムをさらに提供する。この解説は、命令を含むコンピュータ可読媒体をさらに提供する。この命令は、コンピュータシステムで実行される場合、図１、図２、及び図５を参照して説明した方法を実施する。この解説は、コンピュータ可読媒体を含む製品をさらに提供する。

システムの入出力（Ｉ／Ｏ）リンク上のエラーをハンドリングするための方法及びシステムが提供される。リンクは、システムの複数のデバイスによって共有されている。本方法は、複数のオペレーティングシステムを有するシステム上でのエラーのハンドリングをサポートする。システムのコンフィギュレーションの期間中のエラーハンドリングの方法は、システムのコンフィギュレーションの期間中にエラーについてデバイスをチェックするステップと、エラーが検出された場合に、そのデバイスがコンフィギュレーションされることをサスペンドするステップとを含む。また、本方法は、エラーから回復するデバイスの能力を検査するステップと、デバイスがエラーから回復する能力を有する場合には、デバイスを第１のモードでコンフィギュレーションし、そうでない場合には、第２のモードでデバイスをコンフィギュレーションするか又はデバイスをコンフィギュレーションしないステップとを含む。さらに、エラーのハンドリングは、システムのランタイムの期間中も行うことができる。それを行うために、チェックするステップの後に、そのデバイスについて遭遇したエラーを示す数の値がしきい値よりも大きい場合には、デバイスを分離して削除するステップが続く。そうでない場合には、本方法は、デバイスの回復プロセスを起動して、回復プロセスの結果を報告するステップを提供する。

上記技法は、プロセッサによって制御される装置を使用して実施することができる。この場合、プロセッサには、上記技法の一態様を構成するコンピュータプログラムの形の命令が提供される。このようなコンピュータプログラムは、コンピュータ可読命令としてストレージ媒体に記憶することができ、その結果、ストレージ媒体は、本主題のさらなる態様を構成する。

上記説明は、限定的なものではなく、例示であることが意図されている。他の多くの実施形態が当業者には明らかであろう。したがって、この主題の範囲は、添付の特許請求の範囲が権利を有する均等物の全範囲と共に、添付の特許請求の範囲によって決定されるべきである。

本明細書に示すように、本主題は、さまざまな方法、回路、Ｉ／Ｏデバイス、システム、及び関連付けられた命令を有するマシンアクセス可能媒体を含む製品を含めて、多数の異なる実施形態で実施することができる。

当業者には、他の実施形態が容易に明らかであろう。これらの要素、アルゴリズム、オペレーションのシーケンスはすべて、特定の要件に応じて変えることができる。図１に示す方法に関して上述したオペレーションは、本明細書で図示して説明したものとは異なる順序で行うことができる。

図１〜図５は、単に具象描写したものに過ぎず、一律の縮尺で描かれていない。その一定の比率は誇張されている場合がある一方、他のものは最小にされている場合がある。図１〜図５は、当業者が理解でき且つ適切に実行できる、主題のさまざまな実施形態を示している。

本発明の実施形態の上記詳細な説明では、開示を能率化するために、さまざまな特徴が単一の実施形態において共にグループ化されている。この開示方法は、本発明の特許を請求する実施形態が、各請求項に明確に列挙されたものよりも多くの特徴を必要とするという意図を反映しているものと解釈されるべきではない。それとは逆に、添付の特許請求の範囲が反映しているように、独創的な発明は、開示された単一の実施形態のすべての特徴よりも少ない特徴に存在している。したがって、添付の特許請求の範囲は、これによって、本発明の実施形態の詳細な説明に組み込まれ、各請求項は、それ自体で、個々の好ましい実施形態として存在する。

本主題の一実施形態によるシステムのコンフィギュレーションの期間中のＩ／Ｏエラーをハンドリングするための方法を示すフローチャートである。 本主題の一実施形態によるシステムのランタイムの期間中のＩ／Ｏエラーをハンドリングするための方法を示すフローチャートである。 本主題の一実施形態によるＩ／Ｏエラーをハンドリングするための方法を実施するためのブロック図である。 本主題によるハイパーバイザ環境でＩ／Ｏエラーをハンドリングするための方法を実施している間に従うステップを示す一例のフロー図である。 本主題の一実施形態によるハイパーバイザ環境でＩ／Ｏエラーをハンドリングするための方法を実施するブロック図である。

符号の説明

３０２・・・エラー回復システムドライバ
３０４・・・健全性チェッカデーモン
３０６・・・デバイスドライバ
３１０・・・エラーイベントキューイングモジュール
３５０・・・ハードウェア部
２、３'、５'・・・エラーイベント
３・・・エラーイベントの供給
４、５・・・サスペンド
６・・・Ｉ／Ｏリンクのリセット
７、８・・・レジューム
５１０・・・ハイパーバイザモジュール
５１２、５１２'・・・ＯＳインスタンス
５１８、５１８'・・・エラーイベントキューイングモジュール
５２０、５２０'・・・エラー回復システムドライバ
５２２、５２２'・・・健全性チェッカデーモン
５２４、５２４'・・・デバイスドライバ
５５０・・・ハードウェア
１、１'、２、２'・・・エラーイベント
３、３'・・・エラーイベントの供給
４、４'、５、５'、６、６'・・・サスペンド
７・・・Ｉ／Ｏリンクのリセット
８、８'、９、９'、１０、１０'・・・レジューム

Claims (21)

1. システムの入出力（Ｉ／Ｏ）リンクのパリティエラーをハンドリングするための方法であって、
   前記リンクは、
   前記システムの複数のデバイスによって共有され、
   前記方法は、
   前記システムのコンフィギュレーションの期間中に１つ又は２つ以上のエラーについてデバイスをチェックするステップと、
   １つ又は２つ以上のエラーが検出された場合に、前記デバイスがコンフィギュレーションされることを制限し、前記チェックするステップを別のデバイスについて繰り返すステップと、
   エラーから回復する能力について前記デバイスを検査するステップと、
   前記デバイスが前記エラーから回復する能力を有する場合に、前記デバイスを第１のモードでコンフィギュレーションするステップと
   を含む方法。
2. 前記デバイスを検査するステップが、
   前記デバイスが前記エラーから回復する能力を有しないと判断した場合に、前記システムの起動時間優先度に従って前記デバイスを第２のモードでコンフィギュレーションすること
   をさらに含む、請求項１に記載の方法。
3. 前記デバイスを検査するステップは、
   前記デバイスのソフトウェアコードの有効性を確認するステップを含み、
   前記ソフトウェアコードは、
   前記デバイスのオペレーションを駆動するコードである、
   請求項１に記載の方法。
4. 前記デバイスをコンフィギュレーションするステップは、
   前記デバイスに識別子を供給するステップを含み、
   前記識別子は、
   コンフィギュレーションのモードを示すように構成されている、
   請求項１に記載の方法。
5. 前記デバイスをコンフィギュレーションするステップは、
   前記デバイスに識別子を供給するステップを含み、
   前記識別子は、コンフィギュレーションのモードを示すように構成されている、
   請求項２に記載の方法。
6. システムの入出力（Ｉ／Ｏ）リンク上のパリティエラーをハンドリングするための方法であって、
   前記リンクは前記システムの複数のデバイスによって共有され、
   前記方法は、
   前記システムのランタイムの期間中にエラーについてデバイスをチェックするステップと、
   前記デバイスについて遭遇したエラーを示す数の値がしきい値よりも大きい場合には前記デバイスを分離して削除し、前記チェックするステップを別のデバイスについて繰り返すステップと、
   前記デバイスの回復プロセスを起動するステップと、
   前記回復プロセスの結果を報告するステップと
   を含む方法。
7. 前記回復プロセスを起動するステップは、
   前記リンクに結合される１つ又は２つ以上のデバイスをサスペンドするステップと、
   前記デバイスが結合されているリンクをリセットするステップと、
   前記リンクに結合される１つ又は２つ以上のデバイスをレジュームするステップと
   を含む、請求項６に記載の方法。
8. 前記システムは、
   複数のオペレーティングシステムを含み、
   前記デバイスを分離して削除するステップは、
   前記デバイスを共有する前記オペレーティングシステムの詳細を収集するステップと、
   前記デバイスを分離して削除している間、前記デバイスを使用する前記オペレーティングシステムのそれぞれを調整して更新するステップと
   を含む、請求項６に記載の方法。
9. 前記回復プロセスを起動するステップは、
   前記デバイスを共有する前記オペレーティングシステムの詳細を収集することと、
   前記回復プロセスを実行している間、前記デバイスを使用する前記オペレーティングシステムのそれぞれを調整して更新することと
   を含む、請求項８に記載の方法。
10. 前記チェックするステップは、
    前記エラーをエラーイベントキューイングモジュールにリストすることと、
    前記リストされたエラーに従って前記個数をカウントすることと
    を含む、請求項６に記載の方法。
11. 前記調整して更新するステップは、
    ハイパーバイザによって実行される、
    請求項８に記載の方法。
12. 前記調整して更新するステップは、
    ハイパーバイザによって実行される、
    請求項９に記載の方法。
13. 前記チェックするステップは、
    健全性チェッカデーモンによって定期的に実行される、
    請求項６に記載の方法。
14. 前記チェックするステップは、
    前記デバイスのデバイスドライバを使用して実行される、
    請求項６に記載の方法。
15. コンピュータシステムであって、
    処理部と、
    前記処理部に結合され、システムの入出力（Ｉ／Ｏ）リンク上のパリティエラーをハンドリングするためのコードを記憶するメモリであって、
    前記コードは、
    前記システムの前記Ｉ／Ｏリンク上のパリティエラーをハンドリングするための方法を前記処理部に実行させ、
    前記Ｉ／Ｏリンクは、前記システムの複数のデバイスによって共有され、
    前記コードは、
    前記システムのコンフィギュレーションの期間中にエラーについてデバイスをチェックするステップと、
    エラーが検出された場合に、前記デバイスがコンフィギュレーションされることを制限し、前記チェックするステップを別のデバイスについて繰り返すステップと、
    エラーから回復する能力について前記デバイスを検査するステップと、
    前記デバイスが前記エラーから回復する能力を有する場合に、前記デバイスを第１のモードでコンフィギュレーションするステップと
    を含む
    メモリとを備える、コンピュータシステム。
16. コンピュータシステムであって、
    処理部と、
    前記処理部に結合され、システムの入出力（Ｉ／Ｏ）リンク上のパリティエラーをハンドリングするためのコードを記憶するメモリであって、
    前記コードは、
    前記システムの前記Ｉ／Ｏリンク上のパリティエラーをハンドリングするための方法を前記処理部に実行させ、
    前記Ｉ／Ｏリンクは、前記システムの複数のデバイスによって共有され、
    前記コードは、
    前記システムのランタイムの期間中にエラーについてデバイスをチェックするステップと、
    前記デバイスについて遭遇したエラーを示す数の値がしきい値よりも大きい場合には、前記デバイスを分離して削除し、前記チェックするステップを別のデバイスについて繰り返すステップと、
    前記デバイスの回復プロセスを起動するステップと、
    前記回復プロセスの結果を報告するステップと
    を含む
    メモリとを備える、コンピュータシステム。
17. 前記システムは、
    複数のオペレーティングシステムをハンドリングするようにコンフィギュレーションされている、
    請求項１６に記載のコンピュータシステム。
18. コンピュータシステムと共に動作可能なコンピュータ可読媒体であって、
    前記コンピュータ可読媒体には、前記コンピュータシステムによってサポートされるアーキテクチャシミュレータ環境と共に動作可能な命令が記憶され、
    前記媒体は、
    システムの入出力（Ｉ／Ｏ）リンク上のパリティエラーをハンドリングするための命令を含み、
    前記Ｉ／Ｏリンクは、
    前記システムの複数のデバイスによって共有され、
    前記命令は、
    方法を実行するように構成され、
    前記方法は、
    前記システムのコンフィギュレーションの期間中にエラーについてデバイスをチェックするステップと、
    エラーが検出された場合に、前記デバイスがコンフィギュレーションされることを制限し、前記チェックするステップを別のデバイスについて繰り返すステップと、
    エラーから回復する能力について前記デバイスを検査するステップと、
    前記デバイスが前記エラーから回復する能力を有する場合に、前記デバイスを第１のモードでコンフィギュレーションするステップと
    を含む、コンピュータ可読媒体。
19. 請求項１８に記載のコンピュータ可読媒体を備える製品。
20. コンピュータシステムと共に動作可能なコンピュータ可読媒体であって、
    前記コンピュータ可読媒体には、前記コンピュータシステムによってサポートされるアーキテクチャシミュレータ環境と共に動作可能な命令が記憶され、
    前記媒体は、
    システムの入出力（Ｉ／Ｏ）リンク上のパリティエラーをハンドリングするための命令を含み、
    前記Ｉ／Ｏリンクは、
    前記システムの複数のデバイスによって共有され、
    前記命令は、
    方法を実行するように構成され、
    前記方法は、
    前記システムのランタイムの期間中にエラーについてデバイスをチェックするステップと、
    前記デバイスについて遭遇したエラーを示す数の値がしきい値よりも大きい場合には前記デバイスを分離して削除し、前記チェックするステップを別のデバイスについて繰り返すステップと、
    前記デバイスの回復プロセスを起動するステップと、
    前記回復プロセスの結果を報告するステップと
    を含む、コンピュータ可読媒体。
21. 請求項２０に記載のコンピュータ可読媒体を備える製品。

Images