PT2 サーバのハードディスクの冷却ファン取り付け

屋外の最高気温が30度を超えるようになってきました。もちろん室内も屋外ほどでないにしろ、結構気温が上昇しています。暑くなってくると気になるのが、ハードディスクの温度です。FreeBSD で稼働している自宅サーバ（FMV ESPRIMO D5220）には、すでに CD ドライブベイの部分へ冷却ファンを取り付けてハードディスクの温度上昇を抑制していました。今回は、自宅サーバの隣に設置してある PT2 サーバ（FMV ESPRIMO D5210）にも冷却ファンを取り付けて、ハードディスクの温度上昇を抑制するようにしました。

ハードディスク用の冷却ファンを取り付けた FMV ESPRIMO D5210 です。

冷却ファンの取り付け

昨年の夏は、PT2 サーバにも小さな冷却ファンを取り付けていましたが、秋ごろには騒音が激しくなったことから取り外してしまいました。そこで今回も以前と同じように CD ドライブベイの部分へ冷却ファンをネジで固定しました。ハードディスクとの間には穴が無数に開いた状態となっており、この穴から風を送り込んでハードディスクの表面温度を下げるようにします。またこの穴を使って冷却ファンを固定しました。

CDドライブベイへ取り付けた冷却ファンです。

ハードディスクと冷却ファンの位置関係がよく解るように撮影したものです。
冷却ファンの風はハードディスクへ吹き付けるように設置しました。

冷却ファン用電源ケーブル

冷却ファンの電源ケーブルの先端は 3 ピンコネクタとなっています。一般的なパソコン用電源から分岐させるケーブルなどがありますが、このケーブルでは 12 ボルトが供給されるようになっており、冷却ファンがかなりの高速回転をしてしまいます。そこで 5 ボルト電源を供給するケーブルを自作して、回転数を下げる工夫をしました。

作業は簡単で、4 ピンの電源コネクタと 3 ピンのピンヘッダの間をケーブルで接続するだけの簡単なものです。

ピンヘッダは、小さな蛇の目基盤へ一旦ハンダ付けしたあとにケーブルをハンダ付けしました。

冷却ファンへ 5 ボルト電源を供給するケーブルを作ったところです。

端子の部分が剥き出しになっているため、テープで簡単に絶縁処理を施しておきました。

冷却ファンへ 5 ボルト電源を供給するケーブルを接続したところです。
パソコン用電源のケーブルのうち 5 ボルトは赤色のケーブルで、
黄色のケーブルは 12 ボルトになっています。

これで回転数が抑えられた状態で冷却ファンが回転するようになりました。冷却ファンの騒音も気になりません。これで今年の夏を乗り切りたいと思っています。

ファイルサーバのハードディスクのエラーの原因は

先日ハードディスク（WD20EARX）の不調のため交換を行ったファイルサーバですが、再び調子が悪くなってしまいました。原因を調べてみると SATA ケーブルに問題がありました。

ファイルサーバ用ハードディスクの複写
http://near-unix.blogspot.jp/2016/05/blog-post.html

症状

交換したばかりの 2TB のハードディスク（WD20EZRZ）から DMA エラーが発生しているログが次々とコンソール上に表示されていました（涙）。

マザーボードが 1.5Gbps までの速度しか対応していないため、もしかして上手く動作切替ができていないのかしれないと考えて、ハードディスクの側面にあるショートジャンパの 「1.5Gbps 制限動作」の設定を行ってみました。しかし症状は変わりませんでした。

1.5Gbps に制限した WD20EZRZ です。
この写真では SATA ケーブルは交換済みです。

原因は SATA ケーブル

原因を探ると SATA のケーブル（写真の青いケーブル）に問題があったようで、このケーブルで接続するハードディスクのデータ転送が不調となってしまうことが判明しました。

問題があった SATA ケーブル

不調だと思って交換した古い 2TB のハードディスク（WD20EARX）は、すでにデータ複写用のマシン上で検査を行って異常がないことを確認していました。そのため、今回のせっかくハードディスクを交換したのですが、不調の原因は SATA ケーブルに問題があったようです（苦笑）。

新しい SATA ケーブルへ交換したところ、 DMA エラーなどは発生せず、順調に動作しました。これからは、ケーブルにも注意を払いたいと思いました。

自宅サーバのハードディスク交換作業

FreeBSD で稼働している自宅サーバ（FMV ESPRIMO D5220）のハードディスクを交換しました。

