仙石浩明の日記

ハードウェアの認識と制御

2013年11月8日

Z80 コンピュータを作ってみた (27年前のお話)

往年の 8ビット・マイクロプロセッサー Z80。 最近の若い IT エンジニアだと知らない人も多い? 現在でも組み込み用途で使われているのに、 プログラマの高齢化が進んでいるらしい。 私がコンピュータを学んだ思い出深い CPU なので、 このまま忘れ去ってしまうのもモッタイナイ。 思い出せる限り記録に残しておこうと思う。 コンピュータを原理から学ぼうとする人の参考になれば幸い。

以下は、私が大学一回生のとき (1986年, 昭和61年) 独学で作った CP/M (Control Program for Microcomputer, パソコン用シングルタスク OS) マシンの記録。

私は高校生のとき (1983年)、 シャープ製パソコン MZ-80K2E改造しながら独力でデジタル回路を学んだ。 当時のコンピュータ雑誌 (工学社 「I/O」 誌) に掲載された MZ-80K の回路図が大いに参考になった。 1983年版 TTL IC 規格表を片手に MZ-80K の回路図を読み解いて、 コンピュータの仕組みを学んだ。

受験勉強そっちのけでデジタル回路の勉強にのめり込んでしまったので一浪する (1985年) はめになったが、 無事大学に合格した後はたっぷり時間があったので、 Z80 コンピュータを作ってみた。 MZ-80 に倣って当時これを HZ-80 と呼んでいたので、 以下 HZ-80 と呼ぶ。

HZ-80 の写真 ↓ (上面 / 下面)

HZ80

HZ-80 にはディスプレイもキーボードも無いので、 改造した MZ-80K2E とパラレル通信ケーブルで結び、 MZ-80K2E を端末として使用した。 写真 ↑ 中央に見える黒色の 40ピン ソケットに、 パラレル通信ケーブルをつなぐ。 MZ-80K シリーズは画面が横 40文字しか表示できないので、 (MZ 本体とは別に) 80文字表示できるビデオ信号生成回路を作り、 MZ-80K2E の CRT へ出力して、 80桁x25行キャラクタ表示端末として使っていた。

写真左手に見える 36ピン アンフェノール ソケット (セントロニクス仕様のプリンタ用と同じ形状) に、 (PC-8001/8801シリーズ用の) 5インチ フロッピー ディスク ドライブ (以下 FDD と略記) をつなぐ。

写真右手に見える赤と黒の端子に +5V のスイッチング電源をつなぐ。

もっと読む...
Filed under: ハードウェアの認識と制御 — hiroaki_sengoku @ 07:57
2009年9月29日

無線LANコントローラ VIA VT6656 を Linux 2.6.30.8 で使ってみる

VIA Technologies の無線LAN コントローラ チップ VT6656 は、 SOTEC C10x や工人舎SC/SX などのネットブック / UMPC や、 Wyse USB 802.11 b/g Wireless Network Adapter などの USB 無線LAN アダプタなどで広く使われている。 香港で買った OLEVIA X10A-1160 でも、 このチップが使われてた (SOTEC C101 と同型機だから当然)。

幸い、 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 で安定して接続できている。

Filed under: ハードウェアの認識と制御 — hiroaki_sengoku @ 19:21
2009年1月19日

SOTEC C101 (OLEVIA X10A-1160) で Linux (Ubuntu) を使う場合の注意点

香港の旺角電脳中心で買った OLEVIA X10A-1160 は、 Ubuntu 8.04 LTS がプレインストールされていた。 そのまま使うぶんには問題無いが、 Ubuntu のアップデートをインストールしてしまうと (正確に言えばカーネルを更新すると)、 OLEVIA X10A-1160 固有の設定が無効になり、 無線LAN やタッチパッドが使えなくなるなどの問題が生じる。 Ubuntu アップデートを行なった後、 あるいは新規に GNU/Linux (Ubuntu に限らず) をインストールする場合に、 OLEVIA X10A-1160 固有の設定を行なうためのメモ。

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

Filed under: ハードウェアの認識と制御 — hiroaki_sengoku @ 08:59
2008年12月29日

香港の旺角電腦中心で NetBook OLEVIA X10A-1160 を買ってみた

香港の旺角電腦中心 (Mongkok Computer Centre) の 4階 (香港の呼び方だと 3樓) 320號にあるパソコンショップ 「道亨顧問有限公司」 (Dorman Consultants Limited) で、 NetBook OLEVIA X10A-1160 を HK$2880 (約 33,000円) で売っていた。

Olevia X10A 10.1" notebook

Olevia X10A 10.1" notebook

