2014年10月31日金曜日

ThinkPad i 1620 の故障 電源入らず! 修理へ

以前入手していた ThinkPad i 1620 の電源が入らなくなってしまいました。電源ボタンを押しても反応がないのです。バッテリを装着していると充電ランプは点灯するのですが、その他は全く反応がない状態でした。

これは内部の異常だと判断しました。そこで分解して原因を突き止めることとしました。また可能であれば修理をしたいと思っていました。

分解と同時に筐体などは、すっきり水洗いをしながらの作業となりました。最近では分解して内部の掃除をするのが楽しくてたまりません(笑)。

水洗いをする ThinkPad i 1620 の筐体底部品です。

システムボードを取り出して、原因の捜索です。すぐに思いつくのはヒューズ切れです。電気テスターを使ってヒューズの導通を確認してみました。全てかどうかは判りませんが、発見したヒューズはどれも断線していませんでした。電源周りのことなので、てっきりヒューズ切れだと思い込んでいました。

システムボードの表面の様子です。
システムボードの裏面の様子です。

さらにシステムボード上をつぶさに観察してみました。するとバッテリのソケット近くにある何かの半導体?が焼失しているのを発見しました。原因を発見しましたが、名称も不明な半導体の焼失に、修理する方法がないと思われました。

消失していた正体不明の半導体です。
竹串の先にあるのがそれです。
焼失した正体不明の半導体の拡大写真です。
焼けてしまった原因は何だったのでしょうか?
再び同じ故障が発生するのか心配です。

焼失した半導体の表面には ACA と 073 の文字が刻印されているだけでした。何か電源系の半導体のようにも思われました。念の為、手持ち部品取り用システムボードを眺めてみました。すると ThinkPad 600 のシステムボード上に似た部品が載っているではないですか!そこでダメで元々ということで交換してみることとしました。

部品取り用の ThinkPad 600 のシステムボードにあった同様の半導体です。

この正体不明の半導体は、ハンダゴテで剥がしてみると、真ん中の一本だけ太い端子は部品の低部まで回り込んでいる構造となっていて、半導体で発生する熱をシステムボードへ放熱する構造になっていました。そのために、逆に交換用の部品をハンダ付けするのも、ハンダゴテの熱がシステムボードへ逃げるためか少々難しいものとなってしまいました。

ThinkPad i1620 の焼失した半導体を取り除き、ThinkPad 600 から取り出した半導体を持ってきたところです。
交換用の半導体をハンダ付けしたところです。

正体不明の半導体を交換した後、システムボードに液晶モニタとキーボードを取り付けた状態で動作試験を行なってみました。すると無事電源が入り、ロゴ画面が表示されるようになりました。どうも正体不明の半導体の交換は成功したようです。しかしどのような目的の半導体だったのでしょうか?(笑)

システムボードへ液晶モニタとキーボードだけを取り付けて動作確認をしてみました。

電源が入るようになったため、本格的にマシンを組み直しました。そして動作確認のため、インストールしてある Puppy Linux 5.7.1 JP でいろいろと操作していています。

殆ど組み上がったところで、再度電源を投入して動作することを確認しました。
最終的に全てを組み直して動作確認を行いました。

2014年10月30日木曜日

Buffalo EDO-RAM NX8-64M を二枚入手しました

インターネット・オークションで古いノートパソコン用のメモリの詰め合わせセットを落札してきました。中身は PC100 の 128MB や 256MB のメモリが中心となっていましたが、二枚の EDO-RAM が入っていました。EDO-RAM は、バッファロー社の NX8-64M です。このメモリは、以前にも入手していて、ThinkPad 535X や 380X などで使用出来ることを確認しています。今回もお買い得な落札をしたと思っていました(笑)。

早速、二枚の NX8-64M を ThinkPad 380X へ装着して、memtest86+ でメモリ検査を行おうとしました。しかし二枚のうち、一枚はメモリを認識せず、もう一枚も起動時のセルフチェックでエラーと表示されてしまいます。

手前の二枚の NX8-64M が今回入手したメモリ(故障品)です。
ソケットに装着してあるものは、以前入手した動作確認済みのメモリです。

