SP/FPGAインターフェースがFIFOに移行後、AFBR-89BDDZ QSFP28のベンダーフィールドが0905000000000000になる
自社ハードウェアのスイッチ管理ファームウェアを担当していて、SP/FPGAインターフェースがメモリマップドバッファからFIFOに変更されて以来、一部のポートでトランシーバのインベントリがゴミとして返ってくるようになりました。
- QSFP28光モジュール、すべて同一バッチのAFBR-89BDDZ
- 読み取りはサービスプロセッサとFPGA経由でモジュールのEEPROMまで到達する
- ホスト側のヘルパーはget_i2c_status_and_read_buffer: ステータス確認、バッファ全体を読み取り、再度ステータス確認
ベンダーデータの代わりに返ってくるのは:
one port, vendor field: 0905000000000000
the next port, vendor field: all ones
on another machine: vendor field all zeros, elsewhere repeated digit charactersこれまで試したこと:
- 同じポートを連続で何度も読み直したが、ゴミはランダムノイズではなくポートごとに安定していた
- モジュールを電源サイクルしたが変化なし
- シャーシ内のすべてのモジュールが同じパートナンバーであることを確認したので、何か特殊なベンダーブロックを誤ってデコードしているわけではない
本番環境から光モジュールを抜き始める前に、これはモジュール、I2Cパス、自分たちの読み取りヘルパーのどれが原因である可能性が高いでしょうか?
Show original (English)
Also available in: English
العربية
Deutsch
Español
Français
हिन्दी
Bahasa Indonesia
Italiano
日本語
한국어
Nederlands
Polski
Português
Русский
Türkçe
Tiếng Việt
简体中文
Comments 7
それはまさに読み取りパスを指していて、FIFOへの変更が原因です。メモリマップドバッファは何度尋ねても同じ内容を返しますが、FIFOは各バイトをちょうど1回だけ渡すとそれで終わりです。get_i2c_status_and_read_bufferが引き継いだシーケンス、ステータス確認、バッファ全体読み取り、再度ステータス確認は、背後にメモリがある前提では理にかなっていましたが、FIFOでは意味をなしません: モジュールのEEPROM読み取りがまだ配線上にある間にキューを空にしてしまいます。その瞬間にたまたまそこにあったものが返り、遅れて到着したバイトは取り残されて次の読み取りで出てきます。
それはまさにあなたが説明している特徴そのものです。ポートごとに安定したゴミ、シーケンスに沿って移動する破損、タイミングの落ち方次第である機械ではオール0、別の機械では繰り返す数字パターン。そこには不良モジュールが必要な要素は何もなく、あなたのスワップの結果もいずれにせよ光モジュールを除外しています。
修正は、完了チェックの責任を呼び出し側に負わせるのをやめることです。その責任をトランシーバドライバ自体の読み取りルーチンの内側に移してください: I2Cトランザクションがdoneを報告するまで待ってから初めてバッファに触れるようにすれば、構造上どの呼び出し側も早期にキューを空にできなくなります。1箇所の呼び出しだけにパッチを当てても、競合をどこか別の場所に押しやるだけです。
正直に言うと、これは何年も実績のあるものというより提案段階の修正の形なので、インベントリを再び信頼する前に自分たちのプラットフォームで検証してください。とはいえ安く済む教訓として持ち帰ってほしいのは、壊れたベンダー文字列にはまずモジュール対ポートのテストを当てるべきだということです、光モジュールよりも読み取り順序の方がはるかに多く犯人になるので。
これを二つに切り分ける唯一の測定方法があります: 破損はモジュールについて回るのか、それともポートについて回るのか?
0905000000000000を返しているポートからモジュールを抜いて、正しく読めているポートのモジュールと入れ替え、両方を読み直してください。壊れた文字列が物理モジュールについて行くなら、光モジュール側を調べてください。ポート番号側に残る、あるいはもっと悪いことに次に読まれるモジュールへ移っていくなら、モジュールは無実でホスト側の読み取り問題ということになります。ついでに、デコード済みフィールドと一緒に生のEEPROMバイトもダンプしてください。下にある生バイトはまともなのにデコード済みのベンダー文字列がゴミになっているのは、バイト自体がゴミなのとはまったく別のバグです。
そのスワップを2ポートで実行しました。悪いデータはモジュールについて移動しませんでした:
0905000000000000を返していたポートは、別のモジュールを挿してもそれを返し続け、抜いたモジュールは新しいスロットで完璧に読めました。さらに、ポートを読む順番を変えたところ、破損はそのシーケンスと一緒に移動しました。ゴミは、不調なポートの次に読まれるモジュールに乗ります。つまり物理的な部品ではなく読み取り順序を追っているということです。生バイトも間違っているので、こちら側のデコードの問題でもありません。
根本原因は違いますが同じ罠です、こちらはドライバ側から。Intel E810-Cでout-of-treeのice 1.15.4を使っていたとき、QSFP28光モジュールに対する
ethtool -mが間違った不完全なページを返してきました: page 1とpage 3のデータ、しきい値とレーンごとのモニタが、モジュールが実際に保持している内容と一致していませんでした。きちんとした根本原因の説明は得られず、スレッドはあまり詳細もないまま解決済みとしてクローズされたので、これは定説というより一つの体験談として扱ってください。最終的にやったのは、
nvmupdate64eでiceドライバとE810のNVMを更新し、別のホストのin-kernel iceドライバからの読み取りと突き合わせ、そしてデコード済みの出力を信用するのではなく次のように明示的なオフセットと長さを指定して特定のページを取得することでした:生ダンプができるなら、どちらかを信じる前に生データとデコード結果を比較してください。
この階層構造を書き出しておく価値があります、この手の調査がずっと短くなるので。Linuxでは
ethtool -mがモジュールのEEPROMをデコードし(ベンダー名、OUI、パートナンバー、シリアル、日付コード、モジュールが持っていればDDM値)、ethtool -eは生バイトをダンプし、I2Cバスが露出している環境ではi2cdump -y 1 0x50がA0hを、i2cdump -y 1 0x51がA2hを読みます。A0hではベンダー名がバイト20-35に、PN、rev、SNがバイト40-59にあります。なのでベンダーフィールドが壊れていて、そこから20バイトほど先にあるパートナンバーが無傷なら、それだけでEEPROMが壊れているというよりタイミング依存の読み取りだということを示していて、あなたが見ている状況にも合致します。
これと混同してはいけない別の障害が一つあります:
ethtool -mがInput/output errorを返すのは、たいていDDMを持たないモジュールというだけです。A0hのバイト92のビット6は、そもそもA2hが存在するかどうかを示すフラグで、そのチェックはずっと前にin-kernelのixgbeとbnx2xドライバに組み込まれ、存在しないもう256バイトに手を伸ばさずに済むようになっています。その方面から来た人のために言うと、SONiC機でも同じ種類の問題があります。
sfputil show eepromが特定のモジュールに対してCannot get Module EEPROM data: Invalid argumentと言ってきたり、同じポートについてshow interfaces transceiver eepromと静かに食い違ったりします。自分が遭遇した範囲では、光モジュールというよりほとんどがプラットフォームとドライバ側のギャップです: この2つのコマンドは202012ブランチで一貫しないキー名を使っていて、それは202205で修正されました。一部のプラットフォームではドライバの修正が入るまで電源サイクル後にsfputilからQSFPモジュールが消え、別のプラットフォームではget_transceiver_infoが単に実装されていません。スクリプトのために信頼できるものが必要なときは、optoeカーネルドライバのところまで行って、SFP、QSFP、CMISのEEPROMを自分で生読みします。とはいえ自分のプラットフォームで確認してください、挙動は機種間でかなり違います。
こちら側からの続報です。提案どおり完了チェックをドライバの読み取り関数の中に移したところ、数百回のインベントリ走査を通じてすべてのポートでベンダー文字列が正しくなりました、お互いにゴミを交換し合っていた2ポートも含めてです。生バイトも今はデコード済みフィールドと一致しています。
今のところはクローズではなく部分的解決と呼んでおきます: まだ自分たちのツリーに取り込まれていないパッチとして運用していて、どこでも信頼できると言う前に検証すべき別のFPGAビルドのプラットフォームがもう一つ残っています。ただ光モジュールは最初からずっと問題なかったわけで、それは自分一人では見誤っていた部分です。