Operation SystemLinux (Windows Compatible)
ChipsetIntel Atom N270 1.6GHz
BIOSPhoenixBIOS 1.0.00-31
Memory1GB DDR2
LCD10.1” 1024x600 SVWGA
HDD160 GB (SATA) WD1600BEVT
I/OD-sub*1 , USB 2.0*3 , Mic-in
Headphone, LAN
BatteryLithium-Ion 11.1V 2.2Ah (3 cells)
Webcam1.3M Webcam
SoundStereo speakers
Dimension26.5*18.5*2.5cm
Weight~1.3 Kg (including 3 cells battery)

物価が安い香港と言えど、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」 シールも貼ってある。

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

ところが

もっと読む...
Filed under: ハードウェアの認識と制御,香港 — hiroaki_sengoku @ 08:25
2008年8月25日

ギガビット・スイッチング・ハブ CG-SW08GTV2 が故障したと思ったら…

自宅サイト GCD の 2台のゲートウェイ (senri と asao) の NIC が同時に link down した。

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 時間を集計してみるとこんな感じ:

link downupdown秒数
8/18 10:31:3010:33:57147
8/18 10:34:1210:47:45813
8/18 10:54:3410:54:373
8/18 18:18:0718:21:50223
8/18 18:22:3718:42:511214
8/19 15:38:1315:40:35142
8/19 15:45:0515:51:06361
8/19 16:05:5416:05:573
8/19 16:07:4816:07:502
8/19 16:08:2616:10:08102
 
link downupdown秒数
8/19 16:10:1016:10:122
8/20 08:00:1208:02:59167
8/20 08:03:0408:07:47283
8/20 08:07:5708:09:57120
8/20 08:10:2908:22:47738
8/20 08:31:3308:31:363
8/20 08:32:3709:00:141657
8/20 12:56:0613:00:05239
8/20 13:00:2713:08:02455
8/20 13:32:5013:37:15265

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-SW08GTRT-Zone で 3742円だった。 8 port の gigabit が 4000円以下とは、 ずいぶん安くなったものだ (標準価格は 9975円)。

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

もっと読む...
Filed under: ハードウェアの認識と制御 — hiroaki_sengoku @ 07:52
2008年7月14日

なぜ DELL PowerEdge SC440 は ICH7R の Watchdog Timer 機能を利用できないのか?

DELL PowerEdge SC440 は、 インテル 82801GR I/O コントローラー・ハブ (ICH7R) を使っている。 ところが、ICH7 にあるはずの ウォッチドッグ・タイマ (Watchdog Timer) 機能が利用できない。 例えば Linux だとブート時に 「reboot disabled by hardware」すなわち 「ハードウェアによってリブートが禁止されている」とカーネル・ログに出力される:

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) に、

SignalUsageWhen SampledComment
SPKRNo RebootRising Edge of PWROK The signal has a weak internal pull-down. If the signal is sampled high, this indicates that the system is strapped to the "No Reboot" mode (ICH7 will disable the TCO Timer system reboot feature). The status of this strap is readable via the NO REBOOT bit (Chipset Config Registers:Offset 3410h:bit 5).

と書いてある。 つまり 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 が利用できるようになるはず。

もっと読む...
Filed under: ハードウェアの認識と制御 — hiroaki_sengoku @ 07:45
2008年7月11日

外国のメーカに修理/交換してもらうとき課税される関税・消費税を減免する方法

ハードディスクが故障したので、RMA 手続きを行なった上でメーカへ送り返したら、わずか4日で代替品が返ってきた (6月28日)。 RMA++ と思っていたら、 10日後の 7月8日にシンガポールのフェデラル・エクスプレスから 「請求書在中」と書かれた AIR MAIL な封書が送られて来た。 え~ せっかく RMA を誉め称えるブログを書いたのに、 今になって何か追加で請求されるとわ... orz と、 暗澹たる気持ちで開封してみると...

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

Other Charges  消費税/付加価値税(Consumption Tax/VAT) 500
Other Charges  関税・消費税特別手数料(D/T Advancement Fee)  500
合計(Total) 1,000

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

税科目税額合計個数
D 関税¥00
F 消費税¥4001
A 地方消費税¥1001

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

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

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

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

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

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

もっと読む...
Filed under: ハードウェアの認識と制御 — hiroaki_sengoku @ 10:25
2008年7月3日

Western Digital RMA チームから届いた文字化けメールを解読してみた

故障した HDD WD10EACS を RMA (Return Merchandise Authorization, 返却承認) 手続きで交換してみた」で書いたように、 RMA 手続きを行なった上で Western Digital へ故障したハードディスク ドライブ (以下 HDD と略記) を送ったら、 激しく文字化けしたメールが送られてきた。

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

文面を再現するのに時間がかかりそうだなぁ~と思っている間に、 交換品の 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 データ列を意味する。

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

もっと読む...
2008年6月30日

故障した HDD WD10EACS を RMA (Return Merchandise Authorization, 返却承認) 手続きで交換してみた