メモリの表面や接点をアルコールで洗浄してみましたが、結果は変わりませんでした。

もしかしてメモリ検査を行おうとしていた ThinkPad 380X に異常が発生しているのかもしれないと思って、以前入手していた同型のメモリを装着してメモリ試験を行なってみるとちゃんと認識もするし、メモリ試験も通過してしまうのです。やはり今回入手した二枚のメモリに異常があるようです。

ThinkPad 380X 上で正常品のメモリ試験を行なっているところです。
ThinkPad 380X では NX8-64M を認識することができます。

最近入手した EDO-RAM は、不良品であることが多いのですが、メモリチップのリードを再ハンダ付けすることによって復活することが多くありました。そこで今週末にも時間が得られれば、メモリチップの再ハンダ付けを行なってみたいと思っています。結果は、このブログにて報告したいと思っています。

メモリ試験中の ThinkPad 380X です。

2014-11-01 追記
再ハンダ付けで、二枚の NX8-64M は復活しました。
故障していた NX8-64M EDO-RAM を修理しました
http://near-unix.blogspot.jp/2014/11/nx8-64m-edo-ram.html

FreeBSD OpenVPN のアップグレード

FreeBSD の ports へ OpenVPN のアップグレード(openvpn-2.3.4 から openvpn-2.3.5へ)が到着していました。いつものように portupgrade で更新しました。

更新後の OpenVPN の再起動は以下のコマンドです。
# /usr/local/etc/rc.d/openvpn restart

外部から接続を試みましたが、無事接続できました。

openvpn-2.3.5 のビルドオプション

富士通 ESPRIMO D3260 は自宅サーバとしても運用取りやめ

富士通 ESPRIMO D3260 を FreeBSD で稼働する自宅サーバとしても運用を中止しました。自宅サーバのハードディスクは、元の ESPRIMO D5220 へ戻しました。

私個人としては ESPRIMO D3260 に搭載されている SiS671 チップセットで FreeBSD の運用実績がなかったので、このまま運用し続ける度胸がありませんでした。

また運用開始で気になったことは SATA ハードディスクへのアクセス速度です。今までのインテルのチップセットの場合、150MB/s (UDMA5) の転送速度が dmesg 上に表示されていました。同じハードディスクを ESPRIMO D3260 の SiS671 のチップセットでは 16.7MB/s (WDMA2) の転送速度となっていました。何と! 10 分の 1 の転送速度になるそうです。どうしてこんなことになるのかは不明です。FreeBSD には SiS671 上で UDMA で動作する適切なドライバが存在しないのでしょうか? SiS671 チップセットは、何も良い所が無いように感じられました。

2014年10月29日水曜日

富士通 ESPRIMO D5320 はデスクトップ・パソコンとして復活

富士通 ESPRIMO D3260 と入れ替えとなった 富士通 ESPRIMO D5320 ですが、再びデスクトップ・パソコンとして復活することとなりました。

今回分解掃除をした 富士通 ESPRIMO D5320 です。

ただハードディスクを戻してしまえば、元通りに稼働するのですが、この際なので、一度分解して 掃除をしました。

マザーボードや電源ユニットを取り外して、筐体は水洗いしました。外部は日頃から雑巾がけをしていることもあり、傷は多めですが、汚れは気にならない状態でした。しかし内部までには手が行き届かないため、今回のような分解時に しっかりと掃除をしておきました。

分解途中の様子です。

プロセッサの冷却ファンは 比較的掃除がしやすいのですが、電源ユニットの冷却ファンの掃除は大変です。電源ユニットのカバーの一部を取り外した後、プリント印刷基盤の一部のネジを外して、冷却ファンとの間の隙間を作って、冷却ファンを取り出しました。冷却ファンの羽を一枚ずつ掃除をしました。元通りに組み立て直して、電源ユニットの掃除を終了しました。
(注意)電源ユニットの分解はパソコントラブルの原因となりやすいものです。自信のない読者さんはエアーダスターなどで隙間からホコリを吹き飛ばしてください。

電源ユニットから冷却ファンを引っ張りだしたところです。
滅多に掃除が出来ない場所なだけに念入りに掃除をしておきました。

