2


SMS 1.5 のバグ

この章では、SMS 1.5 における既知のバグだけでなく、UltraSPARC IV+ プロセッサをサポートする SMS のパッチで修正されているバグについても説明します。この章では、以下の項目を説明します。


今回の更新でのバグ修正

この節では、SMS 1.5 ソフトウェアのバグと、UltraSPARC IV+ プロセッサをサポートする SMS のパッチで修正されている関連バグの一覧を示します。



注 - パッチ 120648-02 は、UltraSPARC IV+ プロセッサをサポートするために必要です。



UltraSPARC IV+ CPU のエラー処理の強化 (CR ID 6257778)

パッチ 120843-01 は、UltraSPARC IV+ プロセッサを含めるよう、OpenBoottrademark PROM のエラー処理および回復機能を強化しています。

prtdiag が C5 スロットに関して正しくないバス周波数を表示する (CR ID 6286277)

カードをスロット 1 (c5v0) にホットプラグし、システムを再起動すると、prtdiag はカードが装備されたスロットの正しいバス周波数を表示していましたが、そのほかの空スロットのバス周波数の報告が正しくありませんでした。このバグはパッチ 120843-01 で修正されています。

デュアルコア UltraSPARC IV+ を装備した Starcat 上では「PCI IOC ECC テスト」が -l64 またはそれ以降で失敗する (CR ID 6255743)

デュアルコア UltraSPARC IV+ ボードが装備されている Sun Fire E25K/E20K システムでは、診断レベル 64、96、または 127 で lpost が失敗する場合があります。失敗した場合、lpost は次のエラーメッセージを返します。


{SB03/P0/C1} ERROR: TEST=PCI IOC Ecc Tests,SUBTEST=PCI IOC ECC 

 

パッチ 120648-02 がこの問題を修正します。

1500 MHz の UltraSPARC IV+ GA をサポートするための hpost の変更 (CR ID 6270911)

UltraSPARC IV+ ボードをサポートするには、SMS 1.5 の hpost を変更する必要があります。パッチ 120648-02 がこの変更を行います。

Solaris からリブートした場合 hpost -q で「Out Of Config on Timeout」の障害が生じる (CR ID 6324035)

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)

 

パッチ 120648-02 がこの問題を修正します。

UltraSPARC IV+ バージョン 2.1 の初期ロットは Sun 内部専用にするべきである (CR 6292571)

カスタマシステム向けにリリースされた最初の UltraSPARC IV+ プロセッサは、バージョン 2.1.1 です。パッチ 120648-02 は POST を変更して、カスタマが使用するには適さない初期バージョンの 2.1 プロセッサを検出し、構成から除外します。

バージョン 2.1 と 2.1.1 の MaskID はいずれも 2.1 のため、MaskID では両者を区別できないことに注意してください。POST は、そのほかの電気的に読み取り可能な情報に基づいてバージョンを区別します。

UltraSPARC IV+: PN 1500 MHz 上の marginvoltage vcore マイナスが、正しいマージンの電圧を表示しない (CR 6288445)

このバグは、1500 MHz の UltraSPARC IV+ ボードにのみ該当します。時として、
-m-1 オプションを付けて marginvoltage コマンドを使用すると、正しくない値が返されます。数秒後このコマンドを再度発行すると、正しい値が返されます。このバグはパッチ 120789-01 で修正されています。

UltraSPARC IV+: UltraSPARC IV+ vcore の marginvoltage 出力形式が正しくない (CR 6290143)

このバグは、1500 MHz の UltraSPARC IV+ ボードにのみ該当します。
-m-1 オプションまたは -m+1 オプション付きで marginvoltage コマンドを使用すると、システムは正しくない出力形式を返します。たとえば、-m+1 コマンドを使用すると、UltraSPARC IV+ ボード上では Nom+3% (voltage) ではなく、Nom (voltage) という変更された値が返されますが、UltraSPARC IV および UltraSPARC III ボードでは同じコマンドで正しい出力が返されます。パッチ 120789-01 がこの問題を修正します。

RFE: AVL-FS2 (Starcat): 新しい UltraSPARC IV+ CPU エラーの診断を提供 (CR ID 6277467)

UltraSPARC IV+ プロセッサには、UltraSPARC IV および III+ プロセッサを上回る、追加のエラー検出および RAS 機能が含まれます。この CR では、UltraSPARC IV+ が報告できる新しいエラーを診断するための Availability 機能に対する拡張機能が説明されています。この拡張機能により、Availability は、すべてのプロセッサタイプのすべての致命的なエラーだけでなく、Solaris 9 ドメインの致命的ではないエラーも診断します。パッチ 120827-01 がこの拡張機能を提供します。

SC CPU は、プロセッサインダイトメント (障害コンポーネントの訴求措置) を起こさないよう、非 FMA ドメイン上で L3/L2 エラーを処理する必要がある (CR ID 6302265)

UltraSPARC IV+ チップには 3 つのレベルのキャッシュがあります。レベル 2 および 3 はデータキャッシュを参照します。レベル 2 はプロセッサの内部にあり、レベル 3 はプロセッサの外部にあります。

