Shuttle XS35 V2 に FreeBSD を入れる

結論

Shuttle XS35 V2 に FreeBSD9.0 をインストールした場合、有線 LAN で省電力対応のギガビットスイッチングハブに接続すると、デフォルトではリンクアップしない。いまどきのギガビットスイッチはほとんど省電力対応なので困る。

ファンレスサーバが作りたい

Shuttle XS35 V2 に FreeBSD9.0 をインストールした。このマシンはファンレスなので、SSD を搭載すれば完全無音サーバが実現できる。今回は SSD ではなく、USB メモリに OS をインストールしてみた。

Shuttle Japan XS35 V2

USB メモリからの起動

使った USB メモリは Buffalo の RUF2-PS16GS (16GB)。製品の写真からわかるようにやたら小さい。あとからこの PC がかなり発熱することがわかったので、USB メモリは延長ケーブル経由で本体から少し離しておくことにした。

Buffalo: RUF2-PS16GS

FreeBSD のインストールと USB メモリからの起動は問題なく終わった(以前別の製品で、どうしても OS をインストールできなかった USB メモリがあった。経験上、起動メディアに使うなら国産の USB メモリにした方が良い気がする)。USB メモリは /dev/da0 として認識されている。

% df -h
Filesystem       Size    Used   Avail Capacity  Mounted on
/dev/da0p2      13G    6.9G    5.8G    54%    /
devfs               1.0k    1.0k      0B   100%    /dev
tmpfs               953M    4.0k    953M     0%    /tmp

OS の起動はさすがに HDD/SSD より遅いが、一度起動してしまえばさほどストレスなく利用できる。OS の起動時間を計ってみたら下記の通りだった。

• 電源ONからブートメニュー画面が表示されるまで:72秒
• 電源ONからログインプロンプトが出るまで: 101秒

USBの読み書き速度は

• 読み込み: 18.5 MByte/s
• 書き込み: 3.4 MByte/s

くらいだった。

有線 LAN の問題

Shuttle XS35 V2 の有線 LAN には JMicron JMC250　というチップが使われているらしい。FreeBSD9.0 にはドライバが用意されていて、何もしなくても jme0 として認識された。

ところがここで問題が発生。この PC、特定のギガビットのスイッチングハブに接続した場合だけ通信できない。通信できない場合は、スイッチングハブの LINK ランプもつかない(リンクアップしない)。 

JMicron JMC250 を省エネルギー対応のハブと接続するとリンクが確立しないというのは、実は既知の問題で、FreeBSD9.0 の jme のマニュアルページに明記してあった。

% man jme
CAVEATS
(**snip**)
There are two known 1000baseT link establishment issues with JMC25x.  If
the full mask revision number of JMC25x controller is less than or equal
to 4 and link partner enabled IEEE 802.3az Energy Efficient Ethernet fea-
ture,  the controller would not be able to establish a 1000baseT link.
Also if the length of cable is longer than 120 meters, controller can not
establish a 1000baseT link.  The known workaround for the issue is to
force manual link configuration with 100baseTX instead of relying on
auto-negotiation.  The full mask revision number of controller could be
checked with verbose kernel boot option.  Use lower nibble of chip revi-
sion number to get full mask revision of the controller.

訳してみると以下の通り(full mask revision numberについては後述)。

%man jme
警告
(略)
JMC25x には 1000baseT でのリンクに関して2つの問題がある。JMC25x　の full mask revision number が 4以下で、接続先が IEEE 802.3az 省電力型イーサネットを有効にしている場合、このコントローラは 1000baseT でリンクを確立できない。また、ケーブル 長が120m以上の場合も1000baseT でリンクを確立できない。対策はオートネゴシエーションを使わず手動で100baseTX接続を設定することである。full mask revision number は詳細なカーネル起動オプションで確認できる。full mask revision number はチップのリビジョンの低ニブルから得られる。

低速でも接続できればいいというなら

# ifconfig jme0 media 100baseTX

を実行すれば、省エネルギー対応のハブとも 100Mbps で接続できる。起動時に毎回設定するなら /etc/rc.conf に

ifconfig_jme0="inet 192.168.100.100 media 100baseTX"

