Natz's Digital 漂流記

他のサイトでも触れられているように、Intel Atom 330 を搭載した Intel 製のマザーボード D945GCLF シリーズに CentOS 5.x をインストールすると、NIC ドライバーの問題に遭遇する。オンボード NIC の RTL8168 チップセットを RTL8619 と誤認識し、r8169 ドライバーが使われてしまって通信に不具合が出る、と言う問題だ。

僕もこの問題は新ファイルサーバー用のマザーボードの情報収集をする段階で認識していて、実際に購入した D945GCLF2D で CentOS 5.3 をインストールすると確かに r8169 ドライバーがロードされるのも確認したが、普通に通信できているように見えるので 「何だ、問題ねーじゃん」 と油断し、すっかり忘れてしまっていた。

しかしその後 2枚の NIC を束ねるボンディング設定の際に、見事にハマることになる。

ボンディングは複数の NIC を束ねてネットワークの冗長化や負荷分散を実現する機能で、僕はスイッチの機能やネットワーク環境に依存せず、送信・受信共に負荷分散される balance-alb モードを選んだ (後日 VMware Server の問題で active-backup に変更)。ちなみにボンディングの動作モードについては、このページがわかりやすい。

ボンディングの設定は簡単でスムーズに進んだが、Samba の共有フォルダーに Windows XP から 3GB 程度のファイルをコピーしてみると、コピーが途中で止まってしまう現象が発生した。CentOS の通信は問題ないように見えるが、ping を打ってみるとたまにパケットロスが出る (出ないときもある) ので、明らかに正常な状態ではない。OS インストール後から普通に通信できていた (ように見えた) せいで NIC のドライバー問題が完全に頭から消えていた僕は、ボンディングの設定か NIC 自体に不具合があると思い込み、設定を変えたり非ボンディング状態に戻したり、LAN ケーブルを交換してみたりと、無駄な試行錯誤で時間を浪費する羽目になった。

結局原因は、eth0 で r8169 ドライバーが使われていたことだった。Realtek のサイトから Linux カーネル 2.6 用ドライバー "r8168-8.014.00.tar.bz2" をダウンロードし、このときはまだ VMware ESXi 化されていなかった Linux マシン上の NFS 共有ディレクトリに置き、問題の CentOS で任意の場所にコピー (※ NIC が怪しい状態でも、完全に通信できないわけではない)。tar ボールに含まれる "readme" を参考にしつつ、以下の作業を行う。

これでひとまず一件落着だが、この r8168 ドライバーのインストールは、カーネルをアップデートする度にやり直す必要がある。大した作業ではないが、カーネル更新後の再起動直後は毎回 NIC が怪しいと言うのはダルいなァと考えていると、DAG のリポジトリに dkms-r8168 が登録されていることを知った。現時点のバージョンは 8.004.00 と Realtek サイトで提供されている 8.014.00 と比べると少し古いが、別に最新版でなくても問題はなさそうだし、DKMS (Dynamic Kernel Module Support) 対応なので、カーネル更新時の手間が省ける分、こちらの方が良さそうだ。

と言うことで、先日 CentOS 5.3 のカーネルを 2.6.18-164.el5 にアップデートした際、最新ドライバーの再インストールはせずに、DAG のドライバーを使ってみた (yum で使用するリポジトリに DAG が登録されている必要あり)。

lsmod で確認すると正しく r8168 がロードされているし、ボンディングも含め通信は正常。これでようやく 「普通の」 状態になったか。

Comments are closed.