左側のマシンが自宅サーバの FMV-ESPRIMO D5220です。
右側のマシンは、データ複写用マシンです。

経緯

自宅サーバの前回のハードディスク交換は、2014 年 7 月でした。それからおよそ2年が経過していました。我が家のメールや電話など多くの機能がこの自宅サーバに詰まっているため、故障する前に交換することとしました。

自宅サーバのハードディスク交換の予行演習
http://near-unix.blogspot.jp/2014/06/blog-post.html

自宅 FreeBSD サーバの HDD 交換
http://near-unix.blogspot.jp/2014/07/freebsd-hdd.html

準備

昨日までに交換する新しいハードディスクの検査などを終えて、準備を整えていました。なおヘッドの自動待避機能は、WDIDLE3 によって 8 秒から 300 秒へ変更しておきました。

自宅サーバ用ハードディスク（2TB）の交換の準備
http://near-unix.blogspot.jp/2016/05/blog-post_21.html

データ複写

FreeBSD による UFS フォーマットを行った現状の（古い）ハードディスク（WD20EZRX）から新しいハードディスク（WD20EZRZ）へ移行させました。この二つのハードディスクは、型番は異なりますが、基本的な仕様は同一のものです。

前回のハードディスクの交換の再、 4KB/セクタのハードディスクへ対応するために、アライメント（Alignment） 調整を済ませていました。そのため、今回のデータ複写は、単純なイメージコピーで行いました。（訂正2016-05-23： GPT への対応の部分を削除しました）

二年ほど前に設置した WD20EZRX です。

データ複写用に用意したデスクトップ・パソコンへ、新旧のハードディスクを設置した後、GParted Live CD を使って立ち上げました。自動的に起動する GParted を使って、新旧のハードディスクのデバイス名（/dev/sda、/dev/sdb）を確認しました。一旦、GParted を終了させた後、端末ソフトウェアから ddrescue コマンドによってデータの複写を行いました。

GParted -- Live CD/USB/PXE/HD
http://gparted.org/livecd.php

GParted Live CD 上では ddrescue コマンドを実行させるには sudo コマンドも必要でした。実際に指定した ddrescue  コマンドのオプションは次のとおりです。リトライ回数は 3 回に設定しています。

sudo ddrescue  -d  -f  -r 3  -b 4096  /dev/sda  /dev/sdb

古いハードディスク　（WD20EZRX）：/dev/sda
新しいハードディスク（WD20EZRZ）：/dev/sdb

なお実際の作業は、上記の ddrescue のコマンドを実行した後、すぐに Ctrl + C によって複写を停止させた後、GParted を再度立ち上げて、新品の /dev/sdb のハードディスクのヘッダ情報（パーティション情報）が書き換わっていることを確認しました。これは間違って逆方向にデータを複写していないことを確認するためでした。そして、GParted  を再度終了させた後、端末ソフトウェアから ddrescue コマンドで複写をハードディスクの先頭部分から最後まで行いました。

データ複写作業中の様子です。

GParted Live CD 上で ddrescue コマンドで複写を行いました。

複写終了

深夜から開始して、早朝明るくなるまでの約 6 時間ほどで、複写は終了しました。もともと正常に動作していたハードディスクですので、複写作業中に問題は発生しませんでした。そしてすぐに自宅サーバのマシンへ装着して動作確認を行いました。正常に起動を開始して、自宅サーバは再び息吹を吹き返しました。

データ複写中は冷却ファンでハードディスクを冷やしていました。

自宅サーバ用ハードディスク（2TB）の交換の準備

昨日、ファイルサーバのハードディスクの複写を行い、無事交換を行うことができました。そして本日は、自宅サーバのハードディスクの交換の準備を行いました。

ファイルサーバ用ハードディスクの複写
http://near-unix.blogspot.jp/2016/05/blog-post.html

準備作業

準備の内容としては、新品のハードディスク（WD20EZRZ）の検査を行っただけでした（笑）。ウェスタンデジタル製の検査ソフトウェア（Data Lifeguard Diagnostics）で５時間ほど時間を掛けて、しっかりと検査を行いました。

ハードディスクの試験を行っているところです。

Data Lifeguard Diagnostics で検査が終了したところです。

そして WDIDLE3 により、ヘッドの自動待避機能の待避開始時間を８秒から３００秒（５分）へ変更しました。

WDIDLE3 を使ってヘッドの待避時間を調整しました。

交換の予定

メールなどのやり取りがほとんどない深夜からハードディスクの交換作業（複写）を行いたいと思っています。

