情報処理部と、前記情報処理部がリセットされたことを検出する手段と、前記情報処理部のログ情報を取得する取得手段と、前記取得手段が取得したログ情報を格納する複数のバッファと、前記リセットの検出前または検出後に、前記ログ情報が取得されないときに、前記取得手段が取得したログ情報の格納先となるバッファを切り替える制御部と、を備える情報処理装置。前記制御部は、前記ログ情報が出力されない期間が所定時間経過したか否かを検知する手段と、前記ログ情報が出力されない期間が所定時間経過した場合、ログ情報が出力される前に前記リセットが検出されたときに、前記ログ情報の格納先を切り替える手段と、を有する請求項1に記載の情報処理装置。前記制御部は、前記リセット検出後から所定の期間の経過前に、前記ログ情報が出力されないときに前記ログ情報の格納先を切り替える手段を有する請求項1または2に記載の情報処理装置。前記情報処理部からのタイマ初期化信号を所定周期で受信するとともに、前記所定周期内に前記タイマ初期化信号を受信できないときに前記所定周期の時間が経過したことを示す契機信号を発生する契機信号発生部をさらに備え、前記制御部は、前記契機信号にしたがって前記ログ情報の格納先を切り替える手段を有する請求項1から3のいずれか1項に記載の情報処理装置。コンピュータが、情報処理部がリセットされたことを検出するステップと、前記情報処理部のログ情報を取得する取得ステップと、前記取得したログ情報を複数のバッファのいずれかに格納するステップと、前記リセットの検出前または検出後に、前記ログ情報が取得されないときに、前記取得手段が取得したログ情報の格納先となるバッファを切り替える制御ステップと、を実行する情報処理方法。前記制御ステップは、前記ログ情報が出力されない期間が所定時間経過したか否かを検知するステップと、前記ログ情報が出力されない期間が所定時間経過した場合、ログ情報が出力される前に前記リセットが検出されたときに、前記ログ情報の格納先を切り替えるステップと、を有する請求項5に記載の情報処理方法。前記制御ステップは、前記リセット検出後から所定の期間の経過前に、前記ログ情報が出力されないときに前記ログ情報の格納先を切り替えるステップを有する請求項5または6に記載の情報処理方法。前記制御ステップは、前記情報処理部からのタイマ初期化信号を所定周期で受信するとともに、前記所定周期内に前記タイマ初期化信号を受信できないときに前記所定周期の時間が経過したことを示す契機信号を受けるステップと、前記契機信号にしたがって前記ログ情報の格納先を切り替えるステップと、を有する請求項5から7のいずれか1項に記載の情報処理方法。コンピュータに、情報処理部がリセットされたことを検出するステップと、前記情報処理部のログ情報を取得する取得ステップと、前記取得したログ情報を複数のバッファのいずれかに格納するステップと、前記リセットの検出前または検出後に、前記ログ情報が取得されないときに前記取得手段が取得したログ情報の格納先となるバッファを切り替える制御ステップと、を実行させるためのプログラム。前記制御ステップは、前記ログ情報が出力されない期間が所定時間経過したか否かを検知するステップと、前記ログ情報が出力されない期間が所定時間経過した場合、ログ情報が出力される前に前記リセットが検出されたときに、前記ログ情報の格納先を切り替えるステップと、を有する請求項9に記載のプログラム。前記制御ステップは、前記リセット検出後から所定の期間の経過前に、前記ログ情報が出力されないときに前記ログ情報の格納先を切り替えるステップを有する請求項9または10に記載のプログラム。前記制御ステップは、前記情報処理部からのタイマ初期化信号を所定周期で受信するとともに、前記所定周期内に前記タイマ初期化信号を受信できないときに前記所定周期の時間が経過したことを示す契機信号を受けるステップと、前記契機信号にしたがって前記ログ情報の格納先を切り替えるステップと、を有する請求項9から11のいずれか1項に記載のプログラム。しかし、実際に障害が発生した場合においては、障害の発生状況を示すメッセージが以下の要因によって上書きされ、コンソールログを活用できない場合がある。なお、障害の発生状況を示すメッセージを含むコンソールログを障害ログと呼ぶことにする。また、以下の要因はコンソールログに限られず、ログの格納先の容量が有限なコンピュータシステムでのログ取得時に生じ得る。aOS以外のアプリケーションにより多量メッセージが出力されることがある。bユーザ操作やシステム動作などによって、コンピュータが再起動し、再起動時のメッセージが出力される結果、バッファ上の障害ログが上書きされてしまうことがある。cコンピュータの使用状況により、バッファから障害ログを採取するまでに長時間経過することがある。その結果、コンピュータシステムの管理者、あるいは、障害解析のためのコンピュータプログラムが障害ログを採取する前に上記abが繰り返され、障害ログが上書きされることがある。一方、ログを蓄積するためのコンソールサーバを接続する、もしくはLANを経由して、コンソールデータを他のサーバに飛ばすSerialOverLANSOL機能を使用し、他のサーバにログを蓄積するなど、コンソールログの保存方法は存在する。しかし、コンソールサーバあるいはSOLでは専用装置を導入するため、保守費用の増加を伴う。また、コンソールサーバあるいはSOLを導入したとしても、得られるログの大半は正常動作時の無用なログである場合が多い。したがって、コンソールサーバあるいはSOLのような専用装置を配備しているユーザは少ない。また、障害の発生したコンピュータシステムから切り離されて障害ログが蓄積されるため、障害が発生したコンピュータと障害ログを結びつけるための仕組みが要求される。さらに、コンソールサーバあるいはSOLのような専用装置で得られる大量のログから障害発生時のメッセージを特定する作業は、困難を伴う場合がある。以上の問題をまとめると以下の通りである。1障害発生時に、コンピュータシステムからはコンソールログ等のログに、障害に関連するメッセージが出力される。しかし、ユーザ操作によるコンピュータシステムの起動操作、シャットダウン操作、障害復旧のためのシステム動作に等よりメッセージが出力されるため、障害に関連するメッセージが消えてしまう場合がある。2ログ蓄積用の専用装置を具備すると、費用が増加する。3障害発生時のログとその他のメッセージを識別するのが困難である。特に、今日のコンピュータシステムは、複数ベンダの装置、あるいは、コンピュータプログラムを含む。そして、異なるベンダが開発したOS、BIOS、その他のコンピュータプログラムが出力する障害メッセージは多種多様である。このようなコンピュータシステムの様々なメッセージから障害発生時のログを特定し、摘出することは困難な場合がある。そこで、開示の技術の一側面は、コンピュータシステム等の情報処理装置において、障害発生時のログ消失を抑制できるようにすることを目的とする。開示の技術の一側面は、以下の情報処理装置によって例示できる。本情報処理装置は、情報処理部と、情報処理部がリセットされたことを検出する手段と、情報処理部のログ情報を取得する取得手段と、取得手段が取得したログ情報を格納する複数のバッファと、リセットの検出前または検出後に、ログ情報が取得されないときに、前記取得手段が取得したログ情報の格納先となるバッファを切り替える制御部と、を備える。本情報処理装置によれば、障害発生時のログ消失を抑制できる。以下、図面を参照して本発明を実施するための最良の形態以下、実施形態というに係る情報処理装置について説明する。以下の実施形態の構成は例示であり、本情報処理装置は実施形態の構成には限定されない。図1から図10の図面を参照して、実施例1に係る情報処理装置9を説明する。図1は、実施例1に係る情報処理装置9の構成を例示する図である。情報処理装置9は、例えば、サーバと呼ばれる情報処理機能を提供するコンピュータである。また、情報処理装置9は、複数のコンピュータによるコンピュータシステムであってもよい。また、情報処理装置9は、コンピュータシステムに含まれる1つのコンピュータ、例えば、ブレードサーバと呼ばれるものであってもよい。さらに、情報処理装置9は、コンソールログを出力する装置であれば、その種類は問わない。例えば、情報処理装置9は、パーソナルコンピュータであってもよい。図1のように、情報処理装置9は、CentralProcessingUnitCPUと、メモリと、チップセット3と、チップセット3からのコンソールログのデータを受信するIOチップ4と、IOチップ4のシリアルコンソールポートからコンソールログのデータが出力されるコネクタRJ45コネクタ5と、チップセット3からのコンソールログのデータを受信するIntelligentPlatformManagementControllerIPMC1と、WatchdogTimerワッチドッグタイマ、WDT2とを有している。IPMC1は、サーバブレード等のコンピュータのハードウェアあるいはファームウェアの動作を管理するマイクロコントローラである。チップセット3は、CPU、メモリ等の各部間でのデータ授受に関わる処理を実行する。チップセット3は、例えば、入出力コントローラ等を含む。チップセット3は、例えば、IntelArchitectureIAチップセットである。ただし、情報処理装置9のチップセット3が、IAチップセットに限定される訳ではない。すなわち、情報処理装置9としての機能を提供できる構成であれば、どのようなチップセットであってもよい。チップセット3は、例えば、SPARCチップのアーキテクチャを含むものであってもよい。また、チップセット3は、機器組込用のプロセッサを含むものであってもよい。チップセット3、CPU、およびメモリ等が情報処理部の一例である。図1の例では、チップセット3は、IOチップ4、IPMC1に対して、コンソールログのデータ、およびリセット信号を出力する。コンソールログのデータは、CPU上のOS、BIOS、ミドルウェア、アプリケーションプログラム等のコンピュータプログラムが出力するメッセージを含むデータある。リセット信号は、チップセット3に含まれるリセット回路がCPUをリセットする信号である。リセット信号は、CPUの起動時に発せられ、CPUのハードウェアを初期状態にする。CPUは、リセット信号によって初期化された後に処理を開始し、例えば、BIOSの起動、OSのブート等を実行する。IOチップ4は、チップセット3からのコンソールログのデータを受信し、シリアルコンソールポートからRJ45コネクタ5に出力する。IOチップ4としては、SuperIOチップと呼ばれるものを例示できる。SuperIOチップは、種々のシリアルインターフェース、パラレルインターフェース、各種デバイスへのインターフェース等を組み合わせた入出力インターフェースである。ただし、情報処理装置9において、IOチップ4がSuperIOチップに限定される訳ではない。また、コンソールログの出力経路が、IOチップ4とRJ45コネクタ5に限定される訳ではない。例えば、テキスト情報をシリアルポートから出力できる仕様のものであれば、どのような構成でもよい。IPMC1は、情報処理装置9、例えば、ブレードサーバのハードウェア、ファームウェアの動作を管理するマイクロコントローラである。IPMC1は、チップセット3からコンソールログのデータを受信し、保存する処理を実行する。IPMC1は、コンソールログのデータを受信するデータポートDataと、リセット信号を受信するリセットポートRSTを有する。図1の例では、チップセット3に対して、IOチップ4とIPMC1とが並列に接続されている。しかし、情報処理装置9の構成が図1に限定される訳ではない。例えば、チップセット3に対して、IOチップ4とIPMC1とが直列に接続されてもよい。例えば、IPMC1が、IOチップ4のシリアルポートからコンソールログのデータを受信するようにしてもよい。逆に、IPMC1が、IOチップ4にコンソールログのデータを引き渡すようにしてもよい。WDT2は、チップセット3からの図示しないタイマ初期化信号を定期的に受けて、初期化される。そして、チップセット3からのタイマ初期化信号が所定期間受信できないときに、IPMC1に通知信号を送る。さらに、図1では、情報書処理装置9は、上位装置と接続されている。上位装置は、例えば、情報処理装置9および他の情報処理装置等を管理する管理用コンピュータ等である。情報処理装置9は、上位装置とは、例えば、NetworkInterfaceCardネットワークカード、NIC、FibreChannelファイバーチャネル、InfiniBandインフィニバンド等の通信インターフェースで接続される。なお、情報書処理装置9は、ハードディスク駆動装置等の外部記憶装置を有してもよい。また、情報書処理装置9は、CD、DVD、ブルーレイディスク、フラッシュメモリカード等の着脱可能記憶媒体の駆動装置を有してもよい。図2に、IPMC1の構成を例示する。IPMC1は、コンソールデータ受信部11と、切替スイッチ12と、バッファ13-0、13-1と、ログ読み出しコマンド受信部14とを有する。コンソールデータ受信部11は、チップセット3からコンソールログのデータを受信し、切替スイッチ12を介してバッファ13-0またはバッファ13-1に保存する。コンソールデータ受信部11は、IPMC1のデータポートDataへのコンソールログのデータ受信を監視し、受信したデータを取得する。また、コンソールデータ受信部11は、リセットポートへのリセット信号RSTの受信を監視する。ここで、リセット信号は、情報処理装置9が起動されたときにプロセッサが初期化されたことを示す。また、コンソールデータ受信部11は、タイマ113を有し、コンソールログの受信中の期間、コンソールログを受信しない期間、コンソールログを受信していないことを確認後リセット信号発生までの期間、あるいは、リセット信号受信後などの期間を計時する。そして、コンソールデータ受信部11は、例えば、コンソールログが所定期間取得されないときに切替スイッチ12を制御してコンソールログのデータ格納先をバッファ13-0とバッファ13-1との間で切り替える。すなわち、コンソールデータ受信部11は、コンソールログのデータ受信状態を監視し、データ受信が停止したこと、または受信データ量の変動が停止したこと等を契機にタイマ113により時間t1、t2等の計時をスタートする。以下、データ受信が停止したこと、または受信データ量の変動が停止したこと等を単にデータ変動の停止ともいう。時間t1はデータ変動の停止を確定するために計時する時間であり、予め設定可能な閾値以下、第1所定時間T1を越えてデータの変動が停止するかどうかの判定のために用いられる。時間t2はリセットの発生まで計時する時間である。時間t2については、例えば、データの変動停止が確認できた後に計時を開始すればよい。そして、時間t2は、データの変動停止後、予め設定可能な閾値以下、第2所定時間T2内にリセットが発生するかどうかを判定するために用いられる。さらに、コンソールデータ受信部11には、WatchdogTimer以下、WDT2からのトリガ信号が入力される。WDT2は、例えば、OSあるいはアプリケーションが異常となり、コンピュータがフリーズ状態となったことを検知するためのタイマである。WDT2は、例えば、IntelligentPlatformManagementInterfaceIPMIの機能の1つとして提供される。IPMIは、ハードウェアの構成やOSに依存することなく、サーバのハードウェア、あるいはネットワーク機器をモニタ可能にするための標準インターフェース仕様である。ただし、WDT2がIPMI仕様のものに限定される訳ではない。WDT2は、契機信号発生部の一例である。ログ読み出しコマンド受信部14は、チップセット3あるいは情報処理装置9の上位装置と接続されている。ログ読み出しコマンド受信部14は、チップセット3のCPUあるいは情報処理装置9の上位装置からログ読み出しコマンドを受信すると、バッファ13-0あるいはバッファ13-1のコンソールログをログ読み出しコマンド送信元に返信する。図3に、WDT2の構成を例示する。WDT2は、MAX値から所定周期ごとに値を減算するカウンタを有している。WDT2は、IPMC1およびチップセット3を介してCPU上のOS3Aからタイマ初期化信号を受け、カウンタをMAX値に設定する。そして、WDT2は、次のタイマ初期化信号を受けるまで、カウンタ値の減算を繰り返す。そして、カウンタ値がプレタイムアウト値に達すると、WDT2は、プレタイムアウト信号をIPMC1に供給する。実施例1では、プレタイムアウト信号は、例えば、情報処理装置9、OS、あるいはアプリケーションのフリーズの検知に使用される。プレタイムアウト値が所定周期の一例であり、プレタイムアウト信号が契機信号の一例である。例えば、OSあるいはアプリケーションに不具合が発生し、情報書処理装置9がフリーズすると、タイマ初期化信号がWDT2に供給されなくなる。すると、カウンタの減算が継続し、カウンタ値は、プレタイムアウト、さらにはタイムアウトとなる。タイムアウトとなると、タイムアウト信号がIPMC1に出力され、IPMC1は、OS、アプリケーションの不具合発生を検知する。一方、カウンタ値の減算が繰り返し実行されている間に、WDT2が次のタイマ初期化信号を受けると、WDT2は、カウンタ値をMAX値に再度設定する。WDT2の使用例としては、例えば、プレタイムアウトでOSへの割り込み等による監視対象での不具合発生の通知を例示できる。また、タイムアウトでリセット動作等による監視対象に対する復旧処理の起動が例示できる。以上のカウンタMAX値、プレタイムアウト値、タイムアウト値、OSによるタイマ初期化信号の発生周期は、外部から設定可能である。コンソールデータ受信部11は、IPMC1のCPUが実行するコンピュータプログラム、ファームウェア等の動作によって実現される。以下、IPMC1のCPUがコンソールデータ受信部11として、コンピュータプログラム、ファームウェア等により処理を実行することを、コンソールデータ受信部11が処理を実行するという。ただし、コンソールデータ受信部11は、コンソールログのデータ受信回路、およびタイマ113を含む専用デジタル回路であってもよい。切替スイッチ12は、切替スイッチ12の接続先と同期した切替レジスタにレジスタビットを持ち、ビットの書き替えにより切替スイッチ12の接続先を制御することが可能である。例えば、レジスタビット=0のとき、コンソールデータ受信部11とバッファ13-0とが接続される。また、レジスタビット=1のとき、コンソールデータ受信部11とバッファ13-1とが接続される。切替スイッチ12は、コンピュータプログラムとしてのスイッチでもよいし、ハードウェアのスイッチでもよい。コンピュータプログラムとしてのスイッチとしては、例えば、メモリ、レジスタ等に設定されたビットを判定し、コンソールログの出力先をバッファ13-0とバッファ13-1との間で切り替える処理部を例示できる。また、ハードウェアのスイッチとしては、レジスタビットに応じて、接続先を切り替えるデジタル回路、あるいは、トランジスタ等を含む回路を例示できる。バッファ13-0、13-1は、例えば、IPMC1のメモリ上の領域である。ただし、バッファ数が2面に限定される訳ではない。より具体的には、コンソールデータ受信部11は、切替スイッチ12、およびバッファ13-0、13-1を用いて以下の処理を実行する。1コンソールデータ受信部11は、切替スイッチ12により、バッファ13-0と13-1とを切り替えて、コンソールログのデータを保存する。通常のコンソールログは、1スクリーン分のデータは、80文字×25行=2048Bである。実施例1では、バッファ13-0、13-1は、コンソールログ1スクリーン分より大きなデータとする。例えば、バッファ13-0、13-1は、それぞれ6553664KB=32スクリーン分とする。2コンソールデータ受信部11は、例えば、バッファ13-0を初期のコンソールログ格納エリアとする。したがって、情報処理装置9の通常動作状態では、コンソールデータはバッファ13-0に記録されていくものとする。3バッファ13-0、13-1は受信したコンソールデータを初期アドレスより順次記録していき、記録したデータ量がバッファ容量の限界に達すると初期アドレスに戻って記録済みのデータに上書きしていくものとする。4切替スイッチ12は、コンソールデータ受信部11、すなわち、IPMC1のCPUの接続先をバッファ13-0、13-1の間で切り替える。ただし、切替スイッチ12は、3面以上のバッファを順次切り替えるようにしてもよい。5以上の構成を前提として、コンソールデータ受信部11は、以下の機能を有する。aコンソールデータ受信部11は、データ受信の有無および受信データの変動の有無を検知する。そして、コンソールデータ受信部11は、一定時間データの受信がない、もしくは受信データの変動がないことを検出する。ここで、受信データの変動がないとは、例えば、値0もしくは値1の受信データが継続して受信されることをいう。bコンソールデータ受信部11は、情報処理装置9の再起動時に発生するリセット信号の発生を検知する。cコンソールデータ受信部11は、aの発生から所定時間内にbを検知した場合に切替スイッチ12の切り替え契機を与える。より具体的には、コンソールデータ受信部11は、例えば、切替スイッチ12の切替レジスタのレジスタビットを反転する。dWDT2におけるプレタイムアウトによるプレタイムアウト信号を受信した場合に、コンソールデータ受信部11は、切替スイッチ12の切り替え契機を与える。6コンソールデータ受信部11が3にて設定したレジスタビットを元に切替スイッチ12が接続先をバッファ13-0とバッファ13-1の間で切り替える。7実施例1では、IPMC1は、格納したコンソールデータログを読み出すための別のポートを持ち、格納されたログはOSもしくは上位装置から読み出すことができる。8実施例1では、上の契機以外に、OSもしくは上位装置からIPMC1に対する専用コマンドを受信することにより切替スイッチ12のレジスタビットを更新することによっても、面切替が実行できる。図4に、コンソールデータ受信部11の詳細構成を例示する。コンソールデータ受信部11は、データ受信状態検出部111と、制御部112と、タイマ113とを有する。データ受信状態検出部111は、IPMC1のデータポートで受信したコンソールログのデータを監視し、データ受信の有無および受信データの変動の有無を検知する。そして、データ受信状態検出部111は、受信したコンソールログのデータをそのまま切替スイッチ12を通じてバッファ13-0、13-2に格納する。また、データ受信状態検出部111は、データ受信の有無および受信データの変動の有無を制御部112に通知する。データ受信状態検出部111は、ログ情報を取得する取得手段の一例である。制御部112は、データ受信状態検出部111からのデータ受信の有無および受信データの変動の有無受信状態信号を通知される。また、制御部112は、チップセット3からのリセット信号を受け付ける。そして、制御部112は、タイマ113によって、受信状態信号とリセットとの関係を判定し、バッファ13-0、13-1の切替タイミングを決定する。制御部112は、リセットを検出する手段およびログ情報を取得する取得手段の一例である。すなわち、制御部112は、受信状態信号により、aの発生、すなわち、第1所定時間T1の間、データの受信がない、もしくは受信データの変動がない場合に、タイマ113を起動する。第1所定時間T1が、ログ情報が出力されない期間の一例である。ここで、ログ情報が出力されないとは、例えば、受信データ量が0、すなわち、受信データなしの場合でもよい。また、ログ情報が出力されないとは、受信データが規定値以下の場合であってもよい。また、ログ情報が出力されないとは、受信データの変動がない場合であってもよい。また、ログ情報が出力されないとは、受信データの変動が規定値以下の場合であってもよい。受信データの変動が規定値以下とは、例えば、短時間あたりの変動ビット数が規定値以下として定義できる。そして、aの発生から第2所定時間T2以内にb、サーバ再起動時に発生するリセット信号を検知した場合に、制御部112は切替トリガを切替スイッチ12に供給する。切替トリガは、切替スイッチ12の接続先と同期したレジスタビットを反転させる。その結果、切替スイッチ12は、切替トリガに応じて、コンソールデータ受信部11とバッファ13-0、または、コンソールデータ受信部11とバッファ13-1を接続する。ただし、第1所定時間T1の経過後、さらに、第2所定時間T2が経過した場合には、再度abの処理が繰り返される。また、これらの処理の途中で、コンソールログが受信された場合には、abの処理は停止され、通常状態に戻る。以上の構成によって、第1所定時間T1の間、チップセット3からデータ受信がない、またはデータの変動がないことが確認された後、第2所定時間T2以内にリセット信号が入力されると、制御部112は、切替スイッチ12を切り替える。例えば、切替スイッチ12は、コンソールデータ受信部11の接続先をバッファ13-0からバッファ13-1に切り替える。以上の切替によって、異常発生前後のコンソールログを保存できる。図5に、サーバ停止処理実行時の処理フローを例示する。図5の処理は、例えば、ユーザによるシャットダウンコマンドの入力で開始する。シャットダウンコマンドの入力により、各種コンピュータプログラムが停止するS10。次に、周辺機器等の各種ハードウェアモジュール、およびハードウェアモジュールを駆動するドライバ等が停止するS11。なお、S11の処理の途中で、OSによるシステムログの取得、および保存が停止する。さらに、WDT2も停止する。次にOSが停止するS12。この処理では、シャットダウンコマンドの入力以降、所定時間あるいは所定量のコンソールログが取得され、OSが停止する。ただし、S11の処理で、OSのシステムログが保存されなくなった後に、情報処理装置9に異常が発生した場合が問題となる。この場合には、OSの停止前に、コンソールログの受信が途絶える。そこで、ユーザは、例えば、外部スイッチ等により情報処理装置9をリセットするS13。あるいは、情報処理装置9の例外処理等によって、情報処理装置9にリセットが指令される。その結果、情報処理装置9がリセットされ、再起動の後、再度シャットダウンコマンドの実行により、情報処理装置9が停止する。異常発生前、バッファ13-0には、シャットダウン時のコンソールログが異常発生まで蓄積されている。そして、異常発生によって、コンソールログの受信が停止する。さらに、上記、コンソールログを受信することなく、リセット信号を受信すると、情報処理装置9が再起動し、起動時のコンソールログが出力される。図6は、サーバ起動時の処理フローを例示する。図6の処理は、例えば、ユーザによるサーバ起動操作で開始する。サーバ起動操作により、まず、BIOSがロードされるS20。次に、PowerOnSelfTestPOSTが開始し、完了するS21。次に、MasterBootRecordがロードされ、さらに、BootLoaderが起動されるS22。次に、OSが起動開始するS23。次に、周辺機器等の各種ハードウェアモジュール、およびハードウェアモジュールを駆動するドライバ等が起動を開始するS24。なお、S24の処理の途中で、OSによるシステムログの取得、および保存が開始する。さらに、WDT2が起動される。次に、各種コンピュータプログラムの起動が開始するS25。ここで、S24以降は、OSがシステムログを記録する。したがって、S24の処理以降に異常が発生しても、異常発生の状況はシステムログに記録可能性がある。一方、S20からS24の間は、コンソールログが出力される。実施例1の処理は、S20からS24の間で異常が発生したときに、異常発生時のコンソールログを保存することを可能とする。そのため、情報処理装置9は、以下の処理を実行する。A情報処理装置9起動時のリセット後、第3所定時間T3に達するか否かを判定する。Bリセット後、第3所定時間T3に達する前に、データ受信の有無および受信データの変動の有無を検知する。そして、データ受信の有無および受信データの変動が第1所定時間T1の間継続すると、制御部112は、切替スイッチ12を切り替える。例えば、切替スイッチ12は、コンソールデータ受信部11の接続先をバッファ13-0からバッファ13-1に切り替える。その結果、図6において、S20からS24の間で、コンソールログが第1所定時間T1以上受信できない場合に、コンソールログが受信できなくなる前に受信済みのコンソールログを切替スイッチ12による切替前のバッファ13-0に保存できる。また、制御部112はWDT2からのプレタイムアウト信号を受信すると、切替トリガを切替スイッチ12に供給する。この場合には、WDT2によるプレタイムアウト信号受信前のコンソールログが、一方のバッファ、例えば、バッファ13-0に保存され、WDT2によるプレタイムアウト信号受信後のコンソールログが、他方のバッファ、例えば、バッファ13-1に保存される。図7は、WDT2によるプログラムの異常発生を検知する処理フローを例示する図である。情報処理装置9で実行中のプログラムに異常が発生し、情報処理装置9がフリーズすると、WDT2によるプレタイムアウトが発生するS30。この間、例えば、コンソールログは、バッファ13-0に蓄積される。そして、WDT2によるプレタイムアウトがOSに通知される。OSは、クラッシュダンプをコンソールログに出力するS31。なお、クラッシュダンプは、OSのシステムログにも記録される。その後、情報処理装置9は、ユーザ操作、あるいは、情報処理装置9の例外処理等によってリセットされS32、再起動される。実施例1の処理では、WDT2のプレタイムアウトによって、切替スイッチ12は、コンソールデータ受信部11の接続先をバッファ13-0からバッファ13-1に切り替える。以上の切替によって、異常発生前後のコンソールログをバッファ13-0に保存できる。図8に、通常稼働のシーケンスとシャットダウン時に異常が発生した場合のシーケンスとを比較して例示する。図8で、縦軸は、時間軸に相当する。また、図8の横軸方向には、情報処理装置9の構成要素、すなわち、バッファ13-0、13-1、切替スイッチ12、WDT2、IPMC1のコンソールデータ受信部11、およびチップセット3のCPUで実行されるOSとアプリケーションプログラムが例示されている。また、図8は、上下2つに分割されたシーケンスとなっている。図8の上側のシーケンスは、通常時、例えば、情報処理装置9の稼働中のシーケンスを示している。通常の稼働状態では、OSあるいはアプリケーションからコンソールログが出力され、コンソールデータ受信部11および切替スイッチ12を介して、バッファ13-0に出力される矢印A1。また、OSからWDT2に対して、タイマ初期化信号が送信される矢印A2。そして、例えば、コンソールデータ受信部11の制御部112がデータ受信なしあるいは受信データの変動なしを検知すると、タイマにより時間t1の計時を開始する。そして、時間t1が、第1所定期間T1を超えると、制御部112は、データ受信なしあるいは受信データの変動なしの状態であるとの判断を確定する。データ受信なしあるいは受信データの変動なしの状態であるとの判断を確定することを不通状態の確定という。ただし、図8では、タイマ113の計時する時間t1が、第1所定時間T1経過後、第2所定時間T2経過前に、情報処理装置9のリセットは発生しない。第2所定時間T2経過前に、情報処理装置9のリセットが発生しない場合、制御部112は、タイマ113を再設定し、時間t1の計時を時刻0から再開する。そして、制御部112は、再度、所定時間T1の経過による不通状態の確定と、第2所定時間T2経過前のリセットの発生を監視する。そして、図8の上側のシーケンスでは、第2所定時間T2経過後、不通状態が解除となり、データ送信が再開されている。その結果、制御部112は、データ受信を再開し矢印A3、情報処理装置9は、通常の稼働状態に戻っている。図8の下側のシーケンスは、シャットダウン時にエラーが発生した場合のシーケンスを示している。図8の下側のシーケンスでは、シャットダウンの指示、例えば、シャットダウンコマンドの投入により、OSからコンソールログが出力され、コンソールデータ受信部11および切替スイッチ12を介して、バッファ13-0に記録される矢印A4。ここでは、シャットダウンの実行中に、情報処理装置9の異常により、情報処理装置9がフリーズし、データ送信が停止された場合を想定する。データ送信が停止すると、タイマ113が起動され、時間t1が第1所定時間T1を超えると、制御部112は不通状態を確定する。すると、制御部112は、さらに、タイマ113を初期化し、時間t2を計時する。そして、時間t2が第2所定時間T2経過前に、リセットが発生すると矢印A5、制御部112は、切替スイッチ12を切り替える。すると、切替スイッチ12は、コンソールデータ受信部11の接続先をバッファ13-0からバッファ13-1に切り替える。すなわち、制御部112は、切替スイッチ12のレジスタビットを0から1に変更する。その結果、図8の下側のシーケンスにおいて、シャットダウン中のフリーズが発生する直前のコンソールログをバッファ13-0に維持できる。また、情報処理装置9がリセットされた後、復旧処理後のコンソールログは、バッファ13-1に出力される矢印A6。なお、再度時間t1の計時が開始された後、第1所定時間T1経過前に、リセットが発生すると、制御部112が切替スイッチ12を切り替えることなく、情報処理装置9は、起動時の状態に移行する可能性がある。しかしながら、第1所定時間T1を第2所定時間T2に比べて十分に短くすることで、不通状態の確定と、第2所定時間T2経過前のリセットの発生検出によるバッファ13-0、13-1の切替を実行できる可能性を高めることができる。図9は、情報処理装置9の起動によるリセット後のシーケンスを例示する。図9の上側は、情報処理装置9での異常のない通常状態でのシーケンスを例示する。すなわち、情報処理装置9のリセット後、OSあるいはアプリケーションからコンソールログが出力され、コンソールデータ受信部11および切替スイッチ12を介して、バッファ13-0に出力される矢印A7。また、さらに、WDT2が起動され、OSからWDT2に対して、タイマ初期化信号の送信が開始される矢印A8。そして、OSあるいはアプリケーションからコンソールログは、例えば、第3所定時間T3を経過したところで、停止する矢印A9。コンソールログが停止するのは、情報処理装置9のリセット後、所定の起動処理は、第3所定時間T3程度で完了するからである。第3所定時間T3以降、情報処理装置9は、通常の稼働状態となり、例えば、ユーザからの指示を待つ。一方、図9の下側は、情報処理装置9の起動時に、異常が発生したシーケンスを例示する。図9の下側のシーケンスでは、情報処理装置9のリセット後、第3所定時間T3経過前に、コンソールログのデータ送信が停止する矢印A10。矢印A10は、データ送信停止直前のコンソールログの送信を例示している。コンソールログのデータ送信が停止すると、データ受信状態検出部111は、制御部112に、コンソールログのデータ受信停止を通知する。すると、制御部112は、タイマ113により時間t1の計時を開始する。そして、コンソールログのデータ受信停止期間、すなわち、時間t1が第1所定時間T1を経過すると、制御部112は、不通状態が確定したと判定する。そこで、制御部112は、切替スイッチ12を切り替える。すると、切替スイッチ12は、コンソールデータ受信部11の接続先をバッファ13-0からバッファ13-1に切り替える。すなわち、制御部112は、切替スイッチ12のレジスタビットを0から1に変更する。その後、情報処理装置9の例外処理、あるいは、ユーザ動作によって、情報処理装置9がリセットされる。リセットによる復旧処理後のコンソールログは、バッファ13-1に出力される矢印A11。図10に、WDT2がOSまたはアプリケーションのフリーズ状態を検出した場合のシーケンスを例示する。OSまたは情報処理装置9で実行中のアプリケーションがフリーズすると、図3で説明したように、例えば、WDT2のプレタイムアウトが発生する。WDT2は、プレタイムアウトの発生を制御部112に通知する。すると、制御部112は、切替スイッチ12のレジスタビットを0から1に変更する。その結果、切替スイッチ12は、コンソールデータ受信部11の接続先をバッファ13-0からバッファ13-1に切り替える。一方、プレタイムアウトによって、WDT2は、OSに割り込みをかける。すると、OSは、クラッシュダンプを出力し、情報処理装置9をリセットする。したがって、クラッシュダンプおよび情報処理装置9のリセットによる復旧後のコンソールログは、バッファ13-1に出力される。その結果、OSあるいはアプリケーションがフリーズ直前のコンソールログは、バッファ13-0に保持される。ただし、OSが障害によって情報処理装置9をリセットすることができない場合には、WDT2は、プレタイムアウトからさらに進行し、タイムアウトを発生する。WDT2はタイムアウトを発生すると、OSに代わって、情報処理装置9をリセットする。WDT2によるリセットの結果、情報処理装置9は、再起動され、復旧処理を開始する。<処理フロー>図11および図12に、IPMC1の制御部112の処理フローを例示する。また、IPMC1のCPUは、ROM上のファームウェア、コンピュータプログラム等を主記憶装置にローディングし、制御部112として機能する。なお、図11で、開始以降の処理は、情報処理装置9の起動が完了し、通常動作している状態を例示する。情報処理装置9の通常動作状態で制御部112は、WDT2からのプレタイムアウトを確認するS101。そして、WDT2からのプレタイムアウトの通知があった場合、制御部112は、図12のS118に制御を進める。制御部112は、契機信号にしたがってログ情報の格納先を切り替える手段として、S101、S118の処理を実行する。ただし、WDT2は、プレタイムアウトを制御部112に割り込みで通知するようにしてもよい。割り込みによる通知の場合には、制御部112は、S101で、プロタイムアウトを確認することなく、割り込みがあった場合に図17のS118を実行すればよい。割り込みがあった場合にとは、例えば、割り込みがあったときに起動される割り込みハンドラ等によって、制御部112の制御をS118に進める、という意味である。一方、WDT2からのプレタイムアウトの通知がない場合、制御部112は、時間t1計時のため、タイマ113を初期設定するS102。そして、制御部112は、リセットが発生したか否かを判定するS103。制御部112は、リセットを検出する手段の一例として、S103の処理を実行する。ここで、リセットとは、例えば、情報処理装置9起動時に、チップセット3のCPUから発せられる初期化の指令である。リセットが発生した場合、制御部112は、制御をS112に進める。S112以降では、リセット発生時の処理、すなわち、情報処理装置9起動時の処理が実行される。また、S103の判定で、リセットが発生していない場合、制御部112は、チップセット3からのデータ線が不通状態か否かを判定するS104。不通状態か否かは、図4のデータ受信状態検出部111から制御部112に通知される。そして、データ線が不通状態でない場合、制御部112は、制御をS101に戻す。一方、データ線が不通状態の場合、制御部112は、タイマ113の計時時間t1が第1初期値T1を経過したか否かを判定するS105。そして、タイマ113の計時時間t1が第1初期値T1を経過していない場合、制御部112は、制御をS104に戻し、再度データ線の不通状態を確認する。S04-S105の処理によって、第1所定時間以上不通状態が継続した場合に、制御部112は、不通状態を認識する。制御部112は、ログ情報が所定以上出力されない期間の経過を検知する手段の一例として、S104、S105の処理を実行する。また、S105の判定で、タイマ113の計時時間t1が第1初期値T1を経過した場合、制御部112は、制御部112内の状態レジスタを不通状態に設定するS106。そして、制御部112は、図12のS107に制御を進める。そして、制御部112は、時間t1計時のため、タイマ113を初期設定するS107。次に、制御部112は、リセットの発生を監視するS108。制御部112は、リセットを検出する手段の一例として、S108の処理を実行する。そして、リセットが発生しない場合、制御部112は、データ線が不通状態か否かを判定するS109。そして、データ線が不通状態にないとき、すなわち、チップセット3からのコンソールログが受信されたとき、制御部112は、制御をS107に戻す。また、S109の判定で、データ線が不通状態のとき、制御部112は、タイマ113の計時する時間t1が第2所定時間T2を経過したか否かを判定する。そして、時間t1が第2所定時間T2を経過していない場合、制御部112は、制御をS108に戻し、リセットの発生を監視する。一方、時間t1が第2所定時間T2を経過した場合、制御部112は、状態レジスタの不通状態を解除するS111。そして、制御部112は、制御をS101に戻す。つまり、リセットが発生せずに、時間t1が第2所定時間T2を経過した場合には、制御部112は、S101からの処理を始めから繰り返す。また、S108の判定で、リセットの発生が確認された場合、制御部112は、切替スイッチ12によりバッファ13-0と13-1の接続を切り替えるS118。すなわち、コンソールデータ受信部11の接続先をバッファ13-0と13-1との間で、入れ替える。制御部112は、ログ情報が所定以上出力される前にリセットが検出されたときに、ログ情報の格納先を切り替える手段として、S108、S118の処理を実行する。また、図11のS103の判定で、リセット発生が確認された場合、情報処理装置9は、S112以降の情報処理装置9の起動中の処理を実行する。すなわち、制御部112は、時間t1を計時するタイマ113を初期設定するS112。そして、制御部112は、データ線が不通状態か否かを判定するS113。そして、データ線が不通状態でない場合、制御部112は、制御をS112に戻す。したがって、リセット発生後、データが不通状態にならない限り、時間t1の初期化が、所定の時間間隔で実行される。ただし、情報処理装置9のリセット後、所定量のコンソールログが出力された後、情報処理装置9が通常の稼働状態になると、コンソールログの出力はなくなる。すなわち、S113の判定で、データ線が不通状態になると、次に制御部112は、時間t1が第1所定時間T1を経過したか否かを判定するS114。そして、時間t1が第1所定時間T1を経過していない場合、制御部112は、制御をS113に戻し、データ線の不通を確認するS113。S113-S114の処理によって、第1所定時間以上不通状態が継続した場合に、制御部112は、不通状態を認識する。そして、S114の判定で、時間t1が第1所定時間T1を経過した場合、制御部112は、状態レジスタを不通状態に設定するS115。次に、制御部112は、データ線の不通を確認するS116。そして、データ線が不通状態でない場合、制御部112は、制御をS107に進める。そして、制御部112は、S107以降の通常稼働中にシャットダウンが指示された場合の動作に備える。一方、S116の判定で、データ線が不通状態である場合、制御部112は、時間t1が第3所定時間T3を経過したか否かを判定するS117。そして、時間t1が第3所定時間Tを経過した場合、制御部112は、制御をS116に戻し、データ線の不通状態を確認する。時間t1が第3所定時間Tを経過した場合には、リセット後のコンソールログの出力が完了したと考えてよい。したがって、制御部112は、再度データ線の不通状態を確認するのである。また、S117の判定で、時間t1が第3所定時間Tを経過していない場合、制御部112は、制御をS118に進め、バッファを切り替える。S117の判定で、時間t1が第3所定時間Tを経過していない場合には、リセット発生後、本来出力されるコンソールログが出力される前に、データ線が不通状態となり、不通状態の継続期間が第1所定時間T1に達したと判定されたからである。制御部112は、リセット検出後の所定期間経過前に、ログ情報が所定以上出力されないときにログ情報の格納先を切り替える手段として、S117、S118の処理を実行する。以上述べたように、実施例1の情報処理装置9によれば、制御部112は、第1所定時間T1以上、データ線を通じたチップセット3からIPMC1のデータポートへのコンソールログの不通状態が継続することを確認する。そして、不通状態確認後、制御部112は、情報処理装置9でのリセット発生を監視し、リセットが発生すると、切替スイッチ12によって、コンソールデータ受信部11の出力先を、例えば、バッファ13-0からバッファ13-1に切り替える。したがって、不通状態となる前にバッファ13-0に出力されていたコンソールログをバッファ13-0に保持する一方、リセット後のコンソールログをバッファ13-1に蓄積できる。このような処理によって、不通状態になった後に、情報処理装置9の例外処理、あるいは、ユーザの動作によって、情報処理装置9がリセットし、復旧処理が実施される場合でも、不通状態になる前のコンソールログ、つまり、障害発生時のコンソールログを保存できる。さらに、制御部112は、不通状態確認後のリセットの監視を第2所定時間T2まで継続し、第2所定時間経過後は、再度不通状態が第1所定時間T1継続するか否かを確認する。したがって、情報処理装置9が通常稼働中に、コンソールログが第1所定時間T1以上継続し、その後、コンソールログが出力された場合には、バッファ13-0とバッファ13-1の切替を抑制できる。バッファ切替を抑制する理由は、正常な通常処理でのコンソールログを複数のバッファを切り替えて保存しなくてもよいからである。すなわち、情報処理装置9によれば、本来取得したい障害発生時のログと、その障害発生時以降の復旧処理でのログを効果的に分離して格納できる。また、情報処理装置9によれば、情報処理装置9の起動後、第3所定時間T3の経過前に、第1所定時間T1以上、コンソールログの不通状態が継続する否かを確認する。そして、第1所定時間T1以上、コンソールログの不通状態が継続すると、制御部112は、不通状態を確認する。そして、不通状態確認後、制御部112は、切替スイッチ12によって、コンソールデータ受信部11の出力先を、例えば、バッファ13-0からバッファ13-1に切り替える。このようなバッファ13-0からバッファ13-1への切り替えによって、情報処理装置9の起動に伴うリセット時の不通状態からの復旧処理、例えば、リセットが行われた場合でも、起動後の障害発生時のコンソールログを例えば、バッファ13-0に保存し、復旧処理に伴うコンソールログをバッファ13-1に出力できる。したがって、情報処理装置9は、不通状態となる前にバッファ13-0に出力されていたコンソールログをそのまま保持にできる。また、第3所定時間T3の経過後に、制御部112は、通常稼働時のコンソールログの不通状態を確認する処理に移行する。第3所定時間T3の経過後は、情報処理装置9の起動によるリセット時のコンソールログが正常に出力されたと考えることができるからである。ただし、第3所定時間T3の経過の有無に関わらず、不通状態を確認するようにしてもよい。この場合には、シャットダウン時の不通状態の監視処理と、起動時の不通状態監視処理を同一の処理で実行できる。さらに、情報処理装置9によれば、制御部112は、WDT2によって、OSあるいはアプリケーションプログラムによる情報処理装置9のフリーズ、あるいは、コンソールログの不通を監視する。そして、WDT2からの通知があると、制御部112は、切替スイッチ12によって、コンソールデータ受信部11の出力先を、例えば、バッファ13-0からバッファ13-1に切り替える。したがって、情報処理装置9によれば、不通状態からの復旧処理、例えば、情報処理装置9のリセットに伴うコンソールログがバッファ13-1に出力されるので、不通状態となる前にバッファ13-0に出力されていたコンソールログをそのまま保持にできる。図13-図16を参照して、実施例2に係る情報処理装置9を説明する。実施例1では、チップセット3からIPMC1のデータポートへのデータ線を通じたコンソールログの不通状態等をタイマ113、WDT2等の計時により確認した。実施例2では、時間の代わりに、チップセット3からIPMC1のデータポートへのデータ線を通じたコンソールログのデータ量、例えば、単位時間あたりのデータ転送量によって、不通状態等を確認する。コンソールログのデータ量によって、不通状態等を確認する点以外の処理については、第2実施形態の構成要素は、第1実施形態の構成要素と同様である。そこで、第1実施形態と同一の構成要素については、同一の符号を付して説明を省略する。例えば、情報処理装置9の構成は、図1と同様であるので、その説明は省略する。ただし、実施例2では、情報処理装置9は、IPMC1に代えて、IPMC1Aを有する。図13に、実施例2に係るIPMC1Aの構成を例示する。図13のように、IPMC1Aは、コンソールログ受信部11に代えて、コンソールログ受信部11Aを有する点が、実施例1の図2と相違する。図14に、実施例に係るコンソールデータ受信部11Aの構成を例示する。図14のように、コンソールデータ受信部11Aは、制御部112およびタイマ113に代えて、制御部112Aおよびカウンタ113Aを有する点が実施例1のコンソールデータ受信部11と相違する。すなわち、コンソールデータ受信部11Aは、タイマ113で計時する代わりに、カウンタ113Aによって、データ線を通じたチップセット3からデータポートへの受信データ量を監視することで、不通状態等の確認と解除を行う。図15に、通常稼働のシーケンスとシャットダウン時に異常が発生した場合のシーケンスとを比較して例示する。図15においても、実施例1の図8と同様に、OSあるいはアプリケーションからコンソールログが出力され、コンソールデータ受信部11および切替スイッチ12を介して、バッファ13-0に出力される矢印A1。また、OSからWDT2に対して、タイマ初期化信号が送信される矢印A2。ただし、実施例2では、例えば、コンソールデータ受信部11の制御部112がデータ受信なしあるいは受信データの変動なしを検知すると、制御部112は、カウンタ113Aをクリアする。そして、制御部112は、カウンタ113Aのクリア後、コンソールログの受信バイト数をカウントする。そして、受信バイト数が、第1基準バイト数C1未満の受信バイト数であるか否かを判定する。制御部112は、カウンタ113Aクリア後の受信バイト数が、C1バイト未満のとき、チップセット3からのデータ線を通じたコンソールログの不通状態が継続していると判定する。その後、受信バイト数が増加し、受信バイト数がC2バイトに達した場合には、制御部112は、バッファ13-0と13-1との切替を実行しない。通常の稼働状態であると判断できるからである。すなわち、図15の上側のシーケンスでは、C2バイト以上を受信後、不通状態が解除となり、データ送信が再開されている。その結果、制御部112は、データ受信を再開し矢印A3、情報処理装置9は、通常の稼働状態に戻っている。図15の下側のシーケンスは、シャットダウン時にエラーが発生した場合のシーケンスを示している。図15の下側のシーケンスでは、シャットダウンの指示、例えば、シャットダウンコマンドの投入により、OSからコンソールログが出力され、コンソールデータ受信部11および切替スイッチ12を介して、バッファ13-0に出力される矢印A4。そして、実施例1の図8と同様、シャットダウンの実行中に、情報処理装置9の異常により、情報処理装置9がフリーズし、データ送信が停止された場合を想定する。すると、制御部112は、カウンタ113Aをクリアし、受信バイト数が第1基準バイト数C1未満であるか否かを判定する。そして、受信バイト数が第2基準バイト数C2に達するまで、制御部112は、リセットの発生を監視する。そして、受信バイト数が第2基準バイト数C2に達する前に、リセットが発生すると矢印A5、制御部112は、切替スイッチ12を切り替える。すると、切替スイッチ12は、コンソールデータ受信部11の接続先をバッファ13-0からバッファ13-1に切り替える。すなわち、制御部112は、切替スイッチ12のレジスタビットを0から1に変更する。その結果、図15の下側のシーケンスにおいて、シャットダウン中のフリーズが発生する直前のコンソールログをバッファ13-0に維持できる。また、情報処理装置9がリセットされた後、復旧処理後のコンソールログは、バッファ13-1に出力される矢印A6。以上の説明では、不通状態をカウンタ113Aクリア後の受信バイト数が、第1基準バイト数C1未満の間と定義し、リセット発生の監視を受信バイト数が第2基準バイト数C2に達するまで行うとした。このようなバイト数に判断を短時間あたりの受信バイト数で行ってもよい。すなわち、制御部112がデータ受信なしあるいは受信データの変動なしを検知すると、単位時間あたりの受信バイト数が、第1基準バイト数C1未満であるか否かを判定し、不通状態の継続を確認してもよい。また、制御部112は、不通状態の継続を確認後、単位時間あたりの受信バイト数が、第2基準バイト数C2に達するまで、リセットの発生を監視してもよい。そして、一旦、単位時間あたりの受信バイト数が、第2基準バイト数C2に達した場合には、再度、データ受信なしあるいは受信データの変動なしを検知するようにしてもよい。逆に、単位時間あたりの受信バイト数が、第2基準バイト数C2に達しない場合に、リセット発生の監視を継続してもよい。以上述べたように、受信バイト数の確認によって、実施例1と同様、あるいは、実施例1よりもさらに厳密に、不通状態の継続判定ができる。その結果、不通状態となる直前のコンソールログを例えば、バッファ13-0に保存し、不通状態でリセットが発生し、復旧後のコンソールログをバッファ13-1に出力できる。図16に、通常稼働のシーケンスと起動時に異常が発生した場合のシーケンスとを比較して例示する。図16の上側のシーケンスでも、実施例1の図9と同様に、情報処理装置9のリセット後、OSあるいはアプリケーションからコンソールログが出力され、コンソールデータ受信部11および切替スイッチ12を介して、バッファ13-0に出力される矢印A7。また、さらに、WDT2が起動され、OSからWDT2に対して、タイマ初期化信号の送信が開始される矢印A8。そして、OSあるいはアプリケーションからコンソールログは、例えば、第3所定基準バイト数C3以上受信した場合には、制御部112は、情報処理装置9が正常に起動されたと判定する。そのため、制御部112は、バッファ13-0とバッファ13-1の切替を実行しない。一方、図9の下側は、情報処理装置9の起動時に、異常が発生したシーケンスを例示する。図9の下側のシーケンスでは、情報処理装置9のリセット後、第3基準バイト数C3の受信前に、コンソールログのデータ送信が停止する矢印A9。矢印A9は、データ送信停止直前のコンソールログの送信を例示している。すなわち、制御部112がデータ受信のなしあるいは受信データの変動のなしを検知すると、制御部112は、カウンタ113Aをクリアする。そして、制御部112は、カウンタ113Aクリア後の受信バイト数が、第1基準バイト数C1未満の受信バイト数であるか否かを判定する。制御部112は、カウンタ113Aクリア後の受信バイト数がC1バイト未満のとき、チップセット3からのデータ線を通じたコンソールログの不通状態が確定したと判定する。そこで、制御部112は、切替スイッチ12を切り替える。すると、切替スイッチ12は、コンソールデータ受信部11の接続先をバッファ13-0からバッファ13-1に切り替える。すなわち、制御部112は、切替スイッチ12のレジスタビットを0から1に変更する。その後、情報処理装置9の例外処理、あるいは、ユーザ動作によって、情報処理装置9がリセットされる。リセットによる復旧処理後のコンソールログは、バッファ13-1に出力される矢印A10。以上述べたように、受信バイト数のカウント113Aによって、実施例1と同様、あるいは、実施例1よりも厳密に、コンソールログの不通状態を検知できる。したがって、情報処理装置9の起動時の異常を検知し、不通状態となる直前のコンソールログを、例えばバッファ13-0に保存し、不通状態でのリセット時、および異常からの復旧後のコンソールログをバッファ13-1に出力できる。なお、図16の処理でも、第1基準バイト数C1あるいは第3基準バイト数の判断を単位時間あたりの受信バイトと比較して、不通状態の継続、あるいは、起動処理の正常終了等を判定してもよい。<コンピュータが読み取り可能な記録媒体>IPMC1で例示されるコンピュータその他の機械、装置以下、コンピュータ等に上記いずれかの機能を実現させるプログラムをコンピュータ等が読み取り可能な記録媒体に記録することができる。そして、コンピュータ等に、この記録媒体のプログラムを読み込ませて実行させることにより、その機能を提供させることができる。ここで、コンピュータ等が読み取り可能な記録媒体とは、データやプログラム等の情報を電気的、磁気的、光学的、機械的、または化学的作用によって蓄積し、コンピュータ等から読み取ることができる記録媒体をいう。このような記録媒体のうちコンピュータ等から取り外し可能なものとしては、例えばフレキシブルディスク、光磁気ディスク、CD-ROM、CD-R/W、DVD、ブルーレイディスク、DAT、8mmテープ、フラッシュメモリなどのメモリカード等がある。また、コンピュータ等に固定された記録媒体としてハードディスクやROMリードオンリーメモリ等がある。