2014/04/02(水) [n年前の日記]
#2 [ubuntu] Ubuntuとr8168ドライバ云々の作業をメモ
キューブ機(Ubuntu機)のNICドライバを差し替えた際の作業をメモ。M/B は、Intel D945GSEJT。NIC(LANチップ？)は蟹(Realtek製)。Ubuntu 12.04 LTS。
lspci -v | grep r816 で、r8169 が表示されたら誤認識してる。r8168 が表示されてたらOK。
以下を参考にして作業。
_[SOLVED] r8168 on Ubuntu 12.04
_R8169からR8168へのNICドライバの入れ替え on ubuntu - モノヅクリブログ
_UbuntuTips/Others/DkmsHowTo - Ubuntu Japanese Wiki
_RTL8111D 用ドライバをインストールするには (1) - metastable blog
_Iron Sling annex >> 【再掲】Lanドライバ誤認識 - Realtek 8111E R8168 on Ubuntu -
_Intel ATOM MB の NIC を Linux で使うときのメモ - 不定期日記
たぶん、以下にメモした内容はどこかで何か間違えてるけど…。何をしたのか後で分からなくなるので一応メモ。
おそらくはコンパイルだかビルドだかをするために必要なものをインストール。
_Realtek から、「LINUX driver for kernel 3.x and 2.6.x and 2.4.x」をDL。現在のバージョンは 8.038 だった。r8168-8.038.00.tar.bz2 をDL。
/usr/src/ 以下に解凍するのは、後で dkms とやらを使って、カーネルが更新された時にドライバを作る？ためらしい。
とりあえず、以下を実行。
/usr/src/r8168-8.038.00/ 以下に dkms.conf を作って編集。
登録したりビルドしたりするのかな。よく分かってない。
r8169 を使わないようにする、のだと思うけど、なんかこのへんがちゃんとできてなかったような。再起動したら r8169 が使われちゃってたし。blacklist.conf に記述を追加するだけでは反映されてない気がする。
depmod -a とか rmmod r8169 とか、そのあたりをするといいのかもしれない。なんかそのへん適当にやってたら再起動時に r8168 が使われるようになったのですが。作業手順をメモするのを忘れてしまって…。
結局、何をどうすればいいのか、よく分かってない状態です。
lspci -v | grep r816 で、r8169 が表示されたら誤認識してる。r8168 が表示されてたらOK。
以下を参考にして作業。
_[SOLVED] r8168 on Ubuntu 12.04
_R8169からR8168へのNICドライバの入れ替え on ubuntu - モノヅクリブログ
_UbuntuTips/Others/DkmsHowTo - Ubuntu Japanese Wiki
_RTL8111D 用ドライバをインストールするには (1) - metastable blog
_Iron Sling annex >> 【再掲】Lanドライバ誤認識 - Realtek 8111E R8168 on Ubuntu -
_Intel ATOM MB の NIC を Linux で使うときのメモ - 不定期日記
たぶん、以下にメモした内容はどこかで何か間違えてるけど…。何をしたのか後で分からなくなるので一応メモ。
おそらくはコンパイルだかビルドだかをするために必要なものをインストール。
sudo apt-get install --reinstall linux-headers-$(uname -r) linux-headers-generic build-essential dkms
_Realtek から、「LINUX driver for kernel 3.x and 2.6.x and 2.4.x」をDL。現在のバージョンは 8.038 だった。r8168-8.038.00.tar.bz2 をDL。
sudo tar xvf r8168-8.038.00.tar.bz2 -C /usr/srcを実行して、/usr/src/ 以下に r8168-8.038.00/ というフォルダ名で解凍。
/usr/src/ 以下に解凍するのは、後で dkms とやらを使って、カーネルが更新された時にドライバを作る？ためらしい。
とりあえず、以下を実行。
cd /usr/src/r8168-8.038.00/ sudo ./autorun.sh sudo cp /boot/initrd.img-`uname -r` /boot/initrd.img-`uname -r`.bak sudo mkinitramfs -o /boot/initrd.img-`uname -r` `uname -r`これだけで入れ替えることはできるらしい。ただ、カーネルが更新された際、また同じことをしないといかん気がするわけで。なので、そのあたりは dkms とやらでどうにかするのだとか。よく分かってないですが。
/usr/src/r8168-8.038.00/ 以下に dkms.conf を作って編集。
sudo touch /usr/src/r8168-8.038.00/dkms.conf sudo vi /usr/src/r8168-8.038.00/dkms.conf内容は以下のようにしたけどたぶん何か間違えてる気がする。
PACKAGE_NAME="r8168" PACKAGE_VERSION="8.038.00" DEST_MODULE_LOCATION="/updates/dkms" BUILT_MODULE_NAME="r8168" BUILT_MODULE_LOCATION="src/" MAKE="'make' -C src/ all" CLEAN="'make' -C src/ clean" AUTOINSTALL="yes"
登録したりビルドしたりするのかな。よく分かってない。
sudo make modules sudo make clean
sudo dkms add -m r8168 -v 8.038.00 sudo dkms build -m r8168 -v 8.038.00 sudo dkms install -m r8168 -v 8.038.00dkms に登録したソレを削除する時は以下のように打つらしい。
sudo dkms remove -m r8168 -v 8.038.00 --all
r8169 を使わないようにする、のだと思うけど、なんかこのへんがちゃんとできてなかったような。再起動したら r8169 が使われちゃってたし。blacklist.conf に記述を追加するだけでは反映されてない気がする。
echo "blacklist r8169" | sudo tee -a /etc/modprobe.d/blacklist.conf sudo modprobe -rfv r8169 sudo modprobe -v r8168
depmod -a とか rmmod r8169 とか、そのあたりをするといいのかもしれない。なんかそのへん適当にやってたら再起動時に r8168 が使われるようになったのですが。作業手順をメモするのを忘れてしまって…。
結局、何をどうすればいいのか、よく分かってない状態です。
◎ ethtoolもインストール。 :
ethtool なるツールを使うとNICの状態を確認できるらしいのでインストール。
sudo aptitude install ethtool
$ ethtool -i eth0 driver: r8168 version: 8.038.00-NAPI firmware-version: bus-info: 0000:01:00.0 supports-statistics: yes supports-test: no supports-eeprom-access: no supports-register-dump: yes
$ ethtool eth0
Settings for eth0:
Supported ports: [ TP ]
Supported link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
1000baseT/Full
Supported pause frame use: No
Supports auto-negotiation: Yes
Advertised link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
1000baseT/Full
Advertised pause frame use: Symmetric Receive-only
Advertised auto-negotiation: Yes
Speed: 1000Mb/s
Duplex: Full
Port: Twisted Pair
PHYAD: 0
Transceiver: internal
Auto-negotiation: on
MDI-X: Unknown
Cannot get wake-on-lan settings: Operation not permitted
Current message level: 0x00000033 (51)
drv probe ifdown ifup
Cannot get link status: Operation not permitted
「Speed: 1000Mb/s」と表示されてるから、大丈夫なのかな…？
◎ 速度測定。 :
netperf で測定してみたけど、相変わらず 20Mbps程度で、おかしいなと。
ゆうちょ銀行が「入れろ」と言っている PhishWall に疑いの目を向けたり。たぶん通信中に PhishWall が、横から通信データを掠め取って処理をしてるから、そのせいで遅くなってるんじゃないのかと…。
試しに PhishWall をアンインストール。再起動。netperf で確認してみたら、35〜38Mbpsになった。PhishWall のせいで、15〜18Mbps ほど遅くなってるということだな…。
しかしそれでも、この速度はおかしい気がする。
ゆうちょ銀行が「入れろ」と言っている PhishWall に疑いの目を向けたり。たぶん通信中に PhishWall が、横から通信データを掠め取って処理をしてるから、そのせいで遅くなってるんじゃないのかと…。
試しに PhishWall をアンインストール。再起動。netperf で確認してみたら、35〜38Mbpsになった。PhishWall のせいで、15〜18Mbps ほど遅くなってるということだな…。
しかしそれでも、この速度はおかしい気がする。
◎ Windows7のネットワーク周りの設定を変更。 :
もしかして Windows7 の設定がおかしいのではと疑い始めてググってみたら、SNPとやらを無効にしたほうがいいぞ、みたいな話を見かけて。試しに作業してみたり。
以下が参考になった。
_Windows 7のSNPを無効にする | Sahara's WebLog
_ITアーキテクトの「やってはいけない」 - ［Windows 7編］ネットワーク設定を標準で使ってはいけない：ITpro
_SNPを無効にする | Windows 7 高速化.org
_とくみつ録（旧館）: 自宅のホームサーバーが遅いので対策を講じてみた
_Windows 7 のネットワークが遅い時に試す 3 つの方法 | 初心者サーバ運営野郎の Windows に関する、ちょっとしたワザ
SNPを無効化。管理者権限でDOS窓を開いて以下を実行。
NIC側も設定。デバイスマネージャ → NICを右クリック → プロパティ、だったかな…。
ちなみに、自分のメインPCのソレは Intel 82579V だった。
netperf で試してみたけど。結果は変わらなかった…。
以下が参考になった。
_Windows 7のSNPを無効にする | Sahara's WebLog
_ITアーキテクトの「やってはいけない」 - ［Windows 7編］ネットワーク設定を標準で使ってはいけない：ITpro
_SNPを無効にする | Windows 7 高速化.org
_とくみつ録（旧館）: 自宅のホームサーバーが遅いので対策を講じてみた
_Windows 7 のネットワークが遅い時に試す 3 つの方法 | 初心者サーバ運営野郎の Windows に関する、ちょっとしたワザ
SNPを無効化。管理者権限でDOS窓を開いて以下を実行。
netsh int tcp set global rss=disabled netsh int tcp set global chimney=disabled netsh int tcp set global netdma=disabled以下を実行して確認。
> netsh int tcp show global アクティブ状態を照会しています... TCP グローバル パラメーター ---------------------------------------------- Receive-Side Scaling 状態 : disabled Chimney オフロード状態 : disabled NetDMA 状態 : disabled Direct Cache Acess (DCA) : disabled 受信ウィンドウ自動チューニング レベル : normal アドオン輻輳制御プロバイダー : none ECN 機能 : disabled RFC 1323 タイムスタンプ : disabled ** 上の autotuninglevel 設定は、少なくとも 1 つのプロファイルのローカル/ポリシー構成を 上書きするウィンドウ スケーリング ヒューリスティックの結果です。最初の3つの項目が無効(disable)になっていれば設定OK。
NIC側も設定。デバイスマネージャ → NICを右クリック → プロパティ、だったかな…。
ちなみに、自分のメインPCのソレは Intel 82579V だった。
- TCP/IPオフロードのオプション → すべて無効
- ジャンボパケット → オフ
- パフォーマンスのオプション → アダプティブインターフレームスペーシング → オン
- リンクを待機 → オフ
- 受信側スケーリング → オフ
- 大量送信オフロード V2 (IPV4) → オフ
- 大量送信オフロード V2 (IPV6) → オフ
netperf で試してみたけど。結果は変わらなかった…。
◎ iperfで速度測定。 :
netperf は暗号化して通信してるのでCPUパワーがモロに響く、という話を見かけて、別のツールを探した。iperf なるツールも使えるらしいので試してみたり。
Windows版 iperf.exe は、 _Iperf on Windows | Linhost.info から入手。iperf.exe をDL。
Ubuntu版 iperf は、sudo aptitude install iperf でインストールできた気がする。
使い方は、片方のPCで、サーバモードで起動。
もう片方のPCで、クライアントモードで起動。相手のIPを指定。
以下の環境で試した。
自信は無いけど、もしかすると iperf も、CPUパワーに左右されるのかもしれない。いや、NICを使う限り、CPUパワーが関係してくるのかもしれないけど。
何にせよ、300Mbps でやり取りできるなら、まあいいかなと。
netperf はCPUパワーをめちゃくちゃ使うツールだったから速度が全然出なかったのだろう、と思うことにする…。もしかすると双方のバージョンが違うことで頭打ちになってるのかなとも思ったけれど、VMware上で Ubuntu 動かしてやり取りしてみようとしても動作しなくて、そこらへんはお手上げに。
それにしても、Linux はメンドクセー。先輩達がメモを書き残してくれてなかったら、こりゃ手も足も出ませんわ…。
Windows版 iperf.exe は、 _Iperf on Windows | Linhost.info から入手。iperf.exe をDL。
Ubuntu版 iperf は、sudo aptitude install iperf でインストールできた気がする。
使い方は、片方のPCで、サーバモードで起動。
iperf -sポート5001番を使うらしい。
もう片方のPCで、クライアントモードで起動。相手のIPを指定。
iperf -c 192.168.1.6
以下の環境で試した。
- キューブ機(Ubuntu機) が、192.168.1.25
- メインPC(Windows7)が、192.168.1.6
> iperf -s ------------------------------------------------------------ Server listening on TCP port 5001 TCP window size: 8.00 KByte (default) ------------------------------------------------------------ OpenSCManager failed - アクセスが拒否されました。 (0x5) [312] local 192.168.1.6 port 5001 connected with 192.168.1.25 port 40726 [ ID] Interval Transfer Bandwidth [312] 0.0-10.0 sec 1006 MBytes 843 Mbits/sec > iperf -c 192.168.1.25 ------------------------------------------------------------ Client connecting to 192.168.1.25, TCP port 5001 TCP window size: 8.00 KByte (default) ------------------------------------------------------------ [208] local 192.168.1.6 port 2927 connected with 192.168.1.25 port 5001 [ ID] Interval Transfer Bandwidth [208] 0.0-10.0 sec 357 MBytes 299 Mbits/secメインPCをサーバ側にして試すと800Mbps出た。しかし、キューブ機(Ubuntu機)をサーバ側にすると 300Mbpsぐらいしか出なかった。…どゆこと？
自信は無いけど、もしかすると iperf も、CPUパワーに左右されるのかもしれない。いや、NICを使う限り、CPUパワーが関係してくるのかもしれないけど。
何にせよ、300Mbps でやり取りできるなら、まあいいかなと。
netperf はCPUパワーをめちゃくちゃ使うツールだったから速度が全然出なかったのだろう、と思うことにする…。もしかすると双方のバージョンが違うことで頭打ちになってるのかなとも思ったけれど、VMware上で Ubuntu 動かしてやり取りしてみようとしても動作しなくて、そこらへんはお手上げに。
それにしても、Linux はメンドクセー。先輩達がメモを書き残してくれてなかったら、こりゃ手も足も出ませんわ…。
[ ツッコむ ]
以上です。