自宅サーバには、システムに FreeBSD がインストールされており、ファイルシステムに UFS を使用しています。以前のようにダンプ＆リストア方式で複写を行わず、ddrescue によってハードディスクのイメージ・コピーによって複写を行う予定です。既に前回の複写のとき 4K セクタのハードディスク用にアライメント（Alignment）調整を行っていますので、ddrescue によるイメージ・コピーで問題なく動作すると思っています。この ddrescue によるイメージ・コピーによりファイルサーバと同じく６時間〜７時間の作業で終了すると見込んでいます。なお前回のダンプ＆リストア方式の場合は、１６時間ほどでした。

自宅サーバのハードディスク交換の予行演習
http://near-unix.blogspot.jp/2014/06/blog-post.html

自宅 FreeBSD サーバの HDD 交換
http://near-unix.blogspot.jp/2014/07/freebsd-hdd.html

ファイルサーバ用ハードディスクの複写

2011 年 8 月よりファイルサーバ用に使用していたハードディスク（2TB, WD20EARX）に不調が発見されたことから、新しく購入したハードディスク（2TB, WD20EZRZ）へデータ複写をしました。

一部にデータエラーが発見された 2TB のハードディスク（WDEARX）です。
2011-08-30 の書き込みがあることから、この日から使用を開始した模様です。

ファイルサーバとして使用していたマシンの様子です。
2TB と 3TB のハードディスクを装着しています。

複写作業

デスクトップ・パソコンへ古いハードディスク（WD20EARX）と新しいハードディスク（WD20EZRZ）を接続して、Linux 環境から ddrescue コマンドによってハードディスクの複写を行いました。

左側が古いハードディスク（WD20EARX）で
右側が新しいハードディスク（WD20EZRZ）です。

ddrescue コマンドの特徴

ddrescue コマンドでの複写は、いわゆるディスクイメージの複写となります。全域を複写した場合には、同じ内容のハードディスクがもうひとつ出来上がることとなります。

そして ddrescue コマンドは、データの読み取りができない場合には、再度指定した回数まで繰り返して読み込みを行って、できる限りデータを救出する動作をします。動作不良となったハードディスクからデータを救出する場合には、一般的な dd コマンドよりも ddrescue を使用した方がデータの救出率が高まります。昨年、テレビ録画用に使用していたハードディスクからデータを救出したときにも ddrescue コマンドを使用しました。

PT2 サーバのハードディスクの複写
http://near-unix.blogspot.jp/2015/07/pt2_22.html

PT2 サーバのハードディスクの複写終了
http://near-unix.blogspot.jp/2015/07/pt2_26.html

ddrescue で複写

複写をする場合、データの取り扱いを標準の 1 セクタあたり 512 バイトから、4096 バイトへ変更して作業を行いました。これはもちろんアドバンスド・フォーマットにより、 1 セクタあたりのバイト数がどちらでも読み書きができるのですが、4096 バイト単位であれば、より効率的に複写ができるためです。

実際に指定した ddrescue  コマンドのオプションは次のとおりです。リトライ回数は 3 回に設定しています。

ddrescue  -d  -f  -r 3  -b 4096  /dev/sda  /dev/sdb

古いハードディスク　（WD20EARX）：/dev/sda
新しいハードディスク（WD20EZRZ）：/dev/sdb

ddrescue で複写中の様子です。

作業時間

概ね６時間３０分ほどの作業時間を必要としました。この作業時間は、もう一台の新しいハードディスクの複写作業の時間の見積もりに助かります。

[追記] ハードディスクの装着

複写の終わったハードディスクをファイルサーバへ装着しました。動作確認も行いましたが、問題なく動作していました。これから数年間、ファイルサーバとして頑張ってもらいます。

下の段のハードディスクが今回交換した WD20EZRZ です。

Western Digital ハードディスク WD20EZRZ を購入

ウェスタンデジタルの 2TB ハードディスク（WD20EZRZ）を二台購入しました。

購入したハードディスクには青いラベル（Blue）が貼り付けられていましたが、従来からある同社の緑色のラベル（Green）のものと中身は同等のものだそうです。そのためヘッドの自動待避機能も８秒で動作するそうです。使用を開始する前に５分へ変更する予定です。

今回入手したウェスタンデジタルの WD20EZRZ の梱包箱です。

ウェスタンデジタルの WD20EZRZ を取り出したところです。

梱包状態