水洗いした筐体が十分に乾燥したところで、組立を行なって動作試験を行なってみました。内部に多少残っていると思われる水分を飛ばすためにも、マシンが発熱するメモリ試験(memtest86+)を行いました。

富士通 ESPRIMO D5320 には Pentium D が搭載されていました。
memtest86+ の表示で知りました(笑)。
発熱が多くなければ、このまま使用を続けても問題ないマシンではあります。

小一時間ほどメモリ試験を行なって問題がないことを確認しました。これで気分よくパソコンを使用することができます。

水洗いが終わった後、組立を行なって動作試験を行なっているところです。

富士通 ESPRIMO D3260 は、結局 自宅サーバへ

昨日入手したばかりの 富士通 ESPRIMO D3260 はデスクトップ・パソコン(Debian Wheezy Gnome3)として使用を開始しました。しかしいろいろと面倒な不具合が発生していることを発見して、いろいろと対策をしてデスクトップ・パソコンとして使い続けるよりは、ビデオ画面に関係なく動作する自宅のサーバへと転向させることとしました。

ハードディスクを交換して、自宅サーバとして動作しているか確認しているところです。

どうも Debian Wheezy では、SiS671 チップセットの内蔵ビデオ用のドライバに xserver-xorg-video-sis が使用されているようです。この xserver-xorg-video-sisは、xf86-video-sis を Xorg 用にビルドしたもののようです。殆どオプションが存在しないのですが、いくつか設定してみましたが、マウスカーソルの消滅や VLC の画像フリーズには対応できませんでした。

なお Puppy Linux 5.7.1 では問題はありませんでしたが、ビデオドライバに vesa ドライバを使用していて、明らかに画面の動きが遅いことが気になりました。vesa ドライバを使ってまでデスクトップ・パソコンにする必要性はないと判断しました。

vesa ドライバを使用しない手段として、定評のあるビデオカードを入手して、SiS671 のビデオ回路を使用しない方法も考えられましたが、音声がモノラルで出力されるなど、その他にも SiS671 を原因とする不具合が発生することもあるため、デスクトップ・パソコンとして使用することを諦めました。幸い我が家では自宅サーバ類が存在しているため、この自宅サーバのうち、一番の重責を担っているサーバとマシンを入れ替えることとしました。

ただ問題は、主たる自宅サーバは FreeBSD のシステムで構築されていて、今までのようにインテル主体のチップセットのマシンと同様に稼働するかどうかが心配なところです。

とりあえずハードディスクを新しい ESPRIMO D3260 へ装着して、動作確認を行なってみました。イーサネット用チップなども Broadcom のものを使用していることもあり、とりあえず全く設定を変更することなく稼働をしています。

一番心配な点は、 Silicom Image の Sil シリーズの SATA コントローラのように通常は動作するのですが、ハードディスクへの読み書きが輻輳するような状態になるとエラーを発生するような事態にならないことを期待するばかりです。しばらく、この FreeBSD で構築された自宅サーバで運用して結果を判断したいと思います。

自宅サーバとなった D3260 (右)と、従来から運用している PT2 サーバの D5210 (左)です。

2014年10月28日火曜日

富士通 ESPRIMO D3260 を入手しました

表題の通り、インターネット・オークションにて 富士通 ESPRIMO D3260 (Core2Duo E4600 2.4GHz) を落札してきました。

今回入手した 富士通 ESPRIMO D3260 です。

以前は、デスクトップパソコンに IBM の ThinkCentre を落札することが多かったのですが、ここ2〜3年は富士通のものを選んで落札しています。同じメーカーの同じシリーズのものを使用していると、掃除などのときに分解しやすい・部品の流用ができる などの理由があってのことです。

今までは Pentium4 世代のプロセッサのマシンでしたが、ようやく我が家にも Core2Duo のプロセッサのマシンが導入されることとなりました。

元々デスクトップ・パソコンとして使用していた ESPRIMO D5320 からハードディスクを移設して、Debian Wheezy の Gnome3 のデスクトップを使用開始してみました。

