幸い、 VIA Technologies が VIA Arena にて Linux 用の GPL なドライバ (vntwusb カーネル モジュール) VT6656_Linux_src_v1.19_12_x86.zip を公開しているので、 Linux 2.6.28 までは 簡単に無線LAN を利用できる。 Linux 2.6.29 になって、 「struct net_device」 (カーネル ソース include/linux/netdevice.h の中で定義されている) が変更されたので、 そのままではコンパイルできなくなったが若干のパッチをあてることで対応可能 (ではあるが、後述する方法のほうがお手軽)。

ところが、 VIA Arena が模様替えして、 上記無線LAN ドライバがダウンロードできなくなってしまった。 正確に言うと、 VT6656_Linux_src_v1.19_12_x86.zip のファイル自体はまだダウンロードできるのだが、 そこへ至るページが無くなってしまっている (私が見つけられないだけならいいのだが...)。 これは VIA Technologies としてはサポートを行なわないという意思表示なのか？

VIA Technologies がサポートしてくれなくても、 GPL で公開されているのだからなんとかなるだろうと思っていたら、 既に Linux 2.6.32-rc1 に Staging drivers (not of the "normal" Linux kernel quality level) として含まれていた。 内容を見てみると、 VIA Arena で公開されていたドライバほとんどそのままである。

というわけで、 Linux 2.6.32-rc1 のディレクトリ drivers/staging/vt6656 を Linux 2.6.30.8 の drivers/staging/ の下へそのままコピーし、 以下のパッチ (2行追加するだけ) をあててカーネルを再構築してみたら、 vt6656_stage.ko が生成された。

diff -ur linux-2.6.30.8.org/drivers/staging/Kconfig linux-2.6.30.8/drivers/staging/Kconfig
--- linux-2.6.30.8.org/drivers/staging/Kconfig	2009-09-25 00:28:02.000000000 +0900
+++ linux-2.6.30.8/drivers/staging/Kconfig	2009-09-28 13:49:36.026075562 +0900
@@ -115,5 +115,7 @@
 
 source "drivers/staging/serqt_usb/Kconfig"
 
+source "drivers/staging/vt6656/Kconfig"
+
 endif # !STAGING_EXCLUDE_BUILD
 endif # STAGING
diff -ur linux-2.6.30.8.org/drivers/staging/Makefile linux-2.6.30.8/drivers/staging/Makefile
--- linux-2.6.30.8.org/drivers/staging/Makefile	2009-09-25 00:28:02.000000000 +0900
+++ linux-2.6.30.8/drivers/staging/Makefile	2009-09-28 14:06:25.949515761 +0900
@@ -40,3 +40,4 @@
 obj-$(CONFIG_HECI)		+= heci/
 obj-$(CONFIG_LINE6_USB)		+= line6/
 obj-$(CONFIG_USB_SERIAL_QUATECH_ESU100)	+= serqt_usb/
+obj-$(CONFIG_VT6656)		+= vt6656/

起動してみると自動認識してドライバが組み込まれた:

vt6656_stage: module is from the staging directory, the quality is unknown, you have been warned.
VIA Networking Wireless LAN USB Driver 1.19_12<5>VIA Networking Wireless LAN USB Driver Ver. 1.19_12

vntwusb.ko と vt6656_stage.ko でモジュール名は異なるが、 バージョンはどちらも 1.19_12 で同じ。 「Staging」 だから 「Linux カーネルの品質レベルではない」 とのことだが、 今のところ WEP および WPA2 EAP-TLS で安定して接続できている。

OLEVIA X10A-1160 は、 SOTEC C101 と (キーボード配列や天板のデザインを除けば) 同等であるため、 以下の対策は SOTEC C101 に Ubuntu 等の GNU/Linux をインストールして使う場合も、 そのまま適用できるはず。

i8042 のバグ対策を行なってタッチパッドを認識させる

他のいくつかのノートPC (dynabook Satellite P10, Thinkpad R31, Lifebook P7010, Dell XPS M1530 など) と同じく、 OLEVIA X10A-1160 (確認していないが、おそらく SOTEC C101 も同様) のキーボード/マウス コントローラ i8042 互換チップにはバグがある。 OLEVIA X10A-1160 の場合、カーネル起動時に以下のようなログを出力する:

PNP: PS/2 Controller [PNP0303:PS2K,PNP0f13:PS2M] at 0x60,0x64 irq 1,12
i8042.c: Detected active multiplexing controller, rev 1.1.
serio: i8042 KBD port at 0x60,0x64 irq 1
serio: i8042 AUX0 port at 0x60,0x64 irq 12
serio: i8042 AUX1 port at 0x60,0x64 irq 12
serio: i8042 AUX2 port at 0x60,0x64 irq 12
serio: i8042 AUX3 port at 0x60,0x64 irq 12
	...(中略)...
input: PS/2 Generic Mouse as /devices/platform/i8042/serio4/input/input9
psmouse.c: Failed to enable mouse on isa0060/serio4

存在しないはずの外付けポート (AUX0～3) コントローラ (multiplexing controller) を認識してしまうようだ。 このため、 タッチパッド (SynPS/2 Synaptics TouchPad) が使えなくなってしまう。 この問題は、 カーネルパラメータに i8042.nomux=1 を追加することによって回避できる。 例えば GRUB の設定ファイル /boot/grub/menu.lst に、

title           Ubuntu 8.04.1, kernel 2.6.24-23-generic
root            (hd0,0)
kernel          /boot/vmlinuz-2.6.24-23-generic root=UUID=(省略) ro quiet splash vga=789 i8042.nomux=1
initrd          /boot/initrd.img-2.6.24-23-generic
quiet

といった感じで 「i8042.nomux=1」 を追加すればよい。 Linux を再起動すると、

PNP: PS/2 Controller [PNP0303:PS2K,PNP0f13:PS2M] at 0x60,0x64 irq 1,12
serio: i8042 KBD port at 0x60,0x64 irq 1
serio: i8042 AUX port at 0x60,0x64 irq 12
	...(中略)...
Synaptics Touchpad, model: 1, fw: 5.10, id: 0x258eb1, caps: 0xa04711/0x0
input: SynPS/2 Synaptics TouchPad as /devices/platform/i8042/serio1/input/input7

などと出力し、 無事 SynPS/2 Synaptics TouchPad が認識できた。

なお Linux は、 i8042 にバグを持つ PC で問題を回避できるよう、 PC のブラックリストを持っている。 すなわち linux/drivers/input/serio/i8042-x86ia64io.h で定義されている配列 i8042_dmi_nomux_table に PC の ID を登録しておくと、 該当する PC では自動的に i8042.nomux=1 が設定される仕掛けだが、 あいにく OLEVIA X10A-1160 は固有の ID を持っていないようだ:

# head /sys/class/dmi/id/{sys_vendor,product_*}
==> /sys/class/dmi/id/sys_vendor <==
 

==> /sys/class/dmi/id/product_name <==
 

==> /sys/class/dmi/id/product_serial <==
Not Applicable

==> /sys/class/dmi/id/product_version <==
Not Applicable

DMI のベンダ名、プロダクト名が共に空白になっている。

無線LAN ドライバ vntwusb をインストールする

OLEVIA X10A-1160 (確認していないが、おそらく SOTEC C101 も同様) は、 無線LAN チップとして VIA Technologies の VT6656 を使用している。 しかし残念ながらこのチップは、 現時点の Linux 標準カーネルではサポートしていない。 したがってドライバをインストールする必要がある。

まず VIA Technologies のサポートページ VT6656 WLAN Linux Driver Source から、 最新版のドライバ vt6656_wlan_linux_v118.zip (1/18 現在) をダウンロードする。 展開して make すれば、 VT6656 用のカーネルモジュール vntwusb.ko が作られる。

% wget http://www.viaarena.com/Driver/vt6656_wlan_linux_v118.zip
--10:19:24--  http://www.viaarena.com/Driver/vt6656_wlan_linux_v118.zip
           => `vt6656_wlan_linux_v118.zip'
Resolving www.viaarena.com... 74.54.151.131
Connecting to www.viaarena.com|74.54.151.131|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 4,483,650 (4.3M) [application/x-zip-compressed]

    0K .......... .......... .......... .......... ..........  1%   68.92 KB/s
	...(中略)...

% unzip vt6656_wlan_linux_v118.zip
Archive:  vt6656_wlan_linux_v118.zip
   creating: VT6656_WLAN_Linux_V118/
   creating: VT6656_WLAN_Linux_V118/driver/
	...(中略)...
% cd VT6656_WLAN_Linux_V118/driver
VT6656_WLAN_Linux_V118/driver % make
make -C /lib/modules/2.6.24-23-generic/build SUBDIRS=/home/sengoku/VT6656_WLAN_Linux_V118/driver modules
make[1]: ディレクトリ `/usr/src/linux-headers-2.6.24-23-generic' に入ります
  CC [M]  /home/sengoku/VT6656_WLAN_Linux_V118/driver/main_usb.o
	...(中略)...
  LD [M]  /home/sengoku/VT6656_WLAN_Linux_V118/driver/vntwusb.ko