最大手の通販会社より入手しました。ちょっと心配なこととして、ユーザの評価欄に通販会社からの発送方法に問題が指摘されていました。ハードディスクのような精密機器にも係わらず、簡易包装のまま郵便ポストに投函する方法で配達されていたことを問題視していました。幸い我が家では、二台まとめて購入したこともあってか、大きなダンボール箱へ圧着フィルムで固定するという標準的な方法で送り届けられました。

簡易包装ではなく、ダンボール箱で届きました。

経緯

ハードディスクを購入した経緯は二つあります。一つは、ファイルサーバとして活躍しているマシンのハードディスク（2TB）を検査してみると問題があることが発見されたためです。もう寿命に達したようで、交換の必要がありました。

もう一つは、現在自宅サーバとして使用しているマシンのハードディスク（2TB、WD20EZRX）を前回交換してから２年が経過しようとしていることから、問題が発生する前に交換しておきたかったからです。

自宅 FreeBSD サーバの HDD 交換
http://near-unix.blogspot.jp/2014/07/freebsd-hdd.html

ハードディスクの検査

現在のところ、ハードディスクの交換に向けて、届いたハードディスクの検査（Data Lifeguard Diagnostic）を行っています。長く使用するものですので、使い始めだけはしっかりと検査をしておきました。

冷却ファンでハードディスクを冷やしながら検査を行いました。

ハードディスクのの検査の様子です。

2TB で５時間程度の掛かりました。

WDIDLE3 でヘッドの待避時間調整

DOS プログラムの WDIDLE3 を使って、ハードディスクのヘッドの待避時間を調整しました。初期値の 8 秒から 300 秒（5 分）へ変更しました。

- 300 秒へ設定 -
wdidle3 /s300

- 設定値の確認 -
wdidle3 /r

WDIDLE3 でヘッドの待避時間を調整しているところです。

今後の予定

すでに問題が表面化しているファイルサーバのハードディスクから交換をしたいと思っています。

NEC Lavie LL370/E へ Debian Jessie を再インストール

メモリカード不良が発生していた NEC LaVie LL370/E へ Debian Jessie の Xfce4 をインストールしました。

経緯

メモリ異常のためか個人ファイルだけでなく、システムファイルにも障害が発生していました。復旧を試みましたが、なかなか思うように復旧が進みませんでした。日頃使っていないパソコンということもあり、新規にインストールし直すこととしました。

Debian Jessie の再インストール

再インストールに当たって、デスクトップ環境は前回パフォーマンスの良かった Xfce4 としました。インストールそのものは順調に終了しました。

Debian Jessie の Xfce4 デスクトップをインストールした LaVie LL370/E です。

サウンド関係のトラブル

いろいろと個人的な環境を設定を終えたころ、音声（サウンド）が出力されないことに気づきました。

以前のインストール記事を参照してみると、Gnome3 の環境で Pulseaudio のコントローラで、「アナログヘッドホン（アンプなし）」で動作していました。

NEC LaVie LL370/E へ Debian Jessie をインストール
http://near-unix.blogspot.jp/2015/05/nec-lavie-ll370e-debian-jessie.html

そこで早速同じ設定をしようとしたところ、Alsamixer は存在しましたが、Pulseaudio のコントローラは見当たりませんでした。そこで Pulseaudio のコントローラである pavucontrol をインストールしました。

# aptitude update
# aptitude install pavucontrol

すると [アプリケーション]-[マルチメディア]-[PulseAudio  音量調整] としてインストールされました。

これで Gnome3 の時と同様に「アナログヘッドホン（アンプなし）」を選択してみましたが、音声は出力されませんでした。

PulseAudio のコントローラ

問題点対策

認識されている関連チップとしては SiS SI7012 (AD1981B) ということで、カーネル・モジュールは、snd_intel8x0 が使用されていました。この snd_intel8x0 カーネル・モジュールは、過去にも他機種のパソコンでスピーカとヘッドホンの入れ替えを行ったことのあるチップです。メーカの設計によって様々なバリエーションが存在しているようです。そのため多くのオプション設定ができるようになっています。このオプション設定のうち、音声アンプ回路のオン・オフする部分を負論理にする "ac97_quirk=inv_eapd" が適応しました。上記のとおり、Gnome3 の時に「アンプなし」で音声が出力されたことからも合致します。なおこの設定を行った時には「アナログヘッドホン／アンプ」を選択します。