やはり新しい世代のプロセッサを搭載していることもあって、動作は以前よりも機敏になりました! ソフトウェアの立ち上がり時間やファイルを開く時間などが短縮されたように感じました。やはりこの ESPRIMO D3260 を落札してよかったと感じた瞬間でした。

が、しかし ・・・ 問題もありました。 とりあえず以下の二点です。

まず気づいたことは、マウスカーソルの消失です。アイコンなどにカーソルを乗せると説明文が表示されますが、このときカーソルが消失した状態となってしまい見失ってしまうのです。小刻みにマウスを動かして消失に対応すればカーソルを発見できるのですが、やはり不自由です。

そして動画プレーヤの VLC のビデオ画面がフリーズするのです。音声はちゃんと流れるのです。それもプロセッサの使用率が100パーセントに張り付いてしまい、VLC を終了させてもプロセスが残ってしまい、プロセッサに負荷を掛け続けているのです。手動で kill コマンドで残ったプロセスを停止させなければなりませんでした。なお Totem などの動画プレーヤは正常に動作しています。

なお Puppy Linux 5.7.1 JP において VLC を新規にインストールして、動作させてみたところ、問題なくビデオ画面を表示して、問題なく VLC を終了させることができました。Debian Wheezy の設定の問題なのでしょうか? 現在のところ原因は不明です。

(追記)
音声はステレオではなく、モノラルとなるようです。


以下は入手した ESPRIMO D3260 を使用開始する前に分解して掃除をしているところを撮影したものです。

マシンは中古パソコン業者から落札したもので、内部は高圧エアーでホコリをほとんど吹き飛ばした綺麗な状態でした。しかしタバコのヤニなどは高圧エアーだけでは綺麗することが出来ないため、分解掃除において筐体などの水洗い可能な部分は、水洗いを行いました。

マシンを分解して筐体を水洗いしました。
タバコのヤニ状のものが各部に付着していて、これで綺麗になりました。
マシンを分解して取り出したマザーボードです。
低価格帯のマシンのようで、チップセットに SIS 社のものが使用されていました。
プロセッサ用のヒートシンクを取り外したところです。
シート状の伝熱グリスが貼り付けられていました。
古い伝熱グリスをプラカラー用の薄め液で綺麗に拭きとりました。
表面に Core2Duo も刻印が見えます。
プロセッサの表面に伝熱グリスを塗布しました。
ヒートシンクのプロセッサと接触する部分にも伝熱グリスを塗布しました。
すっかり水気が無くなったところで、マシンを組み立てなおして動作確認を行いました。
とりあえず Puppy Linux 5.7.1 JP でマシンを起動させて、各部の動作確認を行なってみました。
上が今まで使用していた ESPRIMO D5320 で、下が今回入手した ESPRIMO D3260 です。

2014年10月27日月曜日

ThinkPad i 1200 で Puppy Linux 5.7.1 JP を起動

入手当時にすでに起動が出来なかった Puppy Linux 5.7.1 JP をライブ CD で起動させることができました。ただ Debain Wheezy のインストールの時と同様で、ビデオ画面に横方向のノイズが発生する状況となっています。症状が同じことから、同じ Silicon Motion SM712 に関連したものと思われます。

Puppy Linux 5.7.1 JP が起動した ThinkPad i 1200 です。

ThinkPad i s30 で Puppy Linux 5.7.1 JP を起動させた時と同様に Safe Mode から起動させ、xorgwizard で設定するのではなく、カラービット長を 16 と調整した xorg.conf を使用して起動させました。

本来は起動させることができた xorg.conf を紹介するところなのですが、まだ横方向のノイズの問題が残されているため、このノイズ対策が終了したところで紹介したいと思っています。

SM712 のビデオドライバに原因があるのか?ノイズが発生します。

参考ページ
ThinkPad i 1200 へ Debian Wheezy をインストール
http://near-unix.blogspot.jp/2014/10/thinkpad-i-1200-debian-wheezy.html



ThinkPad i 1200 へ Debian Wheezy をインストール

ThinkPad i 1200 へ Debian Wheezy の Xfce4 デスクトップをインストールしました。

ThinkPad i 1200 へ Debian Wheezy の Xfce4 をインストールしたところです。