make[1]: ディレクトリ `/usr/src/linux-headers-2.6.24-23-generic' から出ます

あとは、make install して modprobe vntwusb するだけ。

VT6656_WLAN_Linux_V118/driver % sudo make install
make -C /lib/modules/2.6.24-23-generic/build SUBDIRS=/home/sengoku/VT6656_WLAN_Linux_V118/driver modules
mkdir -p /lib/modules/2.6.24-23-generic/kernel/drivers/net
install -m 644 -o root vntwusb.ko /lib/modules/2.6.24-23-generic/kernel/drivers/net
/sbin/depmod -a || true
VT6656_WLAN_Linux_V118/driver % sudo modprobe vntwusb

ただし前もって、 カーネルモジュールを make するための環境を整えておく必要がある。 Ubuntu (というか debian) の場合であれば、 module-assistant パッケージと linux-headers パッケージをインストールしておけばよい。 あるいは、 上記 VT6656_WLAN_Linux_V118/driver ディレクトリを、 Linux カーネルソースにコピーしてカーネルを再構築してもよい。

私は、 Linux カーネルソースツリーに、 linux/drivers/net/wireless/vntwusb ディレクトリを作って、 VT6656_WLAN_Linux_V118/driver ディレクトリの内容をコピーし、 linux/drivers/net/wireless/Kconfig および linux/drivers/net/wireless/Makefile に以下のパッチをあてている。

--- linux-2.6.27.11.org/drivers/net/wireless/Kconfig	2008-10-10 07:13:53.000000000 +0900
+++ linux-2.6.27.11/drivers/net/wireless/Kconfig	2009-01-06 14:52:10.459276155 +0900
@@ -702,5 +702,6 @@
 source "drivers/net/wireless/b43legacy/Kconfig"
 source "drivers/net/wireless/zd1211rw/Kconfig"
 source "drivers/net/wireless/rt2x00/Kconfig"
+source "drivers/net/wireless/vntwusb/Kconfig"
 
 endmenu

diff -ur linux-2.6.27.11.org/drivers/net/wireless/Makefile linux-2.6.27.11/drivers/net/wireless/Makefile
--- linux-2.6.27.11.org/drivers/net/wireless/Makefile	2008-10-10 07:13:53.000000000 +0900
+++ linux-2.6.27.11/drivers/net/wireless/Makefile	2009-01-06 14:52:10.491275159 +0900
@@ -58,6 +58,7 @@
 
 obj-$(CONFIG_IWLWIFI)	+= iwlwifi/
 obj-$(CONFIG_RT2X00)	+= rt2x00/
+obj-$(CONFIG_VNTWUSB)	+= vntwusb/
 
 obj-$(CONFIG_P54_COMMON)	+= p54/
 

Ubuntu などのディストリビューションのアップデートに頼らずに、 カーネルのバージョンアップを行なっている場合は、 カーネルソースツリーに組み込んでおく方が、 ドライバ込みでカーネルを再構築できるので手間が省ける。

Olevia X10A 10.1" notebook

物価が安い香港と言えど、HK$3000 以下の NetBook というと EeePC 701SDX あたりになってしまうわけで、 メモリ 1GB, HDD 160GB の Atom N270 で HK$2880 というのは興味深い。 その場で悩み込むこと数分間。 店員がべらべら説明を始めたが、広東語なので何も分からない (^^;)。

同等スペックの NetBook としては、 例えば acer Aspire One AOA150 がある。 メモリ 1GB, HDD 160GB, Atom N270, WSVGA, 無線LAN あたりは同等で、 違いは Aspire One AOA150 の方が若干小さく (画面サイズも 1インチほど小さい)、 LAN が 100Mbps (X10A は 1Gbps) で、 Webカメラの画素数が 30万画素 (X10A は 130万画素) である点など。 Aspire One AOA150 の最安値は 35000円くらい？

何より OS が Linux というのがいい。 香港版の Windows XP なんて広東語を喋れない私には無用であるわけで、 HK$600 くらいはする Windows XP ライセンスが付いた PC は避けたいところ。 一応 「Windows Compatible」 を謳っていて 「Designed for Microsoft WindowsXP」 シールも貼ってある。

買う一歩手前まで行ったのだが、最後の背中のひと押しが無かったのと、 妻がホテルで待っているというのがあって、 これから帰る旨を電話で伝えて、 後ろ髪を引かれつつお店を後にした。

ところが、

1階まで階段を降りて旺角電腦中心を出ようとしたら、 入口のところで Olevia X10A の屋外展示を行なっていた。 4階の店頭では数多くの PC の内の一台という感じで、 Olevia X10A を売っていたが、 ここでは Olevia X10A だけ。 つい 30分ほど前にここ (旺角電腦中心の入口) を通ったときは何もやっていなかったので、 今まさに展示を始めたばかりのように思われる。 展示に気付いて足を止める人が周囲にどんどん増えてくる。

配ってるチラシ ↓ に、「迎接白色聖誕」などと書いてあるから、 クリスマスキャンペーンなのかも。

後日、 総販売代理店である SCHOT (South China House Of Technology consultants ltd., 南中國科技顧問有限公司) の Web ページを見てみると、 OLEVIA X10A 10吋Notebook 震撼推出 迷你簡約純白 迎接白色聖誕 などと書いてある。 そして発表日は、 私が旺角電腦中心でキャンペーンを見た日と同じ 12月 22日だった。

Atom N270 1.6GHz は雙核心 (dual core) じゃないだろ～ と思いつつも、 確かにこの値段は悪くないし、 キャンペーン当日に居合わせたのも何かの縁と思い、買うことに決めた。 妻に電話で、これから PC を買うので少し帰りが遅れると話してから、 スタッフに買う旨を伝えると、エレベータで 4階に連れていかれて、 先ほど私が買おうか買うまいか悩んでいた、 道亨顧問有限公司 Dorman Consultants Ltd の店頭 ↓ に戻る。

実は私は海外の店頭で PC を買うのは初めてで、スタッフ ↑ が箱を開けて PC を取り出し、 電源を入れて動作を確認してくれと言ってきたので、少々戸惑う。 確認が必要なほど信頼ができないものなのか？ 周辺機器などを米国で買ったことなら何度でもあるが、 購入した製品の箱を店頭で開けて確認を求められた経験は一度もない。 が、せっかくなので液晶のドット抜けが無いか目を凝らして確認させてもらった。 OS は Ubuntu 8.04 LTS だった。 これなら言語設定を変更するだけで日本語で使えるはず。 一応 WindowsXP 用のドライバが入った CD-ROM も渡してくれた。

ホテルに戻ってさっそく動かしてみる。 ユーザ 「olevia」 で自動ログインする設定になっていた。 [System]→[Administration]→[Language Support] を選んで、 「Supported Languages」 の中から「Japanese」 にチェックを付けて、 「Apply」 ボタンを押す。 すると Ubuntu では当然のことながらパスワード入力を求められるが、 困ったことにユーザ 「olevia」 のパスワードが分からない (^^;)。 しばらくパスワード ハックよろしく思いつく限りのパスワードを入力してみたが、 いずれもダメ。

マニュアルのどこかにパスワードの初期値に関して記述がないかと思ったのだが、 ユーザ 「olevia」 だから Ubuntu のマニュアルを探しても無駄だろうし、 かといって Olevia 固有のマニュアルはどこにも見当たらない。 仕方ないので最後の手段、 USB メモリから起動して、 /etc/shadow の中の olevia のパスワードを削除する、 という方法でパスワードを設定し直した。

というわけで無事日本語環境に切替えることができて、 ごくごく普通の Ubuntu マシンとして使えるようになった。 キーボードは英語の刻印のみなので、 ぱっと見には中国向け PC とは思えないくらい。 電源アダプタは 100-240V 対応で、 電源コードのプラグこそ BF タイプではあるものの、 よくあるメガネ型コネクタなので、 日本の電源コードを代わりに使うことができる。

香港の電源プラグが BF タイプという (世界全般から見ると) やや特殊なタイプであるためか、 電脳街に限らず至るところで電源プラグの変換アダプタを売っている。 私は、鴨寮街で買った。 HK$5 だったが、ものは試しと値切ってみたら、HK$4 (46円) になった。

ネジ一つで裏面パネルを外すことができて、 写真 ↓ 左側上から CPU のヒートシンク, メモリ, 無線LAN モジュール (VIA VT6656)、 そして右側には 2.5 インチ HDD が見える。

無線LAN モジュールには、 Model: VNT6656GEV00 と書かれている。 若干モデル番号が違うが、 VIA Networking VNT6656G6A40 54 MBps Wireless USB Module (US$36) と同等のもの (ただしコネクタ形状が USB には見えない) と思われる。 このモジュールは Ubuntu 8.04 では未サポートで、 Building the VT6656 Linux Driver for Ubuntu に書かれているように、 VIA が公開している VT6656 WLAN Linux Driver Source を元にカーネルモジュールを make する必要がある。

Olevia X10A にプレインストールされている Ubuntu には、 このカーネルモジュール vntwusb.ko が含まれていた。 おそらく同様の方法で make したカーネルモジュールなのだろう。
[システム]→[ハードウェア・ドライバ] を見ると、 プロプライエタリなドライバとして、 「VIA Networking Wireless LAN USB Driver」 が有効になっている。

1/2 追記:

コメント欄で、この PC は SOTEC C101W4 と同じと教えていただいたので、 ビックカメラ ラゾーナ川崎店で見てきた。 なるほど、天板のデザインが若干違うのと、 日本語キーボードである点を除くと、そっくりである。 店頭価格は 49,800円だった。 ちなみに、ビックカメラ.com だと SOTEC C101W4 は 44,800円。

SOTEC C101W4 minimumPC 10.1型ワイド液晶

ほとんど差異がない中で、 ハードディスクの容量が 120GB (OLEVIA X10A は 160GB) になっているのが目を引く。 いまどき 120GB でも 160GB でもコスト的な差はほとんどない (最安値で比較すると、WD1600BEVT が 4670円に対し、WD1200BEVT が 4966円と、 むしろ 160GB の方が安い) だろうに、 あえて 120GB を採用しているのは上位機種 (R5シリーズは 160GB) と差別化するため？

他に、 キーボード (OLEVIA が英語で SOTEC が日本語)、 天板のデザイン、 SOTEC には Linux 版がない、という違いもある。 個人的には、Linux 版が選べて (つまり Windows ライセンス料が不要なぶん安い)、 英語キーボードな OLEVIA のほうが好ましい。

Aug 18 10:31:30 senri [144077.315932] tg3: eth0: Link is down.
Aug 18 10:33:57 senri [144201.921009] tg3: eth0: Link is up at 1000 Mbps, full duplex.
Aug 18 10:33:57 senri [144201.921228] tg3: eth0: Flow control is on for TX and on for RX.

Aug 18 10:31:30 asao [894103.906436] tg3: eth0: Link is down.
Aug 18 10:33:57 asao [894253.756472] tg3: eth0: Link is up at 1000 Mbps, full duplex.
Aug 18 10:33:57 asao [894253.756472] tg3: eth0: Flow control is on for TX and on for RX.

この日 8/18 はたまたま早朝から出張だった (帰宅したのは翌日 8/19 23:00 近く) ので link down に気付かなかった (もちろんヘルスチェックは行なっているが自宅なのでタイムアウトは長め)。 留守中、 link down 後しばらくたつと link up (正常状態に復旧)、 という繰り返しが何度も起きたようだ。 ログから down 時間を集計してみるとこんな感じ:

3 秒で復旧することもあれば、 20分以上落ちたままのこともあり規則性がないが、 いったん link down/up すると、 down/up を何度か短時間に繰り返す傾向がある。 また次第に down する頻度が上がり、 down している時間も長くなる傾向にあった。 複数のマシンで同時に link down することから、 ハブの故障だと判断できる。 ハブは、 コレガ製 1000BASE-T/100BASE-TX/10BASE-T 8ポート スイッチングHUB CG-SW08GTV2。 2005年11月9日に購入したものなので1年の保証期間は切れているものの、 まだ3年弱しか経過しておらず自宅LAN の中では比較的新しいハブである。

ちょっと壊れるのが早すぎなんじゃないかと思いつつ、 とりあえず余っていた 100Mbps スイッチング・ハブと置き換えて急場をしのぎつつ、 秋葉原に新しいハブを買いに行った。 買ったのは同じくコレガ製の、 1000BASE-T/100BASE-TX/10BASE-T 8ポート スイッチングハブ CG-SW08GTR。 T-Zone で 3742円だった。 8 port の gigabit が 4000円以下とは、 ずいぶん安くなったものだ (標準価格は 9975円)。

というわけで故障したハブを新しいハブで置き換えて一件落着なのであるが、 3年たたずに故障し、 しかも断続的に down するという症状が腑に落ちなかったので、 壊れた CG-SW08GTV2 の筐体を開けてみた。 すると...

このハブは「ACアダプタを使用しない電源内蔵型」なので、 内部に電源基板 (写真上方) があって、 Switch 基板とケーブルでつながっているのだが、 そのケーブルのコネクタが ↑ の写真のように外れかかっていた。 このケーブルは元々ギリギリの長さしかなく常に若干の張力が働いていて、 2年以上かけて少しづつコネクタが浮いていき、 ついに接触不良を起こすほどに外れてしまったのだろう。 一応このコネクタには抜け防止のツメがあるのだが、 ケーブルが引っ張られる状態が続いたため、 ソケット側が徐々に変形してしまったのかも (設計ミス?)。

コネクタをはめ直して通電してみたら、 丸2日たった今も、 一度も link down を起こさずに正常動作し続けている。 コネクタが外れたことによる接触不良だけが link down の原因だったならば、 コネクタさえきちんと固定しておけば今後は安定して動作することが期待できる。 買い替えを早まったか...? ;-(

iTCO_vendor_support: vendor-support=0
iTCO_wdt: Intel TCO WatchDog Timer Driver v1.02 (26-Jul-2007)
iTCO_wdt: failed to reset NO_REBOOT flag, reboot disabled by hardware
iTCO_wdt: No card detected

この「reboot disabled by hardware」とは何なのかを調べてみると、 Intel I/O Controller Hub 7 (ICH7) Family Datasheet の 78ページ、 Table 2-23. Functional Strap Definitions (Sheet 3 of 3) に、

と書いてある。 つまり ICH7 の SPKR 端子 (Ball# A19) はスピーカ出力なのであるが、 入力端子としても使われていて、 PWROK 入力端子 (Ball# AA4) の立ち上がりエッジ時 (すなわち電源投入時) において SPKR 端子が H レベルであれば、 「No Reboot」モードに固定される。

「No Reboot」モードというのは、 TCO タイマ (つまり Watchdog Timer) による再起動を行なわないモードで、 通常はソフトウェアでこのモードの設定/解除が可能なのであるが、 SPKR 端子によって「固定される」と No Reboot モードのまま変更できなくなる。

具体的には、 「No Reboot」モードの設定/解除は、 ICH7 の「NO REBOOT bit」に 1/0 を書込むことによって行ない、 逆にこの「NO REBOOT bit」を読むことによって現在のモードを確認できる。 Linux カーネルの drivers/watchdog/iTCO_wdt.c に、 このビットを解除し、解除できたか確認するコードがある:

static int iTCO_wdt_unset_NO_REBOOT_bit(void)
{
	...
	/* Unset the NO_REBOOT bit: this enables reboots */
	if (iTCO_wdt_private.iTCO_version == 2) {
		val32 = readl(iTCO_wdt_private.gcs);
		val32 &= 0xffffffdf;
		writel(val32, iTCO_wdt_private.gcs);

		val32 = readl(iTCO_wdt_private.gcs);
		if (val32 & 0x00000020)
			ret = -EIO;
	...
	return ret; /* returns: 0 = OK, -EIO = Error */
}

この iTCO_wdt_unset_NO_REBOOT_bit 関数は、 GCS (General Control and Status Register, オフセット 0x3410) のビット5 に 0 を書込むことによって No Reboot モードの解除を試み、 続いてこのビットを読んで正しく 0 に変わっているか確認し、 確認結果を返す。 つまりこの関数が正常に 0 を返せば、 ICH7 の Watchdog Timer が利用可能であることを示し、 -EIO を返せば、 (No Reboot モード固定なので) 利用不可能であることを示す。

というわけで、 DELL PowerEdge SC440 で Intel TCO Watchdog Timer が利用できない理由は、 電源投入時に SPKR 端子に電圧がかかってしまっていて、 No Reboot モード固定になっているためだろう。 SPKR 端子は内部的にプルダウン (20kΩ) されているので、 SPKR 端子につながっているスピーカを切り離せば SPKR 端子は L レベルになり、 Watchdog Timer が利用できるようになるはず。

PowerEdge SC440 の基板上のスピーカ (RDI # DMT-1206. 48Ω audio tone transducer) 周辺を見てみると:

intel NH82801GR と書いてあるチップが ICH7R で、 その左にある円筒形の部品がスピーカ (円周に沿って RDI-DMT-1206 と書いてある) である。

このスピーカを破壊して (一個 50円程度だし) 基板表面から取り除くという手も考えられるが、 基板のパターンを破損する恐れもある。 きちんと半田を融かして引き抜くには基板を裏返さなければならない。 ICH7R の A19 端子からスピーカまでの配線が特定できれば、 そのパターンを切るという手も考えられるが、 基板を裏返さずに表面に見える配線だけから特定するのは無理っぽい。

あいにく私の PowerEdge SC440 は現在の GCD の メイン・サーバ なので (ちなみに サブ・サーバは HP ProLiant ML115)、 あまり長時間停止させるのは好ましくなく、 基板の取外しが必要となるような作業は (少なくとも今は) 躊躇している (格安サーバ なのだから、 実験用にもう一台 PowerEdge SC440 を買っておくべきだった)。 なんらかの方法 (もちろんスピーカの機能を損なわない方法がベスト) で 電源投入時の SPKR 端子を L レベルに設定し、 PowerEdge SC440 の ICH7R の Watchdog Timer を利用できたかたは、 トラックバック等をいただけると幸いである。

どきどきしながら「請求書 INVOICE」と書かれた一枚目の書類に目を通すと、 請求額は 1000円。 そんなに高額の請求ではなかったので一安心。 内訳を見ると、

関税？ 日本って工業製品に対して関税なんてかけていたっけ？ と思いつつ
二枚目の「輸入許可通知書」に目を通すと、

なるほど、 メーカが申告した価格 (CIF) $108.00 に対して約 5% の消費税がかかる、 ということで納税額が 500円なのか。 でも「関税・消費税特別手数料」って何なのだろう？ 少なくともこの「輸入許可通知書」には「特別手数料」の文字は見当たらない。

まあ高々 1000円だから払っちゃおうか、という考えが頭をよぎる。 ご丁寧にコンビニ払いの用紙まで添付されている。 コンビニ払いか銀行振込を選択可能なようだ。

消費税ってのはいわゆる付加価値税のことである (なぜ VAT (= 付加価値税) という世界的に一般的な名称ではなく、 「消費税」という聞きなれない名称にしたのやら...)。 物品に価値が加わったときにその増分に対して一定割合 (現在は 5%) を納税するのが趣旨であるが、 故障したハードディスクを交換したことが「付加価値」に該当するのだろうか？

確かに私にとっては、 故障したハードディスクは価値ゼロで、 交換してもらったハードディスクは 13000円 (現時点での WD10EACS の小売価格) くらいの価値があるから一見価値が増えたように見えるが、 より厳密に考えると「故障したハードディスク」には「RMA 保証」がついていた (だからこそ交換してもらうことができた) ので、 13000円の価値があったと言ってもよい。

そもそも消費税は、このハードディスクを買ったときに支払っている。 当時は 28140円もしたから、なんと 1340円 (本体価格 26800円の 5%) も、 消費税を払っているわけである。 この上、さらに 500円も消費税を払わされてはかなわない。 これは同一物に対する二重課税ではないのか～っ。 もんもんと考えているうちに、だんだんハラが立ってきた (^^;)。

というわけで、 なんとかこの理不尽な課税を回避できないか試みることにした。 もちろん、たかが 500円の課税であるので回避できたところで、 かけた労力に見合うわけはないのだが、 まあなにごとも経験である。 軽減できる税金は最大 500円であっても、 軽減交渉という経験はプライスレス。

フェデラル・エクスプレスからの請求書には、 末尾に次のように書いてあった。

Inquiry by e-Mail
e-Mail による請求・お支払に関するお問い合わせ
電話、FAXに加えe-mail による請求・お支払に関する お問い合わせも承ります。
アドレス：　seikyukanri@npac.fedex.com

e-mail で問い合わせできるというのはとてもありがたい。 なんせ取り返そうとしている税金はわずか 500円なのであるから、 電話で問合わせたりしたら電話代だけで赤字になってしまいかねない。 とりあえず次のようなメールを書いてみた:

Subject: 消費税立替金に関して
Date: Wed, 09 Jul 2008 16:34:16 +0900

フェデラルエクスプレス御中

仙石です。昨日、郵便で消費税の請求書が届きました。

顧客番号: JPNXXXXXXXXXXX
請求書番号: X-XXX-XXXXX
請求書発行日: 06/30/2008
合計: JPY 1,000

これは、輸入した物品に関して、

消費税 500円
消費税特別手数料 500円

の合計 1000円の請求であると理解したのですが、

今回輸入したのは、ハードディスクであり、これは故障品の交換品としてメーカ
から送付されたものです。つまり次のような経緯となっています。

(1) 2007年11月30日  新品を日本国内で購入 (28140円 消費税込)
(2) 2008年 5月 2日  故障
(3)        6月24日  故障品をメーカ(シンガポール)へ発送
(4)           26日  故障品に対する代替品をメーカが発送 (CIF $108)
(5)           27日  通関

すなわち物品 (ハードディスク) の消費税は既に 
(1) の段階で 1340円を納入済です。

(4) において物品に対して付加価値が加わったわけではないことを考えると、
(5) で再度消費税を納入することは同一物品に対して消費税を二度支払うことに
なってしまいます。

これは二重課税に相当すると思われるので、消費税額に関して異議申し立てを行
なおうと思います。すでに御社が立て替えてしまった 1000円について、どのよう
に取扱うべきか教えて頂けると幸いです。

お手軽なのでまずはメールで問合わせを行なったわけであるが、 フェデラル・エクスプレスはあくまで通関にかかる税金を 「立て替えて」くれただけであるので、 課税に関する文句をフェデラル・エクスプレスに言うのはお門違いであろう。

課税に対する苦情はやはりお役人に対して言わないと、 ということで翌日 税関相談官に電話してみた。 税関相談官というのは、

税関相談官は、輸出入手続等に関する相談・苦情を処理することにより、 相談等の依頼者に対し正しい知識を供与し、 あるいはこれらの者の誤解を解き、 更には、必要に応じ手続等の是正、改善措置を講ずることによって、 適正かつ円滑な税関行政の推進を図ろうとするものであります。

「9301 税関相談官制度について」から引用

という人らしい。 故障したハードディスクを交換するために海外のメーカに送ったら、 戻ってきたときに税関で消費税を取られた旨を説明すると、 いきなり「輸出時に 11条の申請を行ないましたか？」と聞かれた。 申請もなにも、そもそも11条って何やねんと言いたくなるのを抑えて、 その申請を行なっておかないとダメなのですか？と聞くと、 「そうなんですよ～」という勝ち誇った声が返ってきた。

法律の素人 (= 私) に対していきなり「11条」などと専門用語を振り回したり、 「輸出時に申請しなかったオマエが悪いんだから税金払うのはアタリマエ」 的な言い様は、 「相談等の依頼者に対し正しい知識を供与」すべき使命を負う小役人として、 どうよと思ったが、 ここでゴネたりしていては電話代だけで 500円を突破しかねない。 そこで「11条」という手がかりを与えてくれたことに感謝の意を表して、 早々に電話を切った。 ちなみに「関税・消費税特別手数料」についても質問したら、 それはフェデックスさんが請求している手数料だろう、とのこと。

税関に関係する法令の 11条を探すなんて google さまなら朝飯前である。
すぐ該当する条文を見つけた:

（加工又は修繕のため輸出された貨物の減税）
第十一条 　加工又は修繕のため本邦から輸出され、 その輸出の許可の日から一年 （...括弧内省略...） 以内に輸入される貨物 （...括弧内省略...） については、 政令で定めるところにより、 当該輸入貨物の関税の額に、 当該貨物が輸出の許可の際の性質及び形状により輸入されるもの とした場合の課税価格の 当該輸入貨物の課税価格に対する割合を乗じて算出した額の範囲内において、 その関税を軽減することができる。

関税定率法 から引用

要約すれば、 逝って来いで輸出したときと輸入したときの性質・形状が同じならば、 関税はかからないよ、ということになる。 これは関税に関する法律であるが、 消費税に関しても同様の法律があるはずと探してみると、 ほどなく見つかった:

（加工又は修繕のため輸出された課税物品に係る消費税の軽減）
第十五条の二 　加工又は修繕のため本邦から輸出され、 その輸出の許可の日から一年（...括弧内省略...） 以内に輸入される課税物品（...括弧内省略...）については、 政令で定めるところにより、 当該課税物品に係る消費税の額に、 当該課税物品を関税定率法第十一条（加工又は修繕のため輸出された貨物の減税） の輸入貨物とみなして計算される同条に規定する割合 を乗じて算出した額の範囲内において、 その消費税を軽減することができる。

輸入品に対する内国消費税の徴収等に関する法律 から引用

消費税についても、関税定率法第十一条の趣旨が適用されるということのようだ。 つまり同じものを海外と往復させても消費税は課税されない。 今回の場合、 修理ではなくて交換なので断言はできないが、 修理の際に一部のパーツを交換することはよくあることだし、 ハードディスク自体が一つのパーツであるわけだから、 全交換も修理の一形態と言えなくもない。

次にどういう行動をすべきかは、 フェデラル・エクスプレスの返事を見てから考えよう、と思っていたら その日のうちに返事がメールで届いた。 この手の問合わせって 3営業日とか 5営業日かかるものだと思っていたので、 恐ろしく素早い対応である。 RMA といい問合わせに対する対応といい、 この迅速さがサービスの世界標準なのか。

From: "フェデックス請求管理部" <seikyukanri@npac.fedex.com>
To: Hiroaki Sengoku <sengoku@gcd.org>
Subject: Re: 消費税立替金に関して
Date: Thu, 10 Jul 2008 17:41:59 +0900

仙石 浩様
　
　ご利用有難うございました。

　経緯の内容から今回は代替品ですので荷送人が本来負担しなければならないと　
　思います。つきましては請求金額を取り消しさせて頂きますのでよろしく
　お願い致します。
　お手数おかけいたしました。

　ご利用ありがとうございます。
よろしくお願いいたします。

フェデックス 
カスタマーサービス 
請求担当　○○
電話　0120－732－327 

荷送人というと Flextronics Manufacturing (つまりハードディスクのメーカ) なのであるが、 メーカが代替品の消費税を負担しなければならない、というのは初耳である。 有償修理ならば、その修理代金に消費税がかかるのは当然だと思うが、 無償交換でも消費税がかかるのだろうか？ まあ「請求金額を取り消しさせて頂きます」と言ってくれているので、 このまま放置しても構わないだろう。

あとは HDD が送られてくるのを のんびり待つだけと思っていたら、 わずか一日後 6/26 18:44 に Western Digital からメールが来た。 しかし文字化けがひどくて読めない。 最初は何語で書いてあるかすら判然としなかったのだが、 どうやら Shift JIS で書かれた文面を quoted-printable エンコードする際に なにか問題があったようだ。 例えば 0x82 が「,」に、0x95 が「.」に置き換わってしまっている。 置換が規則的でないので、 暗号解読よろしく一文字一文字置き換え規則を推測していくしかない。

故障した HDD WD10EACS を RMA 手続きで交換してみた から引用

文面を再現するのに時間がかかりそうだなぁ～と思っている間に、 交換品の HDD が届いてしまったので、 「暗号」解読するモチベーションを失ってしまっていたのだが、

Posted by 通りすがり 2008年07月02日 00:36
結局、メールにはなんて書いてあったのでしょうか？

同ページ コメント欄 から引用

というコメントを頂いてしまったので、 暗号解読してみることにした。

以下、Western Digital からの文字化けメールを全文引用 (一部伏字) する:

From: "Western Digital RMA" <noreply@wdc.com>
To: <sengoku@gcd.org>
Date: Thu, 26 Jun 2008 02:44:25 -0700
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft CDO for Windows 2000
Content-Class: urn:content-classes:message
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1896
X-OriginalArrivalTime: 26 Jun 2008 09:44:25.0728 (UTC) FILETIME=[3861F800:01C8D771]

HIROAKI SENGOKU -l,=D6=81A

^=C8?=BA,=C9.\Z=A6,=B3,=EA,=BD RMA =
,=CCfXfe=81[f^fX,=F0Sm"F,=B5,=C4,=AD,=BE,=B3,=A2=81B  RMA
,=C9S=D6,=B7,=E9,=A8-=E2,=A2=8D?,=ED,=B9,=CD,=B1,=CCf=81=81[f<,=C9.=D4=90=
M,=B5,=C4,=AD,=BE,=B3,=A2=81B
=8F=EE.=F1,=AA=90=B3,=B5,=A2=8F=EA=8D?=81A,=B1,=CC"dZqf=81=81[f<,=C9,=CD.=
=D4=90M,=B5,=C8,=A2,=C5,=AD,=BE,=B3,=A2=81B


RMA "=D4=8D?=81F 8083XXXX

--------------------------------------------------------------

O=F0S=B7fhf?fCfu,=F0 5=81`7 ?c<=C6"=FA'?,=C9"=AD'-,=B5,=DC,=B7=81B