オプションの設定は以下の通りとしました。音声アンプ回路のスイッチの設定の他、電話回線のモデムも使用しないことからモデム用のカーネル・モジュール（snd_intel8x0m）をブラックリストへ追加して読み込まないようにしました。なお今回の設定ファイルの名前は ll370e.conf としました。そして設定を反映させるためにマシンを再起動させました。

# vi /etc/modprobe.d/ll370e.conf

options snd-intel8x0 ac97_quirk=inv_eapd
blacklist snd_intel8x0m

以上により、音声（サウンド）が出力されるようになりました。

音声が出力されるようになった LaVie LL370/E です。

その他 Alsamixer の [スイッチ] の中の [Headphone Jack Sense] の項目にチェックを入れると音声が出力されなくなりました。音声が出力されないときには、この部分もチェックが必要です。

[Headphone Jack Sense] の項目にチェックを入れない

A-DATA のメモリカードの修理（失敗）

先日、動作異常で NEC LaVie LL370/E から取り外した A-DATA の DDR メモリの修理を試みてみました。

NEC LaVie LL370/E のメモリカードの異常
http://near-unix.blogspot.jp/2016/04/nec-lavie-ll370e.html

修理を試みたのは、今回取り外したメモリカードの他、一年ほど前に取り外した同じメーカのメモリカードも一緒に行いました。

今回修理を試みた A-DATA のメモリカードです。

再ハンダ付け

修理方法は EDO-RAM などで何度も行ったメモリチップのリードへの再ハンダ付けです。通常の表面実装の左右にリードが飛び出した形状のため、私も再ハンダ付けができる状況でした。再ハンダ付けと言うよりは、ハンダを盛りつけては、ハンダの吸い取り線で余分なハンダを吸い出す作業の繰り返しでした。この作業で精根尽き果てました（笑）

ルーペを使って再ハンダ付け作業です。

上段が未加工のメモリカード、
下段が再ハンダ付けを行ったものです。

動作確認

最悪でした（涙）。
メモリカードを装着したパソコンが起動不良となってしまいました。LaVie LL370/E をはじめ、ThinkPad T30、ThinkPad R40 などなど・・・。正常なメモリカードに交換して、何度か電源の入り切りを繰り返すと再び息を吹き返すという状況となってしまいました。

何度かハンダ不良と思われる箇所を修正して、ようやく ThinkPad R40 でだけ、動作確認ができる状況となりました。しかし 512MB の容量のはずなのですが、256MB しか認識してくれませんでした。またメモリカードのベンダ情報などを取得しようとしましたが、何故かできませんでした。

まだ予想の範疇ですが、メモリチップのリードのハンダ割れなどによる接触不良が発生したのではなく、メモリコントローラのチップが破損しているのではないかと思われました。二枚のメモリカードも同様の状況のため、たまたま故障したというよりか、製造上の問題で早期に寿命を迎えてしまったのではないかと想像しているところです。

もうこのメモリカードを装着するとパソコンが起動不良となってしまう状況のため、修理するのを諦めました。メモリカードの上に載っているメモリチップは再利用可能と思われますので、将来必要なときに備えて「使用不可」で保管しておきたいと思います。

NEC LaVie LL370/E のメモリカードの異常

以前入手していた NEC LaVie LL370/E のメモリカード（512MB/PC2700）に異常が発生しました。

今回故障したメモリカードです。

経緯

元々入手した当時に搭載されていた二枚のメモリのうち、一枚は異常が発生していました。そこで一度は二枚とも交換をしていたのですが、そのうち正常に動作していたメモリを元に戻して使用していました。

NEC LaVie LL370/E を入手しました。
http://near-unix.blogspot.jp/2015/05/nec-lavie-ll370e.html

しかしパソコンの電源投入時にファンだけが回転をして、起動をしない状況が発生するようになりました。しかし毎回起動不良が発生する状況ではありませんでした。

そこで memtest86+ でメモリ試験を行ったところ、メモリの異常を発見しました。メモリカードが温まると異常が発生するという典型的なパターンのようです。

memtest86+ でメモリ試験を行ったところです。

対策

不良となった A-DATA ブランドのメモリカードを取り外して、別のメモリカードへ交換しました。

再び memtest86+ で動作試験を行いました。２サイクルほど動作させましたが、問題なく動作しているようです。これでしばらく経過観察をしてみたいと思っています。

メモリカードを交換した後に行った memtest86+ の動作試験です。

ThinkPad R50e で CMOS 電池トラブル