ThinkPad i s30 や ThinkPad 130 の時と同じように、インストール直後はビデオ画面が真っ暗な状態で起動しました。ビデオチップに Silicon Motion SM712 が使用されていることに原因があることが解っていたため、対応は比較的簡単なように思われました。しかし・・・。
参考ページ
ThinkPad s30 へ Debian Wheezy のインストール成功
http://near-unix.blogspot.jp/2014/09/thinkpad-s30-debian-wheezy_23.html

とりあえず行ったことは ThinkPad i s30 で使用したのと同じ "Screen" のセクションのみを記述した xorg.conf を使用しました。特徴としては、カラービット長を 16 ビットに指定してあることです。

---------- xorg.conf ここから ----------
Section "Screen"
    Identifier "Screen0"
    Device     "Card0"
    Monitor    "Monitor0"
    DefaultDepth 16
    Subsection "Display"
        Depth       16
        Modes       "1024x768"
    EndSubsection
EndSection
---------- xorg.conf ここまで ----------

結果としては、Xfce4 のデスクトップ画面を表示させることができましたが、何故か画面に横方向へノイズが走る状態で、それも画面の操作によって変化するもので、とても見難い状態となっています。

ビデオ画面にノイズが横方向に向けて走ります。
画面を操作すると、それに連れてノイズが変化します。
とてもイライラします(怒)。

Xorg のドライバの siliconmotion のオプションを適宜変更してみましたが、画面のノイズを改善出来ないでいる状態です。例えばアクセラレータ・モードを、なし・XAA・EXA などと変更しましたが、改善されませんでした。

なお、このようなノイズが発生する原因としてビデオチップの故障ということも考えられますが、Puppy Linux 4.3.1 (2012) においては、綺麗にビデオ画面を表示するため、ビデオチップや回路に問題はないものと考えています。

このままでは使用に耐えられないため、もう少し原因を探してみたいと思っています。

2014年10月26日日曜日

ThinkPad i 1200 を分解掃除しました

内部には全く問題のなかった ThinkPad i 1200 ですが、何となく分解して、掃除をしてみました。

ThinkPad i 1465 と同様のプラスチック素材で作られた筐体でしたが、非常に脆くなっていて、ちょっと捻ったり、力を入れてしまうと割れてしまう状況となっていました。今回の分解掃除でもアッチコッチの爪が折れてしまいました(涙)。

しかし下記の写真のようにプラスチック部品などは、綺麗さっぱりと水洗いすることができました。これで精神的にも気持よく触ることができるようになりました。

写真は、分解途中の様子などを撮影したものです。

キーボードを取り外した状況です。
筐体には外部から見えるひび割れがありましたが、内部にも割れがありました。
いつものようにプラモデル用の接着剤で割れた部品を接着しました。
これはハードディスクカバーの先端にある爪が織れていたので、写真のようにプラ板を補強に使って接着しました。
冷却ファンを取り外したプロセッサの様子です。
BGA タイプの Celeron 700MHz です。
これが冷却ファンの様子です。ファンの内部にはまだホコリがフェルト状になって固着していました。

システムボードを取り出したところです。表面に付着していたホコリなどを綺麗に掃除しておきました。
システムボードを取り外した筐体は水洗いしました。これがとてもすっきりするのです(笑)。
システムボードの LAN 端子部分を観察していると、ちゃんとソケットが設けられているのを発見しました。Mini-PCI ソケットへイーサネット・カードを接続すれば有線 LAN が使用できるのでしょうか?
液晶パネルのひび割れの様子です。液晶パネルのベゼルを上手く取り外せそうになかったので、今回は未修理のままとしました。
綺麗になった部品を再度組み立てて動作試験をしているところです。
筐体を水洗いしているので、動作状態にしておいて、内部を積極的に乾燥させようとしました。
後で気づいたのですが、液晶パネルを支える左ヒンジに割れが発生しているのを発見しました。
どうも液晶パネルのネジ穴の割れや筐体の割れもこのヒンジの固着によるものと思われました。

2014年10月25日土曜日

ThinkPad i 1200 を入手しました

