第2章 |
|
この章では、SMS 1.5 における既知のバグだけでなく、UltraSPARC IV+ プロセッサをサポートする SMS のパッチで修正されているバグについても説明します。この章では、以下の項目を説明します。
この節では、SMS 1.5 ソフトウェアのバグと、UltraSPARC IV+ プロセッサをサポートする SMS のパッチで修正されている関連バグの一覧を示します。
パッチ 120843-01 は、UltraSPARC IV+ プロセッサを含めるよう、OpenBoot PROM のエラー処理および回復機能を強化しています。
カードをスロット 1 (c5v0) にホットプラグし、システムを再起動すると、prtdiag はカードが装備されたスロットの正しいバス周波数を表示していましたが、そのほかの空スロットのバス周波数の報告が正しくありませんでした。このバグはパッチ 120843-01 で修正されています。
デュアルコア UltraSPARC IV+ ボードが装備されている Sun Fire E25K/E20K システムでは、診断レベル 64、96、または 127 で lpost が失敗する場合があります。失敗した場合、lpost は次のエラーメッセージを返します。
UltraSPARC IV+ ボードをサポートするには、SMS 1.5 の hpost を変更する必要があります。パッチ 120648-02 がこの変更を行います。
UltraSPARC IV+ ボード上で Solaris 9 4/04 OS を実行する Sun Fire E25K/E20K システムは、時として、UltraSPARC IV+ ボード上のドメインをリブートするとタイムアウトになります。システムは次のエラーメッセージを返します。
Proccore SB0/P0/C0 timed out on test Domain Advanced Tests id=0x6F. Test Failed.FAIL Proccore SB0/P0/C0: test_seq_cwd(): failed out of config on timeout (Timeout Secs Given: 30) |
カスタマシステム向けにリリースされた最初の UltraSPARC IV+ プロセッサは、バージョン 2.1.1 です。パッチ 120648-02 は POST を変更して、カスタマが使用するには適さない初期バージョンの 2.1 プロセッサを検出し、構成から除外します。
バージョン 2.1 と 2.1.1 の MaskID はいずれも 2.1 のため、MaskID では両者を区別できないことに注意してください。POST は、そのほかの電気的に読み取り可能な情報に基づいてバージョンを区別します。
このバグは、1500 MHz の UltraSPARC IV+ ボードにのみ該当します。時として、
-m-1 オプションを付けて marginvoltage コマンドを使用すると、正しくない値が返されます。数秒後このコマンドを再度発行すると、正しい値が返されます。このバグはパッチ 120789-01 で修正されています。
このバグは、1500 MHz の UltraSPARC IV+ ボードにのみ該当します。
-m-1 オプションまたは -m+1 オプション付きで marginvoltage コマンドを使用すると、システムは正しくない出力形式を返します。たとえば、-m+1 コマンドを使用すると、UltraSPARC IV+ ボード上では Nom+3% (voltage) ではなく、Nom (voltage) という変更された値が返されますが、UltraSPARC IV および UltraSPARC III ボードでは同じコマンドで正しい出力が返されます。パッチ 120789-01 がこの問題を修正します。
UltraSPARC IV+ プロセッサには、UltraSPARC IV および III+ プロセッサを上回る、追加のエラー検出および RAS 機能が含まれます。この CR では、UltraSPARC IV+ が報告できる新しいエラーを診断するための Availability 機能に対する拡張機能が説明されています。この拡張機能により、Availability は、すべてのプロセッサタイプのすべての致命的なエラーだけでなく、Solaris 9 ドメインの致命的ではないエラーも診断します。パッチ 120827-01 がこの拡張機能を提供します。
UltraSPARC IV+ チップには 3 つのレベルのキャッシュがあります。レベル 2 および 3 はデータキャッシュを参照します。レベル 2 はプロセッサの内部にあり、レベル 3 はプロセッサの外部にあります。
エラーが、副作用として追加のエラーを発生させることがあります。データキャッシュのいずれかのレベルでエラーが発生した場合、Availability ソフトウェアはエラーの根本原因を診断し、副作用のエラー (複数の場合あり) を破棄します。これにより、診断能力の支援となるだけでなく、エラーの影響を受けるコンポーネントが副作用のエラーに起因する訴求措置 (インダイトメント) を受けることがなくなります。パッチ 120827-01 がこの状態を修正します。
複数のドメインを実行するシステムでは、エラー状態のあと dsmd がドメインを回復する前に、hwad は実行中の各ドメインに dstop (domain stop) イベントを発行する必要があります。これらの dstop は連続して発行されていたため、最初の dstop が発行された時点と、すべてのドメインが回復された時点の間には遅延が生じていました。
個別のスレッドを使用して並行して dstop がドメインに発行され、遅延が解消されるよう、パッチ 120789-01 がこの問題を修正します。
UltraSPARC IV+ プロセッサの追加キャッシュレベルを担当することを目的とし、Solaris 9 ドメインの既存のしきい値と協調するため、SC 側の SERD (Soft Error Rate Discriminator) はさまざまなしきい値を必要としていました。調整がなければ、ドメインは SC 側の診断の前にプロセッサをオフラインにします。また、プロセッサの健全性状態は正しく更新されません。
2 つのオペレーティングシステムのバージョンと、サポートされるすべての種類のプロセッサの SMS 1.5 ソフトウェアの間で診断の一貫性が保たれるよう、パッチ 120827-01 はこの問題を修正します。
この節では、SMS 1.5 に影響するもっとも重大なバグについて簡単に説明します。
setcsn コマンドを使用して SC にシャーシシリアル番号 (CSN) を設定せずに Sun Fire ハイエンドサーバーを稼働させると、ドメイン停止 (Dstop) 後に NetConnect に送信される Fault Management Architecture (FMA) イベントレポートでシリアル番号が空のままになります。
回避策: setcsn コマンドを使用してシャーシシリアル番号を設定し、そのあと SMS を再起動します。イベントレポートに CSN を表示するためには、SMS を再起動する必要があります。
SC にシャーシシリアル番号を設定する方法の詳細は、『System Management Services (SMS) 1.5 インストールマニュアル』を参照してください。
一部のデバイスドライバパラメータは、ndd(1M) コマンドをスーパーユーザーとして実行することにより読み取りと書き込みが実行できます。 scman(7D) (ndd/dev/scman) は、Management (MAN) Network の Sun Fire E25K/E20K SC 側を管理し、ndd(1M) コマンドをサポートします。
scman(7D) の man_pathgroups_report パラメータが正しく解釈されない状況が発生すると、実際にはエラーがソフトウェアに起因するにもかかわらず、一連のハードウェアエラーが発生したかのような報告がなされることがあります。その結果、問題の根本要因を除く手段としてハードウェア交換が必要であるという誤った結論が出される可能性があります。
man_pathgroups_report パラメータを指定した場合、次のような出力が得られます。
最後の行にあるアスタリスク (*) は、「hme1 物理インタフェースが前回使用された際にエラーが検出された」ということを示しています。これまでのところ、このエラーのほとんどはハードウェアではなくソフトウェアに起因しています。
ソフトウェアは、MAN ネットワークピアが「ハートビート」メッセージに応答しなくなるか、あるいは dlpi(7P) に不正な状態変異が発生するとエラーを引き起こします。前述のケースは、次のコマンドをスーパーユーザーとして実行することによって繰り返し発生させることができます (上記とまったく同じ出力が表示されていると想定)。
コマンド (SC0 など) を実行する SC については、その Active Path は eri0 から hme1 に切り替わります。しばらくの間、SC1 は物理インタフェース eri0 上でパケットの送信を続け、SC0 は hme1 でパケットを送信します。すぐに、この 2 つは同じインタフェースを使用して同期をとり、通信するようになります。しかし、エラーが起きた最後のインタフェースを示すために、それぞれの SC にアスタリスクが示されます。この場合、エラーがソフトウェアに起因していることは明白です (つまり、このエラーは実際のところ「ハートビート」メッセージシーケンスに対する応答ではない)。これは、致命的なハードウェアエラーではありません。
致命的なハードウェアエラーが持続する場合はたしかに出力内にアスタリスクが示されますが、アスタリスクの原因がハードウェアだけにあると考えないことです。
この節には、SMS 1.5 のマニュアルページおよびマニュアルに含まれる誤りを記載しています。
marginvoltage のマニュアルページには次のように記載されています。
この記載はコア電圧にのみ該当します。そのほかすべての設定は一貫しています。
rcfgadm(1M) のマニュアルページ内にある注記は、次のように訂正してください。
rcfgadm コマンドの実行が失敗しても、対象のボードは実行前の状態には戻りません。dxs または dcs エラーメッセージがドメインのログに記録されます。発生したエラーが回復可能であれば、コマンドを再試行できます。
ドメインで Solaris 8 または Solaris 9 OS を実行している場合、次の確認を行ってください。
1. コマンドを再実行する前に、ドメイン上の /etc/inetd.conf に次に示す dcs エントリが存在することと、それらのエントリが無効になっていないことを確認してください。
2. エラーが回復不可能なものである場合、そのボードを使用するにはドメインを再起動する必要があります。
ドメイン上で Solaris 10 OS を実行している場合、dcs は SMF (Service Management Facility) の一部となっています。次の手順を実行してください。
2. ドメイン上のシステムプロンプトで次のコマンドを入力します。
3. 上記の例に示すように dcs が無効である場合、次のコマンドを入力して有効にします。
testemail(1M) のマニュアルページにある -c オプションの説明は、次のように訂正してください。
イベントを生成するために testemail が使用する fault クラス、またはコンマで区切った fault クラスのリスト。
-c fault_class, fault_class, fault_class
有効な fault クラスの例は、ファイル /etc/opt/SUNWSMS/config/SF15000.dict に挙げられています。
Ecache リソースを使用して testemail を起動する場合は、Ecache を搭載しているシステムボードに電源が入っていることを確認してください。このボードに電源が入っていないと、testemail の起動は失敗し、電子メールは生成されません。
SMS ソフトウェアに電圧コア監視パラメータ (VCMON) が追加されました。VCMON を有効にすると、プロセッサの電圧変化 (ドリフト) が監視されます。電圧の上昇を検知すると (これは、通常、ソケット接続に関連した問題があることを示す)、VCMON はユーザーに FMA イベントの発生を通知し、そのプロセッサのコンポーネント健全状態 (CHS) を faulty (障害あり) とマークします。
showboards コマンドに関するこの説明で、-a オプションは -v に訂正してください。
showenvironment コマンドの説明にあるカテゴリ「デバイス」は削除してください。
showlogs -d domain_indicator -p s
showlogs -d domain_indicator -p c
smsinstall: SMS ソフトウェアをインストールします。
smsupgrade: システムにインストールされている既存の SMS ソフトウェアをアップグレードします。
エラーコード 11300 と 50000 の間に、次のエラーメッセージカテゴリを追加してください。
12100-12299: イベントユーティリティーのメッセージ用に予約。
12300-12499: Wcapp のメッセージ用に予約。
12500-12699: FRUID 関連のメッセージ用に予約。
12700-12799: EBD メッセージ用に予約されている
ハードウェア互換性の表 (表 2-1) では、ドメインとシステムコントローラ (SC) 両方に関して、Solaris 8 ソフトウェアの最初のサポート対象バージョンとして Solaris 8 2/02 が一覧に存在すべきです。
この表には誤字があり、1.65 MHz UltraSPARC プロセッサと記載されています。正しい速度は 1.5 MHz です。
インストールマニュアルに記載されている 4 GB のサイズだけでなく、SMS 1.5 は 2 GB の /swap パーティションサイズもサポートしています。SMS 1.5 の推奨パーティションサイズは、以下のとおりです。
フェイルオーバーを無効にする前には、SMS は起動され実行中である必要があります。
Java バージョン 1.2.2 がインストールされていることを確認するには、システムプロンプトでコマンド java -version を入力します。
smsupgrade コマンドを実行し、SMS をインストールし直します。
シャーシのシリアル番号 (CSN) を記録する前に、SMS は起動され実行中である必要があります。
flashupdate の例に -f スイッチが記載されていません。次のように訂正してください。
-f /opt/SUNWsms/hostobjs/sgcpu.flash
手順 2 のあとに、手順 3 を追加してください。手順 3 は次のように訂正してください。
Solaris OS をアップグレードします。17 ページの「To Install or Upgrade the Solaris OS on the SC」を参照してください。
手順 3 のあとに、次の内容で手順 4 を追加してください。
メジャー OS アップグレード (34 ページを参照) のあと、smsupgrade を実行して SMS をインストールし直すか、あるいは次の手順に進んで SMS 構成を復元してください。
見出し「To Reinstall SMS Software」を「To Restore the SMS Configuration」に変更してください。
Copyright© 2005, Sun Microsystems, Inc. All rights reserved.