などと書いておけばよい。ただせっかくのギガビット NIC なのに100Mbps接続になってしまう。

省電力でないハブに変えて試してみるとギガビットで接続できた。でもいまどき省電力でないハブなんてなかなか手に入らない。

 1Gbit接続可能だったハブ(省電力機能がない製品)

• Buffalo LSW-GT-8NP
• FUJITSU SH1508AT

1Gbit接続不可だったハブ(製品の箱に「省電力」とは書いてあるが IEEE 802.3az とは書いていない)

• Buffalo LSW3-GT-5NS
• ELECOM LAN-GSW08/PHB 

補足

マニュアル中の full mask revision number とは「詳細なカーネル起動オプション」を指定して起動すると表示される 「チップのリビジョン」の下位4bit らしい。「詳細なカーネル起動オプション」を指定するために、OS のブート画面で [2] キーを押して止め "boot -v" と入力して起動してみた。/var/log/messages に残ったログは以下の通り。「チップのリビジョン」は 0x23 で「低ニブル(下位4bit)」は 3。4以下なので、確かにギガビット接続に問題のあるチップに該当していたようだ。

Aug 13 11:33:50 lait kernel: jme0: <JMicron Inc, JMC25x Gigabit Ethernet> port 0xdc00-0xdc7f,0xd800-0xd8ff mem 0xfeaf4000-0xfeaf7fff irq 17 at device 0.5 on pci2

Aug 13 11:33:50 lait kernel: jme0: MSIX count : 8

Aug 13 11:33:50 lait kernel: jme0: MSI count : 8

Aug 13 11:33:50 lait kernel: jme0: attempting to allocate 1 MSI-X vectors (8 supported)

Aug 13 11:33:50 lait kernel: msi: routing MSI-X IRQ 257 to local APIC 0 vector 50

Aug 13 11:33:50 lait kernel: jme0: using IRQ 257 for MSI-X

Aug 13 11:33:50 lait kernel: jme0: Using 1 MSIX messages.

Aug 13 11:33:50 lait kernel: jme0: PCI device revision : 0x0250

Aug 13 11:33:50 lait kernel: jme0: Chip revision : 0x23
Aug 13 11:33:50 lait kernel: jme0: ethernet hardware address not found in EEPROM.
Aug 13 11:33:50 lait kernel: jme0: PHY is at address 1.
Aug 13 11:33:50 lait kernel: jme0: Read request size : 512 bytes.
Aug 13 11:33:50 lait kernel: jme0: TLP payload size : 128 bytes.
Aug 13 11:33:50 lait kernel: miibus0: <MII bus> on jme0
Aug 13 11:33:50 lait kernel: jmphy0: <JMP211 10/100/1000 media interface> PHY 1 on miibus0
Aug 13 11:33:50 lait kernel: jmphy0: OUI 0x00d831, model 0x0021, rev. 1
Aug 13 11:33:50 lait kernel: jmphy0:  none, 10baseT, 10baseT-FDX, 10baseT-FDX-flow, 100baseTX, 100baseTX-FDX, 100baseTX-FDX-flow, 1000baseT, 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, 1000baseT-FDX-flow, 1000baseT-FDX-flow-master, auto, auto-flow
Aug 13 11:33:50 lait kernel: jme0: bpf attached

Aug 13 11:33:50 lait kernel: jme0: Ethernet address: 80:ee:73:**:**:**

【2013/2/9追記】
このサーバが毎晩深夜 3:00 にkernel: panic　する現象が発生。/var/log/messages には

  Jan 20 12:42:10 lait kernel: panic: ufs_dirbad:  /: bad dir ino 243130 at offset 76: mangled entry

というのが残っていたが原因不明。検索しても同じ例はあまり見つからない。シングルユーザモードで ルートファイルシステムに fsck を実行してみても治らない。

試行錯誤の結果、毎晩自動で実行されるセキュリティチェックの中の /etc/periodic/secirity/110.neggrpperm がkernel: panicの原因だったので、このファイルを削除したところ落ちなくなった。このスクリプトはファイルのパーミションを確認して、others に与えられているパーミションが group に与えられていない、というファイルを探すためのものらしい。