本サーバーのオンボードのイーサネットコントローラーはRTL8111Gだ。しかも2ポートもついていてどちらもGigabit Ethernet対応だ。にもかかわらず、長らくLinux上ではRealtekの8111x系のコントローラーのドライバーがプロプライエタリなために使い物にならず、現に本サーバーでも最初に稼働させるときにも使えず、泣く泣くUSB2.0接続のGbEアダプターを増設してネットワークに接続していた。この状態はDebian 10 Busterにアップグレードした時も変わらなかったので、相変わらずUSBアダプターで接続する状態が続いていたのだが、Debian 11 Bullseyeの状況を調べてみると、どうやらどこかの時点でLinux kernelに8111x系のドライバーがちゃんと取り込まれたらしいということが判明。しかも、BusterでもそのバージョンのKernelがすでに使われているというじゃないの。もし本当ならUSB2.0の480Mbpsで頭打ちになるアダプター経由でなくオンボードの8111Gで接続してフルスピードを活用したいということで、試しにオンボードのLAN端子にイーサネットケーブルを接続してインターフェースをアクティブにしてあげると、なんと確かにちゃんとつながるじゃないか。 🙂
というわけで、動作することが分かったのでオンボード側のインターフェースでイーサネット接続するように設定と配線を変更。とはいえ、いついかなる理由でエンバグしてネットワークがダウンするとも限らないので、USB接続のアダプターもそのまま残し、別のIPアドレスを割り当てておいて、いざというときにはケーブルさえ接続すればサーバーのメンテぐらいはできるようにしておいた。
これでちょっとはネットワークのレスポンスがよくなるといいんだけど。
後から調べてみたら、インストール済みのパッケージの中にfirmware-realtekが含まれていた。おそらく、過去にRTL8111Gが使えないかトライしたときに試しに入れたものと思われる。パッケージのバージョンが20190114-2となっているので、過去にトライした時にはRTL8111Gが動かなかったけれど、2019年1月14日にファームウェアの元ファイルが更新されて、その時点で動くようになったのだろう。
なんにせよ、オンボードのインターフェースが動くようになったのはありがたい。が、いくらなんでもサポートされるまで時間かかりすぎだろう。
何日か運用したあとに再起動するとデフォルトゲートウェイが失われて外部からの接続には答えるが自分からは何もパケットを出せないという謎の現象が発生。しかも、この現象が発生すると再起動しても解消しないため、一度電源を落としてからコールドブートする必要がある。
偶然の事象かと思って様子を見ていたのだが、コールドブート後にも数日後に同様の現象が発生しているのを確認。ということは、これはLinuxのカーネルドライバーかあるいはファームウェアの問題で再現性があるということだ。
さすがにこれでは運用は難しいので、元のUSB-GbEアダプター経由の接続に戻すことにした。相変わらずRTL8111x系は鬼門だ。まあ、USB-GbEからオンボードにしても特に速度の向上は感じることができなかったので、実質的にUSB2.0の480Mbpsで頭打ちになるほどの速度はもともと出ていなかったということだろうから、しばらくは我慢することにする。場合によってはUSB3.0接続のGbEアダプターでLinux動作が確認できているものに変えてもいいかもしれない。
結局、TP-LinkのUE305 USB3.0 GbEアダプターに交換することにした。これでGbEのフルスペックの速度が保証されるだろう。しかし、いつになったら安心してRealtekなインターフェースが使える様になるのやら。
ここにきてTP-LinkのUE305でも別の問題が。普通にサーバーとして運用している分には問題ないのだが、TorrentでファイルをダウンロードしようとTransmissionを動かすと転送が大量になった時にxhci_hcdがDMA転送のエラーを報告してNICがダウンしてしまう。どうもこれはUE305に限らずUSB3.0なデバイスで大量にデータ転送した時には同様に起きる問題のようで、USB3.0経由でHDDを接続して大量にコピーした時も同じように突然HDDがみえなくなってしまった。Bullseyeでkernelが4系列から5系列に上がれば治るかと思ったが、5系列でも同様の症状。NICの場合はこうなった時はUSBポートから抜き差しするだけで復帰するからよいものの、このバグがあるのならTransmissionはラズパイあたりで専用のサーバーを用意するしかなさそう。