エラーが、副作用として追加のエラーを発生させることがあります。データキャッシュのいずれかのレベルでエラーが発生した場合、Availability ソフトウェアはエラーの根本原因を診断し、副作用のエラー (複数の場合あり) を破棄します。これにより、診断能力の支援となるだけでなく、エラーの影響を受けるコンポーネントが副作用のエラーに起因する訴求措置 (インダイトメント) を受けることがなくなります。パッチ 120827-01 がこの状態を修正します。

hwad シリアルでの dstop イベントの送信が、遅延と正しくない dsmd ASR を引き起こす (CR ID 6302843)

複数のドメインを実行するシステムでは、エラー状態のあと dsmd がドメインを回復する前に、hwad は実行中の各ドメインに dstop (domain stop) イベントを発行する必要があります。これらの dstop は連続して発行されていたため、最初の dstop が発行された時点と、すべてのドメインが回復された時点の間には遅延が生じていました。

個別のスレッドを使用して並行して dstop がドメインに発行され、遅延が解消されるよう、パッチ 120789-01 がこの問題を修正します。

S9U8、S10U1/FMA、および SMS 1.5 の間で、CPU イベントの SERD チューニング可能属性が一貫しない (CR ID 6309365)

UltraSPARC IV+ プロセッサの追加キャッシュレベルを担当することを目的とし、Solaris 9 ドメインの既存のしきい値と協調するため、SC 側の SERD (Soft Error Rate Discriminator) はさまざまなしきい値を必要としていました。調整がなければ、ドメインは SC 側の診断の前にプロセッサをオフラインにします。また、プロセッサの健全性状態は正しく更新されません。

2 つのオペレーティングシステムのバージョンと、サポートされるすべての種類のプロセッサの SMS 1.5 ソフトウェアの間で診断の一貫性が保たれるよう、パッチ 120827-01 はこの問題を修正します。


SMS 1.5 ソフトウェアの既知のバグ

この節では、SMS 1.5 に影響するもっとも重大なバグについて簡単に説明します。

NetConnect に送信される FMA イベントレポートに、変更されたシャーシシリアル番号が報告されない (CR ID 5052078)

setcsn コマンドを使用して SC にシャーシシリアル番号 (CSN) を設定せずに Sun Fire ハイエンドサーバーを稼働させると、ドメイン停止 (Dstop) 後に NetConnect に送信される Fault Management Architecture (FMA) イベントレポートでシリアル番号が空のままになります。

回避策: setcsn コマンドを使用してシャーシシリアル番号を設定し、そのあと SMS を再起動します。イベントレポートに CSN を表示するためには、SMS を再起動する必要があります。

SC にシャーシシリアル番号を設定する方法の詳細は、『System Management Services (SMS) 1.5 インストールマニュアル』を参照してください。

ndd/dev/scman man_pathgroups_report 出力は詳しい解明が必要である (CR ID 6252771)

一部のデバイスドライバパラメータは、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 パラメータを指定した場合、次のような出力が得られます。


# ndd /dev/scman man_pathgroups_report
MAN Pathgroup report: (* == error)
Interface       Destination             Active Path     Alternate Paths
----------------------------------------------------------------
scman1          Other SSC               eri0 eri0 exp 0, hme1 exp 0 *

 

最後の行にあるアスタリスク (*) は、「hme1 物理インタフェースが前回使用された際にエラーが検出された」ということを示しています。これまでのところ、このエラーのほとんどはハードウェアではなくソフトウェアに起因しています。

ソフトウェアは、MAN ネットワークピアが「ハートビート」メッセージに応答しなくなるか、あるいは dlpi(7P) に不正な状態変異が発生するとエラーを引き起こします。前述のケースは、次のコマンドをスーパーユーザーとして実行することによって繰り返し発生させることができます (上記とまったく同じ出力が表示されていると想定)。


# ndd -set /dev/scman man_set_active_path '1 0 1'

 

コマンド (SC0 など) を実行する SC については、その Active Path は eri0 から hme1 に切り替わります。しばらくの間、SC1 は物理インタフェース eri0 上でパケットの送信を続け、SC0 は hme1 でパケットを送信します。すぐに、この 2 つは同じインタフェースを使用して同期をとり、通信するようになります。しかし、エラーが起きた最後のインタフェースを示すために、それぞれの SC にアスタリスクが示されます。この場合、エラーがソフトウェアに起因していることは明白です (つまり、このエラーは実際のところ「ハートビート」メッセージシーケンスに対する応答ではない)。これは、致命的なハードウェアエラーではありません。

致命的なハードウェアエラーが持続する場合はたしかに出力内にアスタリスクが示されますが、アスタリスクの原因がハードウェアだけにあると考えないことです。


SMS 1.5 ドキュメントの誤り

この節には、SMS 1.5 のマニュアルページおよびマニュアルに含まれる誤りを記載しています。

marginvoltage(1M)

marginvoltage のマニュアルページには次のように記載されています。

マージン設定は以降の電源再投入で一貫していません。

この記載はコア電圧にのみ該当します。そのほかすべての設定は一貫しています。

