Turris OmniaがLuleey LL-XS2510 XPONスティックを1000baseXに固定し、ethtoolに2.5Gが一切出てこない

リンクのメッセージだけでなく、ethtool eth2の全出力とdmesgのsfp関連の行も貼ってほしい。興味深いのは、ホストがそのモジュールの能力をどう判断したかという点。phylinkがinband/1000base-xに落ち着いたのなら、それはモジュール自身のEEPROMから読み取った結果であり、ドライバが一度も見ていないモードは、ルーター側で何を設定しても追加されない。

Omnia側のケージは2.5Gまで問題なく対応しているので、ここで制限しているのはハードウェアではない。あと、イメージのアップグレードも含めて、最近ホスト側で何か変更がなかったかも教えてほしい。

dmesgは、どの起動でも同じ:

mvneta f1034000.ethernet eth2: switched to inband/1000base-x link mode
Link is Up - 1Gbps/Full

ethtool eth2はsupportedとadvertisedの両方とも1000baseX/Fullを返し、Link detected: yesで1000Mb/s full duplexとなっている。出力のどこにも1Gを超えるものは出てこない。

スティック側のflash set LAN_SDS_MODE 6は実行自体は通り、モジュールを再起動しても設定は残るが、ホスト側はそれにまったく反応しない。メッセージも同じ、1Gのままも同じ。ルーターはスティックを入れて以来ずっと同じイメージのままなので、戻せる先も特にない。

それはホストがモジュールの申告をそのまま信じているということ。sfpドライバはEEPROMを読み、1000base-xを名乗るパーツを見つけて、eth2をinband/1000base-xに固定する。するとphylinkには提示できる2.5Gモードがなくなり、それがまさに貼ってくれたethtoolの出力になる。RTL960xの内部でLAN_SDS_MODEを使って設定しているのはモジュール自身のSerDesであって、ルーターに対して何を申告するかではないので、それでネゴシエーションされるモードが変わることはそもそもなかった。

抜け道は2つあり、自分が知っているのもこの2つだけ。1つはモジュールのEEPROMを書き換えて2.5Gを申告させる方法で、DFP-34X-2C3では既知の手だが、そちらは2C2なので同じオフセットだとは決めつけないほうがいい。もう1つはホスト側にパッチを当てる方法で、sfp.cにこのモジュール用のquirkを追加してそのカーネルを走らせる、スティック自体には手を付けない。

総合的に見て、自分ならホスト側にパッチを当てる。簡単には書き戻せないスティックのEEPROMを文鎮化させるほうが、ロールバックできるカーネルよりずっとひどい午後になる。

モジュールよりホスト側を疑い続けるべき理由がもう一つ。OpenWrtのスナップショットでは、バックポートされた汎用のphylink validateコードがOmniaのSFPケージを完全に壊していた時期があった。ethtoolは2500baseX/Fullを申告し続けるのに、ポートはLink detected: noとしか報告しない。あるカーネルコミットにきれいにbisectでき、そのバックポートを外すと2500Mb/s full duplexでリンクが戻り、その後の修正で決着した。

症状はそちらとは違うが教訓は同じ。mvnetaとphylinkのボードでは、ケージに何を許すかを決めているのはホスト側のソフトウェアなので、自分でビルドを始める前に、動作確認済みのイメージを戻し先として残しておく価値がある。

Turris OSでカスタムカーネルの道を選ぶなら、まずスナップショットを取ること。schnapps create "Before new kernel"のあとにopkg install --force-reinstall /srv/kernel_5.15.148-1_arm_cortex-a9_vfpv3-d16.ipkを実行して再起動する。カーネルがおかしな動きをしても、ルーターを分解する代わりにロールバックすればいい。

2つ目、みんな事が起きたあとにしか言わないことだが、2.5Gbpsのリンクは2.5Gbpsのトラフィックを意味しない。Omniaに載っているArmada CPUは単一キューではそこまで捌けないので、線上の数字がスループットになる前に、パケットステアリングとRPSのチューニングを見込んでおくこと。

本筋とは関係ないが、別のスティックでこれを読んでいる人向けの落とし穴を一つ。一部のPONモジュールは自前のOSを走らせていて、応答するまでに1分ほどかかることがある。そのためコールドブート時にルーターが早すぎるタイミングでケージをプローブしてしまい、銅線側のマグネティクスにフォールバックする。U-Bootでfw_setenv bootdelay 60を設定するのが定番の対処法。そちらのモジュールはすぐに検出されているので、今回のケースには当てはまらない。

締めくくりとして報告すると、ホスト側にパッチを当てる方法で決着した。修正済みのsfp.cでカーネルをビルドし、先にschnappsのスナップショットを取ってから、--force-reinstallでipkをインストールして再起動した。ethtool eth2は今では2500baseX/Fullを表示し、リンクは2.5Gbpsで上がっている。

結局モジュール側には何もしなかった。LAN_SDS_MODEはそのままにしてあり、無関係だったと分かったので、EEPROMには一度も手を触れずに済んだ。

スループットのほうは2つ目のアドバイスも必要だった。再起動直後は単一キューのせいでリンクレートよりかなり下で頭打ちになっていたが、パケットステアリングを調整したら、WANはようやくこのスティックを買った目的どおりに動くようになった。