廉価な 1TB SATA ハードディスク ドライブ (以下 HDD と略記) として有名な、 Western Digital 製 WD Caviar GP WD10EACS は、 省電力・静音を謳っている。 環境に優しいのは結構なことだが、 その実現方法:

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

のうち、特に「アイドル時の自動ヘッド退避」というのがいただけない。 ヘッドを退避すれば空気抵抗が減ってモーターの負荷が減るから 低消費電力が実現できる (実際、アイドル時の消費電力は際立って低い)、 ということなのだろうが、 常時使用する 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 なんて今まであることすら知らなかったわけで、 どうやって故障品を送ったらいいのか見当もつかない。

もっと読む...
Filed under: ハードウェアの認識と制御 — hiroaki_sengoku @ 08:12
2008年6月13日

HP ProLiant ML115 で、IPMI ハードウェア・ウォッチドッグ・タイマー ipmi_watchdog を使ってみる

ハードウェア・ウォッチドッグ・タイマー iTCO_wdt のススメ」へのリンクを張って頂いた:

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

うっ、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 に書込む。

Filed under: ハードウェアの認識と制御 — hiroaki_sengoku @ 08:17
2008年5月12日

x86_64 な Linux カーネルで i386 プログラムを実行するときの注意点 ── ivtv ドライバの ioctl インタフェース

64bit Linux (x86_64 別名 amd64) は、 CONFIG_IA32_EMULATION を有効にしておくことにより、 32bit プログラム (i386 別名 ia32) を走らせることができる。 したがって 64bit へ移行する際は、 全プログラムを一度に 64bit 化する必要はなく、 まずカーネルだけ 64bit 化しておいて、 各プログラムは (バージョンアップの機会などに) 徐々に 64bit 化していけばよい。 ただし 32bit プログラムがカーネルの機能を呼び出す場合は、 各機能それぞれが 32bit プログラムからの呼び出しに対応していることが前提となる。

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 番組を予約録画した) が、 今のところ問題は起きていない。

2008年4月15日

ビデオキャプチャ・カード GV-MVP/RX2W を使って Linux 2.6.24.4 でテレビ録画

ついに Linux 2.6.24 で I-O DATA 製 ハードウェア MPEG-2 エンコーダ搭載TVキャプチャボード GV-MVP/RX2W (2006年7月5日生産終了) が標準カーネルのままでテレビ視聴が可能になった。 もはやカーネルのバージョンを上げるたびにパッチを当て直す必要はない。 仕様が公開されていないハードウェアを解析してドライバを開発し、 それを標準カーネルにマージすべく働き掛けた方々の努力に敬意を表したい。

この 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   |
Filed under: ハードウェアの認識と制御 — hiroaki_sengoku @ 07:57
2008年3月14日

HP ProLiant ML115 と DELL PowerEdge SC440 を買ってみた

HP と DELL がエントリ・サーバ (タワー型) のキャンペーン販売を行なっていたので、 試しに買ってみた。 どちらも 2万円以下。

HP ProLiant ML115 DELL PowerEdge SC440
価格 15,750円 (21,000円割引) 19,800円 (46,875円割引)
プロセッサ AMD Athlon 3500+ Pentium Dual-Core E2180
チップセット nVidia MCP55S Pro Intel 3000
グラフィック Matrox G200e (ServerEngines) ATI ES1000
メモリ PC2-5300 ECC Unbuffered DDR2 SDRAM 512MB
HDD 80GB SATA 7200rpm
光学ドライブ TSSTcorp CD-ROM TS-H192C TSSTcorp DVD-ROM TS-H352C

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枚組を差して使っている。

Filed under: ハードウェアの認識と制御 — hiroaki_sengoku @ 08:27
2008年1月22日

BIOS アップデートにより、ハードディスクが Power-Up In Standby 状態になっていても起動できるようになった

1/9 以降、Windows VISTA 搭載 レッツノートのハードディスクが突然死する可能性がある」問題を解決するための BIOS が公開された。

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

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

Lenovo ThinkPad (1/15):

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

レッツノートの 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 機能を無効にする命令も送っているようだ。

Filed under: ハードウェアの認識と制御 — hiroaki_sengoku @ 11:02
2008年1月18日

Windows VISTA 用の更新プログラム KB943899 が原因で突然死したハードディスクを復旧させる方法

昨日書いた 「1/9 以降、Windows VISTA 搭載 レッツノートのハードディスクが突然死する可能性がある 」を大変多くの方に読んで頂けた。 頂いたコメントで目立ったのが、 復旧方法が万人向けではない、という点。 確かに Linux 2.6.22 以上の LiveCD を自前で調達しなければならないというのは、 よほど普段から Linux を使いこなしていない限りは難しいだろう。

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

まず、この 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 メモリを抜くのを忘れずに。

Filed under: ハードウェアの認識と制御 — hiroaki_sengoku @ 09:40
Older Posts »