ThinkPad i シリーズの 1200 (1161-72J) を入手しました。いつものようにインターネット・オークションにて落札してきました。最近はだんだんと古い ThinkPad の出品が少なくなっているようで、ちょっと寂しいです。

宅配業者さんから受け取った荷物を開梱して、すぐに掃除に取り掛かりました。もういつもの儀式となっています。液晶パネルやキーボードを中心にして、特に念入りに掃除をしました。掃除と言っても、ブロアーでキーボードやプロセッサの冷却ファンのホコリを吹き飛ばした後に、ひらすら雑巾で表面を拭くだけなのですが。

表面が綺麗になったところで、ようやく電源を投入しました。無事電源が入り、起動時のロゴも見えました。そして Windows 2000 が起動しました。筐体には Windows Me のシールが貼り付けてあったので、きっと前のオーナーさんが入れ替えたもののようです。

前の所有者さんが Windows2000 をインストールしていたようです。

個人データなどは消去されていましたが、ウィルス対策ソフトウェアなど、以前のオーナーさんの痕跡が残っている状況でした。ハードディスクを検査した後、ハードディスク消去ソフトウェアを使って綺麗サッパリ消し去りました。

ハードディスク(IBM-DJSA-220)は、カラカラと異様な動作音を立てていましたが、MHDD での検査では、意外なほど良好な結果となっていました。
HGST の DriveFitnessTest も異常なしとの判定が出ました。
ハードディスクの消去に初めて MAXLLF を使ってみました。
普通のゼロフィル動作のソフトウェアだと思いますが、なんか動作が遅いように感じました。

メモリは、オンボードに 64MB が搭載されており、前のオーナーさんの手によって 64MB のメモリが追加されていました。これも memtest86+ を使ってメモリ試験を行なっておきました。この後、追加されていた 64MB のメモリを抜き取って、128MB のメモリを追加して、合計 192MB のメモリ容量としました。i440MX のチップセットを搭載している本機では、これで最大容量となるようです。

オンボード 64MB に、拡張 64MB のメモリが搭載されていました。
memtest86+ によるメモリ試験です。

ここで OS として Puppy Linux をインストールすることとしました。

メモリの容量が 192MB と少ないため、フルインストールを予定しています。バージョンは 5.7.1 JP を予定していましたが、メモリ容量gは少ないと Puppy Linux 5.7.1 JP の GParted が上手く動作しないことが多いため、Puppy Linux 4.3.1 (2012) を使って、ハードディスクのパーティション分割を行うこととしました。

Puppy Linux 4.3.1 では、X の設定で、16 ビットで設定して起動させることができました。

写真のように前半分を Ext3 でフォーマットした後、スワップ領域として 512MB ほど確保しておきました。

一旦 Puppy Linux 4.3.1 を終了して、Puppy Linux 5.7.1 JP を起動させてみました。

何と!画面が真っ暗になる現象です。ThinkPad 130 などと同じ症状のようです。

Silicon Motion SM712 を搭載しているので 24 ビットのカラービット長では動作してくれません。

そこで再度 Puppy Linux 4.3.1 で起動した後、ビデオ設定の xorg.conf を調べてみたところ、やはり ThinkPad 130 と同様に Slicon Motion SM712 が使用されていました。カラービット長が 24 ビットでは動作せず、16 ビットに設定する必要があります。

そこで Puppy Linux 4.3.1 で設定した xorg.conf を USB メモリへコピーした後、再度 Puppy Linux を Safe Mode で起動させて、Puppy Linux 4.3.1 の xorg.conf をコピーして X を起動させてみました。

Puppy Linux 5.7.1 JP を Safe Mode で起動させて、xorg.conf をコピーしました。

ThinkPad 130 の時と違って、この ThinkPad i 1200 では、デスクトップ画面が表示されましたが、直後に画面にノイズが走り、システムがフリーズしてしまいました(涙)。やはり xorg.conf の単純移植では動作しないようです。今後の検討課題です。

Puppy Linux 5.7.1 JP は、この状態でフリーズしました。

以上で本日の作業は終了となりました。筐体の底面には割れ目などがあり、今後、掃除を兼ねて分解修理が必要だと感じました。修理を行った場合には、また本ブログにて報告したいと思っています。