^=C8?=BA,=CCfhf?fCfu,=F0 Western Digital =
,=CDZ=F3-=CC,=B5,=DC,=B5,=BD=81F

     fVfSfAf<"=D4=8D?     =90=BB.i"=D4=8D?             =
Z=F3-=CC"=FA=81iGMT=81j
     ------------     ---------------      -------------
     WCASJxxxxxxx     WD10EACS-00ZJB0      6/25/2008

--------------------------------------------------------------

^=C8?=BA,=C9.\Z=A6,=B3,=EA,=BD RMA =
"=AD'-=8F=F3<=B5,=F0Sm"F,=B5,=C4,=AD,=BE,=B3,=A2=81B

-A'-<=C6Z=D2,=CCfVfXfef?,=CC=8DX=90V,=C91?c<=C6"=FA,=AA,=A9,=A9,=E8=81A,=BB=
,=CCO=E3"=AD'-'=C7=90=D5"=D4=8D?,=AA-LO=F8,=C9,=C8,=E8,=DC,=B7,=CC,=C5=81=
A,=B2-=B9=8F=B3,=AD,=BE,=B3,=A2=81B

O=F0S=B7fhf?fCfu,=CC'-.t=90=E6=81F

     HIROAKI SENGOKU
     XXXXXXXXXXXXXXXXXXXXXXXXX TAKATSU
     KAWASAKI, Japan 213-XXXX
     JAPAN