久しぶりに ThinkPad R50e を立ち上げてみました。すると CMOS 用の電池が消耗していたようで、日付などが初期化（リセット）されていました。

CMOS 用電池のトラブルが発生した ThinkPad R50e です。

起動画面から BIOS 画面へ自動で切り替わってしまいました。
日付の項目を表示させると初期化されていました。

この ThinkPad R50e は以前に銅箔テープ法で CMOS 用電池を交換していました。消耗するには、早いようにも感じました。本体のバッテリパックが存在していないので、CMOS 回路用の電力を一手に引き受けていることもあり、消耗が早かったのかもしれません。

そこで筐体を分解して CMOS 用電池の交換をすることとしました。ThinkPad R50e の CMOS 用電池はパームレスト部分の下に隠れています。

現在我が家で標準としている銅箔テープ法です。

CMOS 用電池の絶縁をしていたテープを剥がして電圧を計測してみました。なんと 3.2 ボルトありました。どうも電池の消耗ではなく、接触不良だったようです。

そこで継続して電池の表面と銅箔が接触を継続できるようにスポンジテープを貼り付けてみました。これで筐体の蓋で常に押さえつけられている状態となり、接触不良も改善されると考えました。

スポンジテープで電池と銅箔の接触を改善してみました。

再び接触不良が発生するかどうか経過観察をしてみたいと思っています。

Logicool QuickCam Communicate Deluxe (V-UBE43) を入手

インターネット・オークションにて、ロジクールのウェブカメラ QuickCam Communicate Deluxe (V-UBE43) を入手しました。

今回入手した QuickCam Communicate Deluxe (V-UBE43) です。

どうも大型家電量販店で購入したもののようで、販売店のタグ類がそのまま残っていました。そして新品・未使用のものだったようです。とても幸運でした。

QuickCam Communicate Deluxe (V-UBE43) のパッケージです。

QuickCam Communicate Deluxe (V-UBE43) を開梱したところです。

動作確認

早速 Debian Jessie が稼働しているマシンへ装着してみたところ、Guvcview などで問題なく動作しました。

QuickCam Communicate Deluxe (V-UBE43) 本体を取り出したところです。

 側面にあるピント調節ホイールも右手で調整するため、レンズの前を遮ることなく調整できます。

QuickCam Communicate Deluxe (V-UBE43) のピント調整ホイールが側面に設けられていました。

そして画質は、レンズが良いためか良好なものとなっていました。ピントを近距離に合わせて撮影したものです。近距離でもシャープな画像が得られました。

QuickCam Communicate Deluxe (V-UBE43) で撮影したサンプル画像です。

個人的に収集を行っている古い ThinkPad と同様に外装がゴム塗装となっているため、将来的にベトベトになってしまうのではないかと少し心配しています。日頃から雑巾などで表面を水拭きしていれば、表面に染み出してくる可塑剤を減少させられるため、大抵問題ないはずだと思っています。しかし、こればかりは時間が経過してみないと結果が解らないのが辛いところです。

Logitech QuickCam for Notebooks Deluxe を入手

インターネット・オークションにて ロジテックの QuickCam for Notebooks Deluxe (V-UAV35) を入手しました。

Logitech QuickCam for Notebooks Deluxe です。

概要

ノートパソコン向けの持ち運びができる小型のウェブカメラです。持ち運び用に便利なポーチもありました。ノートパソコンへの装着は液晶モニタのベゼル部分へ本体底部にあるクリップで挟み込むようになります。ただしベゼルの厚みがあるものは挟みこむことができませんでした。そして画素数は 30 万画素です。

QuickCam for Notebooks Deluxe の背面です。

QuickCam for Notebooks Deluxe の底部クリップです。

ノートパソコンの液晶モニタのベゼルへ装着したところです。
動作中は左側にある黄色い LED ランプが点灯します。

動作確認

Debian Jessie が稼働しているマシンに装着してみると、すぐに認識しました。Guvcview などで動画を観ることができました。ドライバに gspca_zc3xx が使用されていました。

OpenWrt  でも動作確認

OpenWrt Chaos Calmer 15.05 がインストールされている FON2303D へ装着してみましたが認識しませんでした。gspca_zc3xx のカーネル・モジュールがインストールされていませんでした。そこで gspca_zc3xx のカーネル・モジュールをインストールして動作確認をしてみたところ、動作しました。

# opkg update
# opkg install kmod-video-gspca-core kmod-video-gspca-zc3xx

画像は、いわゆるウェブカメラらしいチープなものでした（涙）。