内蔵etherがリンクアップしない問題の暫定対策

Linux Ubuntu

どうも。over80です。
今日は久々に予定の全く無い休日だったので、溜まっていたおかいものとかをしてきました。右の写真は今日買ってきた物の一部です。

さて、今日のエントリは、私のPCのネットワークインターフェースのトラブルの話です。起きたのは随分前だったと思うのですが、ブログに書いている余裕が無く、放置していた物だったりします。今日、状況が進展した(いや、むしろ進展しなかった？)ので、ネタにしてみました。

2010-11-24 追記: この問題は MSI が配布している新しい BIOS (私が確認したバージョンは 1.7)で修正されたようです。もし同じ症状が出ているようなら、まずはBIOSの更新をお試し下さい。

問題の詳細

先日(といってもけっこう前。2ヶ月ぐらい？)、Ubuntuのカーネルのアップデートを契機に、突然、ネットワークが動かなくなりました。
dmesgやifconfigを見るに、物理層のリンクアップに失敗しているようです。

わたしの使っているネットワークカードは先日購入した MSI 890GXM-G65 に内蔵されたギガビットイーサです。詳細を見てみると Realtek の石でした。

$ lspci | grep Ether
02:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168B PCI Express Gigabit Ethernet controller (rev 03)
$ sudo lspci -v -s 02:00.0
02:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168B PCI Express Gigabit Ethernet controller (rev 03)
	Subsystem: Micro-Star International Co., Ltd. Device 7642
	Flags: bus master, fast devsel, latency 0, IRQ 27
	I/O ports at c800 [size=256]
	Memory at fdfff000 (64-bit, prefetchable) [size=4K]
	Memory at fdff8000 (64-bit, prefetchable) [size=16K]
	Expansion ROM at fe9c0000 [disabled] [size=128K]
	Capabilities: [40] Power Management version 3
	Capabilities: [50] Message Signalled Interrupts: Mask- 64bit+ Queue=0/0 Enable+
	Capabilities: [70] Express Endpoint, MSI 01
	Capabilities: [ac] MSI-X: Enable- Mask- TabSize=4
	Capabilities: [cc] Vital Product Data <?>
	Capabilities: [100] Advanced Error Reporting <?>
	Capabilities: [140] Virtual Channel <?>
	Capabilities: [160] Device Serial Number 00-e0-4c-68-00-00-00-3c
	Kernel driver in use: r8169
	Kernel modules: r8169

Ubuntu の Bug Track を検索してみたら、出るわ出るわ。

それだけ沢山使われている石ってことなんでしょうけど、それにしても今一不安定な物のようですね。
私の所の物と同じ症状の報告もいくつか上がっていて、修正されたソースもあるようです。

さすがにこれだけ広範囲な物なら報告も沢山あがっていて、そのうち修正はとりこまれるんでしょうが、それまでネットが全く使えないのも問題なので、幾つか暫定回避の為の対策をここに列挙しておきます。同じ問題や、似たような問題にハマった人は参考にしてみて下さい。

暫定対策1： オートネゴシエーションを無効にする

今回の問題の場合、イーサネットの100Mのリンクに失敗するのが直接的な原因のようで、オートネゴシエーションを切って10Mのリンクに固定してやれば動作しました。

次のコマンドを試してみてください。

$ sudo ethtool -s eth0 autoneg off

注：イーサネットが複数あるPCの場合は eth0 を適宜置き換えて実行してください。

実行して数秒後に、タスクバーにあるネットワークのアイコンが変わって接続完了すれば成功です。

もし、当面この対策で乗り切るのであれば、rcスクリプトを編集して、起動時にこのコマンドが自動実行されるようにすることもできます。

#!/bin/sh -e
#
# (中略)

ethtool -s eth0 autoneg off
exit 0

わたしはこの方法でここ1、2ヶ月をのりきっています。ネットが少し遅くなってしまいますが、大きなファイルをダウンロードしたりしなければ意外と問題無いです。

暫定対策2： 古いカーネルを使い続ける

以前のカーネルでは動作していたわけですから、そのカーネルを使い続ければ問題は起こりません。

Ubuntuの場合、kernelのアップデートの際にも、古いカーネルは残されています。PC起動時のブートローダの画面で沢山並んでいるカーネルの少し古い(バージョンの低い)ものを選択して起動させてみましょう。それで問題が起きなければ、それを使い続けるという手があります。

毎回カーネルを選択するのが面倒な人は、ブートローダ(grub)の設定を変更する手があります。が、これに失敗すると起動しなくなる事もありえますので、やる気のある方は /etc/default/grub の中身と grub-update の詳細を確認してから、自己責任でやってください。

あと、古いカーネルはセキュリティバグが残っていることもありますので、その点も自己責任で。

暫定対策3： カーネルモジュールをビルドして置き換える

RealTekのサイトにおいてあるソースや、linuxカーネルMLに流れているパッチなどのバージョンでは動いたという報告もあります。例えば、 https://forums.ubuntulinux.jp/viewtopic.php?id=5347 とか https://bugs.launchpad.net/ubuntu/+source/linux/+bug/564984/comments/33 などです。(だからこそそのうち解決されるだろうと楽観しているのですが。)

そのようなソースを元にビルドし、モジュールを置き換えれば動くこともあるでしょう。

私は正直、面倒なので試してもいません。やりたいひとは、まあ、頑張ってくださいw

暫定対策(失敗編)： イーサネットのHubを買い替える

私の環境は、PCはギガイーサでしたがハブは100Mだったので、「ギガハブに変えれば動くんじゃね？」という考えもありました。

実は今日の買い物の目的の1つはそれだったりします。(冒頭に貼った写真にも写ってますね。)

で、結果は、というと、あっさりダメでした。 orz

まぁ、メインPC以外の機器には恩恵がありますし、メインPCもカーネルが直った折りには 10M(暫定対策1) → 1000M とジャンプアップ2階級特進なので良いことにしましょう。

といったところで今日はこれまで。

久々にブログ書いて疲れたので、いっしょに買ってきたトリックロジックで遊ぶぞー。アキバヨドバシに行ったら売り切れてて、ブックオフで買ってきたんですが、意外と人気なんですかね？ コレ。 私的には久々にビビビっと来て買っちゃったんですがね。