"z'-<=C6Z=D2=81F     Fedex
"z'-'=C7=90=D5"=D4=8D?=81F XXXXXXXXXXXX

     fVfSfAf<"=D4=8D?     =90=BB.i"=D4=8D?             =
"=AD'-"=FA=81iGMT=81j
     ------------     ---------------      -------------
     WCASJXXXXXXX     WD10EACS-32ZJB0      6/26/2008

--------------------------------------------------------------

S=D6~AfSf"fN=81F
RMAZ=E8=8F?ZwZ=A6=8F=EE.=F1,=CC?{--/^=F3=8D=FC
  - =

http://websupport.wdc.com/rd.asp?t=3D102&l=3Djp&p=3Dm&r=3D8083XXXX&f=3De

"=AD'-,=C6=8D=AB.=EF,=CC=8F=EE.=F1
  - http://websupport.wdc.com/rd.asp?t=3D103&l=3Djp&p=3Drp

RMAfXfe=81[f^fX,=CC?{--
  - =

http://websupport.wdc.com/rd.asp?t=3D104&l=3Djp&p=3Dv&r=3D8083XXXX&z=3D21=

3-XXXX

Western Digital fTf|=81[fgfz=81[f?fy=81[fW
  - http://websupport.wdc.com/rd.asp?t=3D105&l=3Djp&p=3Dh

^=C8=8F=E3=81A
WD RMA f`=81[f?

http://websupport.wdc.com/rd.asp?t=3D105&l=3Djp&p=3Dh

ヘッダに「quoted-printable」と書いてあるとおり、 quoted-printable エンコーディングを行なったのだろうが、 のっけから「^=C8?=BA,=C9.\Z=A6,=B3,=EA,=BD」となっていて、 一体何語なんだ？と思わせる始まり方である。

ちなみに quoted-printable というのは 8bit データを、 「印字可能 (printable)」つまり 7bit の英数字・記号だけで表現するための方法 (エンコーディング) で、 印字可能でない 8bit データは 16進数で表わして前に「=」をつける (「=」自身は「=3D」で表現する)。 例えば「^=C8?=BA,=C9.\Z=A6,=B3,=EA,=BD」は、 16進数で書くと 「5E C8 3F BA 2C C9 2E 5C 5A A6 2C B3 2C EA 2C BD」 という 8bit データ列を意味する。

腕に覚えのあるかたは、解答を見ずに解読を試みてはいかがだろうか？

結論から言うと元のテキストは Shift JIS で書かれた日本語である。 海外からのメールなので、日本語以外の可能性を考えてしまったのが敗因だった。 最初から日本語であると決めつけていれば、 もうちょっと早く解読できていたかもしれない。

Shift JIS の場合 1byte 目は 0x80 (16進数で 80) 以上であるはずなのだが、 なぜ冒頭が「5E C8 3F BA ...」になってしまっているかというと、 元テキストにおいて 0x80 ～ 0x98 のデータが、 メール中で以下のように化けてしまっているため。

表中、「元データ」の欄に、Windows の欧文文字コード CP1252 の字形を入れてみた。 それぞれの元データがメール中でどのように化けるかを見ていると、 quoted-printable エンコーディングにおいて、 CP1252 の字形を印字可能文字 (7bit の英字・記号) で無理矢理表現しようとした結果、 このような「文字化け」変換が行なわれてしまったように思えてくる。

注目すべきはこの変換が多対一対応である点、 すなわち異なるデータがメール中で同じ文字に変換されてしまっている点だろう。 例えば、 0x80, 0x86, 0x87, 0x89 のいずれのデータも、 メール中では「?」という文字に置き換えられてしまっているし、 0x93 も 0x94 も区別無く「"」という文字に置き換えられてしまっている。 すなわちメール中に「"」が現れても、それが 0x93 なのか 0x94 なのか、 はたまた「"」自身なのか、区別がつかない、ということである。

元のテキストでは、 冒頭は『以下に表示された』という文字列だったと推測される。 『以下に表示された』という文字列を quoted-printable エンコーディングで変換すると、 「=88=C8=89=BA=82=C9=95\=8E=A6=82=B3=82=EA=82=BD」になるが、 0x88 は上表にあるように「^」に化けてしまう。 同様に、0x80～0x98 の各データについて上表の「文字化け」変換を行なうと、 「^=C8?=BA,=C9.\Z=A6,=B3,=EA,=BD」となって、 前掲したメールの冒頭に一致する。

このように元のテキストから「文字化け」したメールを生成するのは、 上表を用いれば簡単に行なえるが、 その逆変換 (つまり文字化けの修復) は複数の可能性 (例えば「^」は 0x88 と「^」自身の二通りの可能性がある) の中から最も日本語として自然なものを選ばなければならない。

というわけで、 化けている文字それぞれについて、 一番自然に見えるものを選ぶ、 という操作を繰り返すことによって「暗号解読」すると、 元のテキストと思しき次の文面が得られる:

HIROAKI SENGOKU 様へ、

以下に表示された RMA のステータスを確認してください。  RMA
に関するお問い合わせはこのメールに返信してください。
情報が正しい場合、この電子メールには返信しないでください。


RMA 番号： 8083XXXX

--------------------------------------------------------------

交換ドライブを 5～7 営業日中に発送します。

以下のドライブを Western Digital は受領しました：

     シリアル番号     製品番号             受領日（GMT）
     ------------     ---------------      -------------
     WCASJxxxxxxx     WD10EACS-00ZJB0      6/25/2008

--------------------------------------------------------------

以下に表示された RMA 発送状況を確認してください。

輸送業者のシステムの更新に1営業日がかかり、その後発送追跡番号が有効になりますので、ご了承ください。

交換ドライブの送付先：

     HIROAKI SENGOKU
     XXXXXXXXXXXXXXXXXXXXXXXXX TAKATSU
     KAWASAKI, Japan 213-XXXX
     JAPAN

配送業者：     Fedex
配送追跡番号： XXXXXXXXXXXX

     シリアル番号     製品番号             発送日（GMT）
     ------------     ---------------      -------------
     WCASJXXXXXXX     WD10EACS-32ZJB0      6/26/2008

--------------------------------------------------------------

関連リンク：
RMA手順指示情報の閲覧/印刷
  - http://websupport.wdc.com/rd.asp?t=102&l=jp&p=m&r=8083XXXX&f=e

発送と梱包の情報
  - http://websupport.wdc.com/rd.asp?t=103&l=jp&p=rp

RMAステータスの閲覧
  - http://websupport.wdc.com/rd.asp?t=104&l=jp&p=v&r=8083XXXX&z=213-XXXX

Western Digital サポートホームページ
  - http://websupport.wdc.com/rd.asp?t=105&l=jp&p=h

以上、
WD RMA チーム

http://websupport.wdc.com/rd.asp?t=105&l=jp&p=h

「交換ドライブを 5～7 営業日中に発送します」と書いてあるが、 実際にはこのメールが送信された時 (日本時間で 6/26 18:44) には既に発送が完了 (18:02) していて輸送中である。 このメールを 6/27 の時点で解読できていれば、 HDD が届く前に FedEx の追跡ページ で HDD が今どこを輸送中であるか調べることができたはずであるが、 あいにく 6/27 は一日中外出していたので、 解読を始めたのは 6/28 土曜日のお昼過ぎになってからである。 ちょうど解読の糸口がつかめたあたり (元テキストが Shift JIS であることが判明した時分) で HDD が届いてしまった (6/28 15:34)。

参考までに、復号するための perl スクリプトを以下に添付する。 解読はこのような復号スクリプトを徐々に形作りつつ、 前述した表を推測していく形で行なった。

#!/usr/bin/perl
use strict;
use warnings;
while (<>) {
    while (/=\n/) {
	$_ = $` . <>;
    }

    s/\"=D4=8D\?/*94*D4*8D*86/g;	# 番号
    s/=(8[DF])\?/*$1*87/g;	# 合
    s/\?\{\-\-/*89*7B*97*97/g;	# 閲覧
    s/fVfXfef\?/*83V*83X*83e*83*80/g;	# システム
    s/fTf\|=81\[fgfz=81\[f\?fy=81\[fW/*83T*83|=81[*83g*83z=81[*83*80*83y=81[*83W/g;	# サポートホームページ
    s/f\`=81\[f\?/*83`*81[*83*80/g;	# チーム
    s/f\?/*83*89/g;	# ラ
    s/fS/*83*8A/g;	# リ
    s/f\</*83*8B/g;	# ル
    s/f\"/*83*93/g;	# ン
    s/\'-/*91*97/g;	# 送
    s/\'\?/*92*86/g;	# 中

    s/\,(=[0-9A-F][0-9A-F])/*82$1/g;
    s/f(=[89A-F][0-9A-F]|[\^\|ACNSTVXehu])/*83$1/g;
    s/\^(=[0-9A-F][0-9A-F])/*88$1/g;
    s/\?(=[0-9A-F][0-9A-F]|c)/*89$1/g;
    s/S(=[0-9A-F][0-9A-F]|[cm])/*8A$1/g;
    s/\<(=[0-9A-F][0-9A-F])/*8B$1/g;
    s/O(=[0-9A-F][0-9A-F])/*8C$1/g;
    s/Z(=[0-9A-F][0-9A-F]|[qw])/*8E$1/g;
    s/\'(=[0-9A-F][0-9A-F])/*92$1/g;
    s/\"(=FA|d)/*93$1/g;
    s/\"(=[0-9A-F][0-9A-F]|[Fz])/*94$1/g;
    s/\.(=[0-9A-F][0-9A-F]|[it\\])/*95$1/g;
    s/\-(=E2)/*96$1/g;
    s/\-(=[0-9A-F][0-9A-F]|[ALl])/*97$1/g;
    s/\~(=[0-9A-F][0-9A-F]|[ALl])/*98$1/g;

    s/[=\*]([0-9A-F][0-9A-F])/pack("H*", "$1")/eg;
    print;
}

IntelliPower - きめ細かく調整された　ディスク回転速度　転送速度　及びキャッシュサイズの調和により飛躍的な省電力と確実なパフォーマンスを提供します
IntelliPark - 風損を減らす為のアイドル時の自動ヘッド退避によりドライブは消費電力を低減する
IntelliSeek - 電力消費量、ノイズおよび振動を低減させるために、最適なシーク速度を計算します。

GreenPower ハードドライブ から引用

のうち、特に「アイドル時の自動ヘッド退避」というのがいただけない。 ヘッドを退避すれば空気抵抗が減ってモーターの負荷が減るから 低消費電力が実現できる (実際、アイドル時の消費電力は際立って低い)、 ということなのだろうが、 常時使用する PC (特にサーバ) だと「自動ヘッド退避」の回数が とんでもないことになる。 SMART 情報を見ると:

# smartctl -a /dev/sdb
smartctl version 5.37 [i686-pc-linux-gnu] Copyright (C) 2002-6 Bruce Allen
Home page is http://smartmontools.sourceforge.net/

=== START OF INFORMATION SECTION ===
Device Model:     WDC WD10EACS-00ZJB0
Serial Number:    WD-WCASJxxxxxxx
Firmware Version: 01.01B01
User Capacity:    1,000,204,886,016 bytes
	...
Vendor Specific SMART Attributes with Thresholds:
ID# ATTRIBUTE_NAME          FLAG     VALUE WORST THRESH TYPE      UPDATED  RAW_VALUE
	...
  9 Power_On_Hours          0x0032   095   095   000    Old_age   Always   3826
 12 Power_Cycle_Count       0x0032   100   100   000    Old_age   Always   24
192 Power-Off_Retract_Count 0x0032   200   200   000    Old_age   Always   19
193 Load_Cycle_Count        0x0032   197   197   000    Old_age   Always   11327
	...

わずか 3826 時間 (159日、約5ヶ月) で、 実に 11327回もの自動ヘッド退避が行なわれている。

この異常な回数の自動ヘッド退避が原因かどうかは分からないが、 この 1TB HDD は 2007年11月30日に 28140円で購入してから わずか 5ヶ月余りの 2008年5月2日に故障した。 こんなに早く故障するとは思ってもいなかったので、 T-Zone の延長保証 (200円の追加で通常3ヶ月保証を最長6ヵ月保証) を掛けていなかった。 6ヶ月ではどーせ故障しないから保証を掛けるだけ無駄と判断したのだった (ついでに言うと、6ヶ月では故障しないだろうと高を括っていて、 まだ一部バックアップしていないデータがあったので、 復旧にえらく手間取った。1TB もあると復旧も一筋縄にはいかない)。

運が悪かったとあきらめるしかない (二度とグリーン・パワー・ハードディスクは買わないぞっ！) と思っていたら、 RMA (Return Merchandise Authorization, 返却承認) という メーカによる保証があるということを同僚から教えてもらった (社内IRC で HDD の故障を嘆いていたら、哀れに思って教えてくれたらしい ^^;)。 RMA番号を取得した上で故障品をメーカへ送ると、 代替品を送り返してくれる、という保証。

ステップ3
製品が故障していて交換が必要と判断された場合、 RMA タイプを下から選択して RMA（返却承認）手続きを開始してください。

Standard Replacement
お客様から故障製品を受け取ったあとに代替製品を送付します。 RMA が作成されてから30日以内に故障製品を返送してください。

エンドユーザー向け製品交換 から引用

Western Digital の エンドユーザー向け保証確認ページで、 故障した HDD のシリアル番号を入力してみると、

おお、「限定保証期間内」と表示された。 有効期間は再来年の 12月まで、三年間もあるらしい。 もしかしたら交換してもらえるかも？と期待が膨らむ。 といっても RMA なんて今まであることすら知らなかったわけで、 どうやって故障品を送ったらいいのか見当もつかない。

まず EMS(国際スピード郵便) のページを見てみると、 EMS ラベル印字ネット受付サービス なるものがあるらしい。 単に、「ご依頼主」「お届け先」の住所を印字した EMSラベルを 届けてくれるだけのサービスであるが、 郵便局に行かなくても EMSラベルを入手できるのは有難い。 「お届け先」は、 この時点ではまだ分からなかったので空欄にして、 「ご依頼主」は、自宅住所を記入して申し込んでみる。 一週間ほどで EMS ラベルが 5枚 (一度の申込みで最大5枚まで) 届いた。

宛先住所 (RMA を作成すると表示される。 RMA 返送先住所の一覧ページ で調べることもできる) を、 手書きで記入するとこんな感じ:

次に問題となるのが HDD の梱包である。 そもそも HDD なんて発送したことがないから、 梱包に適した箱なんて持っていない (買うときはいつもバルク品を買ってるので、箱なんかには入っていない)。 どうしたものかと思っていたら、 4月29日に買った安物ギガビット・スイッチング・ハブ (5ポート 2802円) の箱が目に留まった。 HDD を入れるのに丁度よさげな大きさである。 これを裏返しにする:

バルク品を購入すると、 ときどきリテール品の箱を裏返しにした箱に入っていることがある。 裏返すと無地 (というかダンボール地) になる箱が多いので、 箱を流用したいとき裏返すのは便利なテクニックだと思う。

故障した HDD (故障しているので思うように読み書きできないのだが、 無理矢理動かしてランダムデータを全周に何度も書込んだ) を、 静電防止袋 (購入時に入っていた袋) に入れて、

次にエアークッション (いわゆる「プチプチ」、使用済シートを大量に確保してある) でグルグル巻きにして、 前述の裏返しした箱に入れる。 885g だった。 900g まで 1660円で、1g でも超えると 1800円なので、 丁度良い按排だった (ちなみに 800g までなら 1520円)。

以上で、発送の準備が整った。 そこで、前述したエンドユーザー向け保証確認ページで (故障した HDD のシリアル番号を入力した上で) 「RMA作成」ボタンを押す。 すると RMA 番号と送付先住所が書かれた 「Western Digital RMA（返却承認）送り状/明細書」が表示される (6/23 16:47)。 前述した EMS ラベルに、この送付先住所を記入。 表示されたページには、

海外のお客様： お客様の便宜を考慮し、 提供される送り状/明細書（Proforma invoice/packing list）を 税関向けの送り状として使用しても構いません。 フォームに署名と日付を記入の上（適用される場合）、同梱してください。

とも書いてあったので、このページを印刷、署名して郵便局に持参する。 郵便局で、インボイス (INVOICE) を書くように言われるので、 この送り状を見せると、 インボイスを手書きせずに済む (宛先住所が結構長いので、その場で記入するのはちょっと手間)。

また、このページから RMA ラベルを印刷することができる。 つまり RMA 番号のバーコードだが、このラベルが箱に貼ってあると、 交換が迅速に行なわれるらしい。 たくさん印刷して箱の全ての面に貼り、 さらに RMA 番号をマジックで手書きした (上面は EMSラベルを貼るために空けてある)。

EMS は配達状況を Web 上で確認できる。 13桁のお問い合わせ番号を入力して配達状況を表示させてみると、 シンガポールのフレクストロニクス (世界第二位の製造代行企業) まで一日強で届いていることが分かる (日本国内の地方の工場へ送るよりも早いような...?)。

あとは HDD が送られてくるのを のんびり待つだけと思っていたら、 わずか一日後 6/26 18:44 に Western Digital からメールが来た。 しかし文字化けがひどくて読めない。 最初は何語で書いてあるかすら判然としなかったのだが、 どうやら Shift JIS で書かれた文面を quoted-printable エンコードする際に なにか問題があったようだ。 例えば 0x82 が「,」に、0x95 が「.」に置き換わってしまっている。 置換が規則的でないので、 暗号解読よろしく一文字一文字置き換え規則を推測していくしかない (7/3追記: 文字化けメールを解読してみた)。

これは文面を再現するのに時間がかかりそうだなぁ～と思っていたら、 6/28 15:34 日通航空(ペリカン便)で自宅に HDD が届いた。 あまりの早さに、 もしかして交換されずにそのまま送り返されたのかと思ったほどである。 FedExの貨物追跡ページ で調べてみると、

シンガポールからフィリピン、成田を経由して川崎まで丸二日で届くのか...

というわけで、6/24 10:59 に故障した HDD を発送して、 わずか 4日後の 6/28 15:34 に交換品の HDD が届いた。 しかも復路の送料はメーカが負担してくれる。 代理店/販売店保証による修理/交換に比べて、 圧倒的に早く、手軽で、費用もかからず、しかも保証期間が長い。 HDD の購入は RMA 保証があるものを選びたい。

HP ML115 には IPMI (Intelligent Platform Management Interface) という 便利なインターフェイスが内蔵されています。 ... (中略) ... IPMI 機能の一つ、watchdog timer 機能を利用してみようと思います。
... (中略) ...
watchdog timer の動作に関しては、 こちらの方が 詳しいので興味ある方はご確認ください。 さて、どうやって watchdog を起こすかというと、 先ほどインストールしたドライバと ipmitool を利用します。

Watchdog Timer / IPMItool (Jun 1,2008) から引用

うっ、ML115 の IPMI には、 ウォッチドッグ・タイマーの機能もあったのか (何たる不覚 orz)。 今まで ML115 では、 ソフトウェア版ウォッチドッグ (softdog.ko モジュール) を 使っていたので、 速攻で IPMI のハードウェア・ウォッチドッグ・タイマーに乗り換えてみた。

Linux カーネル・ソースの Documentation/IPMI.txt を見ると、

A watchdog timer is provided that implements the Linux-standard
watchdog timer interface.  It has three module parameters that can be
used to control it:

  modprobe ipmi_watchdog timeout=<t> pretimeout=<t> action=<action type>
      preaction=<preaction type> preop=<preop type> start_now=x
      nowayout=x ifnum_to_use=n

ブート時に「modprobe ipmi_watchdog」を実行するだけで使えそうである。 タイムアウトを「timeout=<t>」で指定できるが、 私のマシンでは「蹴り代行」デーモンを走らせている (「ハードウェア・ウォッチドッグ・タイマー iTCO_wdt のススメ」参照) ので、 デフォルトのタイムアウトである 10 秒のままでも問題無い。

「action=<action type>」には、タイムアウト時の挙動を指定する。 「reset」(ハードウェア・リセット)、 「power_cycle」(電源OFF してから電源ON)、 「power_off」(電源OFF) を指定できるが、 デフォルトは「reset」なので、これも指定しなくて構わない。

「nowayout=0」を指定すると、 /dev/watchdog をクローズ時にウォッチドッグ・タイマーが止まる。 ウォッチドッグ・タイマーは、 いったん動き出したら何が起ろうと止めるべきではないと思うし、 デフォルトは「nowayout=1」(つまりクローズしても止まらない) なので、 これも指定する必要はない。

というわけで、ipmi_watchdog を使ってみる:

# modprobe ipmi_watchdog
# echo @ > /dev/watchdog

/dev/watchdog が存在しない場合は、「mknod /dev/watchdog c 10 130」を実行して、 /dev/watchdog を作成しておく。

10秒後、勝手にリセットがかかった (めでたしめでたし)。 リセットを防ぐには 10秒以内に /dev/watchdog へ書込み続けなければならない。 例えば、

#!/bin/sh
while true; do
    echo @ > /dev/watchdog
    sleep 5
done

といったスクリプトを走らせ続ける。 このスクリプトだとシンプルすぎて、 システムに異常が起きたときも動き続けてしまう (だからタイムアウトが発生しない) 恐れがあるので、 while ループの中にシステム異常を検知する (異常が起きたときは 10秒以上時間がかかる) ようなコマンドを入れておくとよい。

何かの都合でタイマーを止めたい (止めるべきではないが) ときは、 「V」を /dev/watchdog に書込む。

32bit プログラムからの呼び出しに対応するといっても、 基本的には引数の型を変換するだけである。 x86_64 の整数データモデルは LP64、 つまり long int 型とポインタ型が 64bit で (引数の型として多用される) int型は 32bit のままなので、 変換が不要なケースも多い。

例えば ioctl システムコールはファイル・ディスクリプタ (file descriptor, 以下 fd と略記) ごとに カーネルが実行すべき機能は変わってくるわけで、 その実装は各デバイス・ドライバに委ねられることが多い。 したがって 32bit プログラムからの ioctl 呼び出しに応えられるか否かは、 各ドライバが 32bit 対応しているか否かに依存する。 不幸にしてドライバが対応していない場合は、

ioctl32(tv:11028): Unknown cmd fd(5) cmd(40045613){t:'V';sz:4} arg(081ec8b4) on /dev/video0

などといったカーネル・メッセージ (dmesg) が出力される。 このメッセージは、 カーネル・ソース中 fs/compat_ioctl.c の compat_ioctl_error が出力している:

static void compat_ioctl_error(struct file *filp, unsigned int fd,
    unsigned int cmd, unsigned long arg)
{
    ...
    compat_printk("ioctl32(%s:%d): Unknown cmd fd(%d) "
            "cmd(%08x){t:%s;sz:%u} arg(%08x) on %s\n",
            current->comm, current->pid,
            (int)fd, (unsigned int)cmd, buf,
            (cmd >> _IOC_SIZESHIFT) & _IOC_SIZEMASK,
            (unsigned int)arg, fn);
    ...
}

fs/compat_ioctl.c は 32bit 版 ioctl システムコールを実装していて、 32bit プログラムが ioctl システムコールを呼び出すと、 この中の compat_sys_ioctl ルーチンが呼ばれる:

asmlinkage long compat_sys_ioctl(unsigned int fd, unsigned int cmd,
                unsigned long arg)
{
    ...
        if (filp->f_op && filp->f_op->compat_ioctl) {
            error = filp->f_op->compat_ioctl(filp, cmd, arg);
            if (error != -ENOIOCTLCMD)
                goto out_fput;
        }
    ...
            compat_ioctl_error(filp, fd, cmd, arg);
    ...
 out_fput:
    fput_light(filp, fput_needed);
 out:
    return error;
}

つまりドライバ側で file 構造体の compat_ioctl 関数ポインタ (filp->f_op->compat_ioctl) が定義されていればそれが呼ばれ、 未定義ならば上記のような「Unknown cmd」エラーが出力される。

ちなみにこのエラーメッセージの「tv:11028」は、 ioctl を呼び出した 32bit プロセスの名前 (コマンド名) とプロセスID であり、 fd(5), cmd(40045613), arg(081ec8b4) は、 それぞれ ioctl システムコールの第一 (つまり fd 番号)、 第二 (ioctl リクエスト番号)、第三引数 (ioctl リクエストの引数) であり、 最後の on /dev/video0 は (第一引数の) fd 番号に対応するファイルのパス名である。

そして、この tv コマンドは 「ビデオキャプチャ・カード GV-MVP/RX2W を使って Linux 2.6.24.4 でテレビ録画」で紹介した perl スクリプト であり、 その名称から推測できるとおりテレビ録画を行なうためのスクリプトである。

このスクリプトでは Video::ivtv モジュールを利用していて、 このモジュールが /dev/video0 つまり TV キャプチャ・デバイスに対して、 ioctl システムコールを呼び出している。 上記エラーはスクリプト中 $IvTV->stopEncoding($TunerFD); を実行したときに発生した。

その名称から推測できる通り、 stopEncoding メソッドはキャプチャ・デバイスに対して エンコーディングの停止を指示するためのもので、 内部で ioctl(fd, VIDIOC_STREAMOFF) などと ioctl 呼び出しを行なっている。 VIDIOC_STREAMOFF は videodev2.h にて、

#define VIDIOC_STREAMOFF    _IOW  ('V', 19, int)

と定義されていて、このマクロを展開すると 40045613 (16進) となり、 上記カーネル・メッセージ「cmd(40045613)」と一致する。

というわけで、(少なくとも Linux 2.6.24.7 に含まれる) ivtv ドライバは、 残念ながら 32bit 対応していないことが分かった。 もちろん x86_64 なカーネルではなく、 i386 カーネルを使えば 32bit プログラムから ivtv ドライバを使うことができるが、 x86_64 なカーネルでは、32bit プログラムからの ioctl システムコールを 64bit カーネルが受付けられる形に変換できないということだ。

とはいうものの、 32bit だろうが 64bit だろうが ioctl のインタフェースに大した変わりはないはずだ。 どうして ivtv ドライバは 32bit 呼び出しをサポートしていないのだろう？ と 思いながらドライバのソースを眺めていると... drivers/media/video/compat_ioctl32.c を見つけた。 名前からしていかにも 32bit 版 ioctl のように見える。

compat_ioctl32.c の中の v4l_compat_ioctl32 ルーチンは、 32bit な ioctl 呼び出しを受付けて 引数を 64bit へ変換し (といっても int 型はどちらも 32bit だが)、 本来の (64bit な) ioctl を呼び出し直す仕組みになっている。 なぜ ivtv ドライバは、このルーチンを利用していないのだろうか。

static int do_video_ioctl(struct file *file, unsigned int cmd, unsigned long arg)
{
    ...
    /* First, convert the command. */
    switch(cmd) {
        ...
    case VIDIOC_STREAMOFF32: realcmd = cmd = VIDIOC_STREAMOFF; break;
    };

    switch(cmd) {
        ...
    case VIDIOC_STREAMOFF:
        err = get_user(karg.vx, (u32 __user *)up);
        compatible_arg = 1;
        break;
        ...
    };
    if(err)
        goto out;

    if(compatible_arg)
        err = native_ioctl(file, realcmd, (unsigned long)up);
    else {
        mm_segment_t old_fs = get_fs();

        set_fs(KERNEL_DS);
        err = native_ioctl(file, realcmd, (unsigned long) &karg);
        set_fs(old_fs);
    }
    ...
    return err;
}

long v4l_compat_ioctl32(struct file *file, unsigned int cmd, unsigned long arg)
{
    ...
        ret = do_video_ioctl(file, cmd, arg);
        break;
    ...
    return ret;
}

ざっと見た感じ、 ivtv ドライバからこの v4l_compat_ioctl32 ルーチンを呼んでも 特に問題は無いように思われる。

そこで、ivtv ドライバの file 構造体 (の中の file_operations 構造体) の compat_ioctl 関数ポインタに、 v4l_compat_ioctl32 を設定してみた。

--- linux-2.6.24.5.org/drivers/media/video/ivtv/ivtv-streams.c	2008-01-25 07:58:37.000000000 +0900
+++ linux-2.6.24.5/drivers/media/video/ivtv/ivtv-streams.c	2008-05-04 09:10:07.581416212 +0900
@@ -49,6 +49,7 @@
       .write = ivtv_v4l2_write,
       .open = ivtv_v4l2_open,
       .ioctl = ivtv_v4l2_ioctl,
+      .compat_ioctl = v4l_compat_ioctl32,
       .release = ivtv_v4l2_close,
       .poll = ivtv_v4l2_enc_poll,
 };
@@ -59,6 +60,7 @@
       .write = ivtv_v4l2_write,
       .open = ivtv_v4l2_open,
       .ioctl = ivtv_v4l2_ioctl,
+      .compat_ioctl = v4l_compat_ioctl32,
       .release = ivtv_v4l2_close,
       .poll = ivtv_v4l2_dec_poll,
 };

このパッチをあてることにより、 x86_64 なカーネル上で i386 な Video::ivtv モジュールを使って、 ビデオキャプチャ・カード GV-MVP/RX2W を コントロールすることができるようになった。 一週間ほど使ってみた (多数の TV 番組を予約録画した) が、 今のところ問題は起きていない。

この TVキャプチャボードのおかげで、 私はリアルタイムでテレビを視聴する習慣を無くすことができた。 録画したものを見れば「飛ばし読み」や「斜め読み」が可能だし、 1TB のディスクに録りだめしておいて優先順位をつけて見ることもできる。 ニュースやスポーツ以外であれば放送日に見る必要はそもそもないし、 下らないと判明した時点で視聴を打ち切って 別の録画した番組を見るようにすれば、 駄作をだらだらと見続けて時間を無駄にすることもない。

この手のハードウェアは、 Linux などのオープンソースな OS で動いてこそ真価を発揮するのだと思う。 視聴方法は人によって様々であるから、 全てのユーザニーズを満たすような万能なソフトウェアを、 ハードウェアメーカが製品出荷時に開発することなど、 そもそも無理な話ではないのか？

ハードウェアメーカはドライバ (あるいはハードウェア仕様) の公開だけにとどめ、 ソフトウェアの開発は他者に任せてはどうか。 餅は餅屋というではないか。 一つの万能ソフトウェアより、 ニーズに応じて単機能なソフトウェアを使い分ける方が合理的だし、 さらに言えばどんな OS 上でそのソフトウェアが動いて欲しいかは、 ユーザによって異なるだろう。

例えば私の場合、 24時間365日、安定して録画し続けることが最優先であるし、 「使い易い」グラフィカルなユーザインタフェースよりは、 perl スクリプトから 自由にコントロールできることのほうが重要である。 私もノートPC では Windows VISTA を使用しているが、 録画サーバの OS に Windows を使う気にはなれない。

GV-MVP/RX2W は生産終了になって久しく、 後継の GV-MVP/RX3 や GV-MVP/GX2W はまだ Linux では使えないらしい (はたして地上アナログ停波までに使えるようになるだろうか?)。 I/Oデータの製品は Linux で使えないことが多いので注意が必要だろう。 Windows のみ対応しているハードウェア製品だと、 サポートが打ち切られて Windows の新 OS に対応しなくなった段階で、 使うことができなくなってしまう (サポート終了を理由に VISTA 対応版を出していないハードウェア製品は多い)。 もっとも、メーカ側からすると早く使えなくして、 新製品に買い換えてもらいたいのだろうが。

なお冒頭で「パッチを当て直す必要はない」と書いたが、 GV-MVP/RX2W には DeEmphasis (DEM) モードを設定すると常にモノラル音声になるという問題がある。 標準カーネルでは DEM ON がデフォルトになっているので、 Linux 2.6.24.4 に以下のパッチをあてて、 DEM OFF をデフォルトにしてみた。 このパッチをあてることにより、 デフォルトで二か国語/ステレオ放送の録画ができるようになる。

--- linux-2.6.24.4.org/drivers/media/video/tda9887.c	2008-01-25 07:58:37.000000000 +0900
+++ linux-2.6.24.4/drivers/media/video/tda9887.c	2008-04-13 11:41:30.232518786 +0900
@@ -227,8 +227,7 @@
 		.name  = "NTSC-M-JP",
 		.b     = ( cNegativeFmTV  |
 			   cQSS           ),
-		.c     = ( cDeemphasisON  |
-			   cDeemphasis50  |
+		.c     = ( cDeemphasisOFF |
 			   cTopDefault),
 		.e     = ( cGating_36     |
 			   cAudioIF_4_5   |

PowerEdge というと (ラック・マウント型の) 爆音サーバのイメージが強かったので、 自宅で 24時間通電は難しいのではないかと思っていたのだが、 普通のデスクトップPC 並に静かで驚いた。 ProLiant のほうは、爆音というほどではないがそれなりにファンの音がする。

ProLiant ML115 は、 ビデオ・メモリが 2MB しかなくて画面の解像度の限界が 1024x768 16bit だったり、 光学ドライブが DVD でなかったり、 PCI が 3.3V 専用だったりと、 デスクトップPC として使うには少々難がある (もちろんサーバとして使う場合は問題無い)。

それに比べると PowerEdge SC440 は、 デスクトップPC としても使える。 手持ちのサウンド・カード Vortex2 SQ2500 (5V PCI なので ProLiant ML115 では使用不可) を差して Ubuntu をインストールしてみた。 ただし、DRI (Direct Rendering Infrastructure) は使えないので、 ビデオ再生などには向かない。

また、PowerEdge SC440 は ECC 付メモリしか使えないので、 安価なメモリを使いたい場合は不便。 一方 ProLiant ML115 はECC 無しメモリも利用できるので、 私は ProLiant ML115 の 512MB ECC 付 DDR2/667 メモリを PowerEdge SC440 へ移し、 ProLiant ML115 には、 4800円で購入した KINGBOX 1GB ECC 無し DDR2/800 2枚組を差して使っている。

レッツノート (1/21):

本BIOSの導入によって現象を回避することが可能ですが、 詳細が判明次第、弊社Webサイトにてご報告いたしますので、 引き続き弊社Webサイトからお知らせを覧いただきますようお願いします。
ただし、本現象がすでに発生している場合は、 対策のBIOSアップデートプログラムを導入できません。
大変お手数ですが、下記の修理相談窓口に修理のご相談をお願いします。

CF-R6M/CF-R6Aシリーズご使用のお客様へのご案内 から引用

Lenovo ThinkPad (1/15):

注意：Windows Vistaを使用しているシステムで、 電源投入時に"2100: Initialization error on HDD0 (Main hard disk drive)"と 表示され、 HDDから起動できなくなることがある問題を修正しました。

ファームウェア・アップデート・ユーティリティ 2.5インチ SATA ハード・ディスク・ドライブ用 から引用

レッツノートの BIOS アップデートは Windows 上から実行する必要があるので、 「本現象がすでに発生している場合は」、 まず「Windows VISTA 用の更新プログラム KB943899 が原因で突然死したハードディスクを復旧させる方法」などを用いてハードディスクをスピン・アップさせ、 Windows を正常起動させておく必要がある。 「修理相談窓口に修理のご相談を」するのは「大変お手数」なので、 ハードディスク以外の方法 (USB メモリからの起動など) で 起動する手段を提供すべきだと思うのだが...

さっそくレッツノートで BIOS アップデートを行なってみた。

試しに、 ハードディスクを故意に Power-Up In Standby 状態にしてみる。 すなわち、 「Windows VISTA 用の更新プログラム KB943899 が原因で突然死したハードディスクを復旧させる方法」 の 「お手軽パック」などを使って Linux を起動し、 hdparm コマンドを使って Power-Up In Standby 状態にしてみる:

# mount -t vfat /dev/sdb1 /mnt
# /mnt/hdparm -s1 /dev/sda

/dev/sda:
Use of -s1 is VERY DANGEROUS.
This requires BIOS and kernel support to recognize/boot the drive.
Please supply the --yes-i-know-what-i-am-doing flag if you really want this
Program aborted
# 

おお、fool proof 機能付とは、なかなか親切なコマンドだ。 とても危険なので、 「何をしようとしているか分かっている」場合のみ、 「--yes-i-know-what-i-am-doing」オプションを付けて再実行する:

# /mnt/hdparm -s1 --yes-i-know-what-i-am-doing /dev/sda

/dev/sda:
 setting power-up in standby to 1 (on)
# /mnt/hdparm -I /dev/sda | grep Power-Up
           *    Power-Up In Standby feature set
# 

これで、ハードディスクが Power-Up In Standby 状態になった。 つまり電源投入時にスタンバイ・モードに入り、 明示的に spin up 命令を送らない限りは回転を始めない。 だから、 レッツノートの以前の BIOS ではハードディスクを認識できず起動に失敗していた。

Ctrl-Alt-Del を押して再起動すると、 ハードディスクから正常にブートした。 再び「お手軽パック」を使って Linux を起動し、 ハードディスクの状態を確認してみる:

# /mnt/hdparm -I /dev/sda | grep Power-Up
                Power-Up In Standby feature set
# 

Power-Up In Standby 機能が無効になっていた。 新しい BIOS は、 ハードディスクに spin up 命令を送るだけでなく、 Power-Up In Standby 機能を無効にする命令も送っているようだ。

というわけで、 突然死したハードディスクを復旧させる「お手軽パック」を作ってみた。 もちろん無保証である。 いかなる損害が発生しても私は何の責任も負えない、 ということに同意して頂けるかたのみに対して使用を許諾する。

まず、この zip アーカイブ をダウンロードして、 USB メモリへ展開する。 以下の例では USB メモリが「ドライブ D」になっているが、 実際の USB メモリのドライブ名で読み替えて欲しい。

D:\>dir
 ドライブ D のボリューム ラベルがありません。
 ボリューム シリアル番号は 0000-0000 です

 D:\ のディレクトリ

2007/07/16  08:49            23,040 syslinux.exe
2008/01/18  07:33           537,844 hdparm
2007/12/25  08:07         2,411,333 initz
2007/12/24  09:50         1,423,768 linuz
2008/01/18  08:18                58 syslinux.cfg
               5 個のファイル           4,396,043 バイト
               0 個のディレクトリ     510,672,896 バイトの空き領域

D:\>

Windows のコマンド プロンプト にて、 D:\syslinux.exe を以下のように実行する。 もちろん、引数の「D:」は USB メモリのドライブ名で読み替える。

D:\>syslinux.exe -ma D:

D:\>

これで Linux 2.6.23.12 がブート可能な USB メモリができた。 このメモリをレッツノートに差して起動する。 BIOS 設定で USB から起動可能にしておくのを忘れずに。

ハードディスクが回転しないのであるから、 以下のメッセージが表示されて止まってしまうが、

Phoenix TrustedCore(tm) NB
Copyright 1985-2004 Phoenix Technologies Ltd.
All Rights Reserved

Copyright (C) Matsushita Electric Industrial Co.,Ltd. 2007
BIOS Version 1.00-L13

CPU = 1 Processors Detected, Cores per Processor = 2
Intel(R) Core(TM) Duo CPU      U2400  @ 1.06GHz
2048MシステムRAMテスト完了。
システムBIOSがシャドウされました。
ビデオBIOSがシャドウされました。
ハードディスク0:
マウスが初期化されました。
エラー
0200: ハードディスクエラーです。 0

<F2>キーを押すとセットアップを起動します。

ここで構わず <F1>キーを押すと、 USB メモリからの起動が始まる。

linux が起動すると /bin/sh が実行されてプロンプト「#」が表示されるが、 その後 USB メモリが認識されてカーネル・ログが出力される。

	...
PWD='/'
ROOTPARM=' -o ro'
TERM='linux'
initrd='initz'
/bin/sh: can't access tty; job control turned off
# [   31.556958] scsi 6:0:0:0: Direct-Access     Multi    Flash Reader     1.00 PQ: 0 ANSI: 0
[   32.077952] sd 6:0:0:0: [sdb] 1006592 512-byte hardware sectors (515 MB)
[   32.079952] sd 6:0:0:0: [sdb] Write Protect is off
[   32.080089] sd 6:0:0:0: [sdb] Mode Sense: 03 00 00 00
[   32.080094] sd 6:0:0:0: [sdb] Assuming drive cache: write through
[   32.085449] sd 6:0:0:0: [sdb] 1006592 512-byte hardware sectors (515 MB)
[   32.087574] sd 6:0:0:0: [sdb] Write Protect is off
[   32.087699] sd 6:0:0:0: [sdb] Mode Sense: 03 00 00 00
[   32.087704] sd 6:0:0:0: [sdb] Assuming drive cache: write through
[   32.087830]  sdb: sdb1
[   32.090803] sd 6:0:0:0: [sdb] Attached SCSI removable disk
[   32.091527] usb-storage: device scan complete

プロンプトの後にカーネル・ログが出力されてしまっているため紛らわしいが、 Enter キーを押せばプロンプトが表示される。

このカーネル・ログでは [sdb] と表示されているが、 レッツノートに接続した USB デバイスが他にもあれば、 sdc や sdd になっているかもしれない。 その場合は、以下の sdb を sdc なり sdd なりで読み替えて欲しい。

以下のように mount コマンドを実行して、 USB メモリを /mnt へマウントする。 そして USB メモリ上の hdparm コマンドを実行してみる:

# mount -t vfat /dev/sdb1 /mnt
# /mnt/hdparm -i /dev/sda

/dev/sda:

 Model=Hitachi HTS541612J9SA00                 , FwRev=SBDOC70P, SerialNo=      SBXXXXXXXXXXXX
 Config={ HardSect NotMFM HdSw>15uSec Fixed DTR>10Mbs }
 RawCHS=16383/16/63, TrkSize=0, SectSize=0, ECCbytes=4
 BuffType=DualPortCache, BuffSize=7516kB, MaxMultSect=16, MultSect=?16?
 CurCHS=16383/16/63, CurSects=16514064, LBA=yes, LBAsects=234441648
 IORDY=on/off, tPIO={min:120,w/IORDY:120}, tDMA={min:120,rec:120}
 PIO modes:  pio0 pio1 pio2 pio3 pio4 
 DMA modes:  mdma0 mdma1 mdma2 
 UDMA modes: udma0 udma1 udma2 udma3 udma4 *udma5 
 AdvancedPM=yes: mode=0x80 (128) WriteCache=enabled
 Drive conforms to: ATA/ATAPI-7 T13 1532D revision 1:  ATA/ATAPI-2,3,4,5,6,7

 * signifies the current active mode

# 

以上のように、 レッツノートのハードディスク (/dev/sda) の諸元が表示されれば成功である。 以下のように hdparm を実行して「Power-Up In Standby feature」を無効にすれば、 ハードディスクの復旧が完了する。

# /mnt/hdparm -s0 /dev/sda

/dev/sda:
 spin-up: setting power-up in standby to 0 (off)
# 

後は、Ctrl-Alt-Del を押すなどして再起動すれば、 ハードディスクから正常にブートする。 USB メモリを抜くのを忘れずに。

Phoenix TrustedCore(tm) NB
Copyright 1985-2004 Phoenix Technologies Ltd.
All Rights Reserved

Copyright (C) Matsushita Electric Industrial Co.,Ltd. 2007
BIOS Version 1.00-L13

CPU = 1 Processors Detected, Cores per Processor = 2
Intel(R) Core(TM) Duo CPU      U2400  @ 1.06GHz
2048MシステムRAMテスト完了。
システムBIOSがシャドウされました。
ビデオBIOSがシャドウされました。
ハードディスク0:
マウスが初期化されました。
エラー
0200: ハードディスクエラーです。 0

<F2>キーを押すとセットアップを起動します。

というメッセージをビープ音とともに出力して止まってしまう。 HDD が壊れたのかと思い、 BIOS で HDD を起動ドライブから外して USB メモリからブートを試みたが、 起動ドライブから外しても内蔵 HDD に問題があると先に進めないようだ。

HDD を完全に取り除いてしまえば USB メモリからブートするらしいが、 このような中途半端な死にかただとスピン・アップ待ちになってしまって、 そこから先に進めなくなる (後で知ったのだが、 実は上記画面で止まっているとき <F1> を押すと、 ブートを継続できて USB メモリ等からブートできる)。

昔、HDD のスピンドル (spindle) が固着して、 スピン・アップ (spin up) しなくなる症状に見舞われたことがあったが、 今回はつい数分前まで全く正常に動いていた HDD が、 突然スピン・アップしなくなったのであって、 あからさまに症状が異なるように思われた。 しかもごく短い距離を移動するためにレッツ・ノートを閉じただけなので、 途中衝撃なども一切与えていない。 機械的な障害ではないように思われた。

とはいえ、 いちおー無駄な抵抗は試みた (^^;)。 すなわち、 HDD が回転しなくなったときに、 HDD を振り回すことによってトルクを与える手法や、 あるいは結露等で回路に異常がおきたときに、 結露を霧散させる手法 (平たく言うとしばらく放置しただけ ;) を試したのだが、 HDD が回転音を発することは無かった。 出張初日で、 代替マシンの調達もままならず、 Advanced/W-ZERO3[es] に USB キーボードをつないで急場をしのいだものの、 えらく難儀した。

結論から言うと、 想像通りハードウェア的にはなんら故障していなかった。 単に HDD が 「電源投入時にスタンバイ・モードに入る (power-on in standby)」 状態になっていただけだった。

1/9 に行なわれた Windows Update KB943899 が原因らしいです。 おそらくこの Update のバグで、 HDD に power-on in standby を有効にする命令が 送られてしまうことがあるのでしょう。 私の CF-R6 は 1/10 に発症しましたが、 他にも同様の発症例が多数あるとか。

例えば、 Linux の hdparm コマンドのマニュアルには、 次のような記述がある。

NAME
    hdparm - get/set hard disk parameters

SYNOPSIS
    hdparm [ flags ] [device] ..

OPTIONS

    -s   Enable/disable  the power-on in standby feature, if supported by
         the drive.  VERY DANGEROUS.  Do not use  unless  you  are  abso-
         lutely  certain  that both the system BIOS (or firmware) and the
         operating system kernel (Linux >= 2.6.22)  support  probing  for
         drives  that  use this feature.  When enabled, the drive is pow-
         ered-up in the standby mode to allow the controller to  sequence
         the  spin-up of devices, reducing the instantaneous current draw
         burden when many drives share a power supply.

「VERY DANGEROUS」と書いてある通り、 HDD がひとたびこの「power-on in standby」モードになってしまうと、 電源を投入してもスピン・アップしなくなる (スタンバイ状態になる)。 HDD が沢山あるサーバなどで、 全ディスクが一斉に回転を始めると、 突入電流が電源の許容範囲を超えてしまったりするわけで、 それを回避するためのモードらしい。 つまり、 電源を投入したあと、 おもむろに HDD を一台づつスピン・アップしていくことにより、 回転開始にともなう突入電流を分散させることができるというわけ。

実験してみる (非常に危険なので何をやっているか完全に理解するまでは 真似しないでください):

# hdparm -s1 /dev/sda

/dev/sda:
 setting power-up in standby to 1 (on)
# hdparm -I /dev/sda

/dev/sda:

ATA device, with non-removable media
	Model Number:       Hitachi HTS541612J9SA00                 
	Serial Number:      SBXXXXXXXXXXXX
	Firmware Revision:  SBDOC70P
Standards:
	Used: ATA/ATAPI-7 T13 1532D revision 1 
	Supported: 7 6 5 4 
Configuration:
	Logical		max	current
	cylinders	16383	16383
	heads		16	16
	sectors/track	63	63
	--
	CHS current addressable sectors:   16514064
	LBA    user addressable sectors:  234441648
	LBA48  user addressable sectors:  234441648
	device size with M = 1024*1024:      114473 MBytes
	device size with M = 1000*1000:      120034 MBytes (120 GB)
Capabilities:
	LBA, IORDY(can be disabled)
	Queue depth: 32
	Standby timer values: spec'd by Vendor, no device specific minimum
	R/W multiple sector transfer: Max = 16	Current = 16
	Advanced power management level: 128 (0x80)
	Recommended acoustic management value: 128, current value: 254
	DMA: mdma0 mdma1 mdma2 udma0 udma1 udma2 udma3 udma4 *udma5 
	     Cycle time: min=120ns recommended=120ns
	PIO: pio0 pio1 pio2 pio3 pio4 
	     Cycle time: no flow control=120ns  IORDY flow control=120ns
Commands/features:
	Enabled	Supported:
	   *	SMART feature set
	   *	Security Mode feature set
	   *	Power Management feature set
	   *	Write cache
	   *	Look-ahead
	   *	Host Protected Area feature set
	   *	WRITE_BUFFER command
	   *	READ_BUFFER command
	   *	NOP cmd
	   *	DOWNLOAD_MICROCODE
	   *	Advanced Power Management feature set
	   *	Power-Up In Standby feature set
	   *	SET_FEATURES required to spinup after power up
	    	SET_MAX security extension
	    	Automatic Acoustic Management feature set
	   *	48-bit Address feature set
	   *	Device Configuration Overlay feature set
	   *	Mandatory FLUSH_CACHE
	   *	FLUSH_CACHE_EXT
	   *	SMART error logging
	   *	SMART self-test
	   *	General Purpose Logging feature set
	   *	WRITE_{DMA|MULTIPLE}_FUA_EXT
	   *	64-bit World wide name
	   *	IDLE_IMMEDIATE with UNLOAD
	   *	SATA-I signaling speed (1.5Gb/s)
	   *	Native Command Queueing (NCQ)
	   *	Host-initiated interface power management
	   *	Phy event counters
	    	Non-Zero buffer offsets in DMA Setup FIS
	    	DMA Setup Auto-Activate optimization
	    	Device-initiated interface power management
	    	In-order data delivery
	   *	Software settings preservation
Security: 
	Master password revision code = 2007
		supported
		enabled
	not	locked
		frozen
	not	expired: security count
	not	supported: enhanced erase
	Security level maximum
	72min for SECURITY ERASE UNIT. 
Checksum: correct
# 

「Power-Up In Standby feature set」が有効になっていることが分かる。 この状態で再起動する (HDD の電源をいったん切る) と、 冒頭に引用した「0200: ハードディスクエラーです。 0」を表示して止まってしまう。 <F1> を押して HDD 以外から起動させると、

[    0.000000] Linux version 2.6.23.12 (sengoku@senri.gcd.org) (gcc version 4.1.2) #1 SMP Mon Dec 24 09:50:41 JST 2007
	...
[   72.479025] ata3.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
[   72.479031] ata3.00: irq_stat 0x40000001
[   72.479044] ata3.00: cmd c8/00:08:00:00:00/00:00:00:00:00/e0 tag 0 cdb 0x0 data 4096 in
[   72.479047]          res 51/04:08:00:00:00/00:00:00:00:00/e0 Emask 0x1 (device error)
[   72.481033] ata3.00: configured for UDMA/33
[   72.481043] sd 2:0:0:0: [sda] Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE,SUGGEST_OK
[   72.481051] sd 2:0:0:0: [sda] Sense Key : Aborted Command [current] [descriptor]
[   72.481060] Descriptor sense data with sense descriptors (in hex):
[   72.481066]         72 0b 00 00 00 00 00 0c 00 0a 80 00 00 00 00 00 
[   72.481082]         00 00 00 00 
[   72.481089] sd 2:0:0:0: [sda] Add. Sense: No additional sense information
[   72.481099] end_request: I/O error, dev sda, sector 0
[   72.481114] ata3: EH complete
[   72.481738] sd 2:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
[   72.481794] sd 2:0:0:0: [sda] 234441648 512-byte hardware sectors (120034 MB)
[   72.481818] sd 2:0:0:0: [sda] Write Protect is off
[   72.481824] sd 2:0:0:0: [sda] Mode Sense: 00 3a 00 00
[   72.481861] sd 2:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA

何度も HDD へリクエストを再送した末、「I/O error」になる。 Linux 2.6.22 以降の場合、 I/O error にはなるものの HDD デバイス自体は認識しているので、 hdparm コマンドからコントロールすることができる。

逆に言うと、古いカーネルだとデバイス認識も行なわれないので、 hdparm コマンドすら使えなくなってしまい 以下の方法では復旧できない。 現時点では Knoppix などの LiveCD の多くは、 2.6.21 以前のカーネルのまま (例えば Knoppix v5.1.1 は 2.6.19) なので注意。

hdparm を使って「Power-Up In Standby feature」を無効にする:

# hdparm -I /dev/sda | grep Power-Up
	   *	Power-Up In Standby feature set
# hdparm -s0 /dev/sda

/dev/sda:
 setting power-up in standby to 0 (off)
# hdparm -I /dev/sda | grep Power-Up
	    	Power-Up In Standby feature set
# 

これで、電源投入時に HDD は自動的に回転を始めるようになる。
再起動すれば HDD から正常にブートする。