rcfgadm(1M)

CR ID 4945049

rcfgadm(1M) のマニュアルページ内にある注記は、次のように訂正してください。

rcfgadm コマンドの実行が失敗しても、対象のボードは実行前の状態には戻りません。dxs または dcs エラーメッセージがドメインのログに記録されます。発生したエラーが回復可能であれば、コマンドを再試行できます。

single-step bulletドメインで Solaris 8 または Solaris 9 OS を実行している場合、次の確認を行ってください。

1. コマンドを再実行する前に、ドメイン上の /etc/inetd.conf に次に示す dcs エントリが存在することと、それらのエントリが無効になっていないことを確認してください。


sun-dr stream tcp wait root /usr/lib/dcs dcs
sun-dr stream tcp6 wait root /usr/lib/dcs dcs

 

2. エラーが回復不可能なものである場合、そのボードを使用するにはドメインを再起動する必要があります。

single-step bulletドメイン上で Solaris 10 OS を実行している場合、dcs は SMF (Service Management Facility) の一部となっています。次の手順を実行してください。

1. root としてログインしていることを確認します。

2. ドメイン上のシステムプロンプトで次のコマンドを入力します。


# inetadm | grep dcs
 
disabled disabled svc: /platform/sun4u/dcs: default

 

3. 上記の例に示すように dcs が無効である場合、次のコマンドを入力して有効にします。


# svcadm enable svc:/platform/sun4u/dcs:tcp 

 

testemail(1M)

CR ID 5047803

testemail(1M) のマニュアルページにある -c オプションの説明は、次のように訂正してください。

イベントを生成するために testemail が使用する fault クラス、またはコンマで区切った fault クラスのリスト。

-c fault_class, fault_class, fault_class

有効な fault クラスの例は、ファイル /etc/opt/SUNWSMS/config/SF15000.dict に挙げられています。

CR ID 6221370

「説明」セクションの注記は、次のように訂正してください。

Ecache リソースを使用して testemail を起動する場合は、Ecache を搭載しているシステムボードに電源が入っていることを確認してください。このボードに電源が入っていないと、testemail の起動は失敗し、電子メールは生成されません。

System Management Services (SMS) 1.5 管理者マニュアル

第 1 章、5 ページ:

VCMON の説明は、次のように訂正してください。

SMS ソフトウェアに電圧コア監視パラメータ (VCMON) が追加されました。VCMON を有効にすると、プロセッサの電圧変化 (ドリフト) が監視されます。電圧の上昇を検知すると (これは、通常、ソケット接続に関連した問題があることを示す)、VCMON はユーザーに FMA イベントの発生を通知し、そのプロセッサのコンポーネント健全状態 (CHS) を faulty (障害あり) とマークします。

第 10 章、196 ページ:

showboards コマンドに関するこの説明で、-a オプションは -v に訂正してください。

showenvironment コマンドの説明にあるカテゴリ「デバイス」は削除してください。

第 11 章、206 ページ:

最初の例は、次のように訂正してください。

showlogs -d domain_indicator -p s

2 つ目の例は次のように訂正してください。

showlogs -d domain_indicator -p c

付録 A、253 ページ:

次のコマンドを追加してください。

smsinstall: SMS ソフトウェアをインストールします。

smsupgrade: システムにインストールされている既存の SMS ソフトウェアをアップグレードします。

付録 B (CR 6227544、4943474):

エラーコード 11300 と 50000 の間に、次のエラーメッセージカテゴリを追加してください。

11500-11699: EFHD のメッセージ用に予約。

11700-11899: ELAD のメッセージ用に予約。

11900-12099: ERD のメッセージ用に予約。

12100-12299: イベントユーティリティーのメッセージ用に予約。

12300-12499: Wcapp のメッセージ用に予約。

12500-12699: FRUID 関連のメッセージ用に予約。

12700-12799: EBD メッセージ用に予約されている

System Management Services (SMS) 1.5 インストールマニュアル

5 ページ:

ハードウェア互換性の表 (表 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 の推奨パーティションサイズは、以下のとおりです。


0

/ (root)

8 G バイト

1

swap

4 G バイト

4

OLDS/LVM データベース (metadb)

32 M バイト

5

OLDS/LVM データベース (metadb)

 

32 M バイト

7

/export/install

残りの空き容量


 

17 ページ:

フェイルオーバーを無効にする前には、SMS は起動され実行中である必要があります。

18 ページ:

Java バージョン 1.2.2 がインストールされていることを確認するには、システムプロンプトでコマンド java -version を入力します。

手順 3 は次のように訂正してください。

smsupgrade コマンドを実行し、SMS をインストールし直します。

33 ページ:

シャーシのシリアル番号 (CSN) を記録する前に、SMS は起動され実行中である必要があります。

43 ページ:

例は sc1 ではなく、sc0 を示すべきです。

44 ページ:

flashupdate の例に -f スイッチが記載されていません。次のように訂正してください。

-f /opt/SUNWsms/hostobjs/sgcpu.flash

48 ページ:

手順 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」に変更してください。