2010/09/30

自前ブロードバンドルータからフレッツスクウェアに接続してみる

alixで作成したdebianベースのブロードバンドルータを使っていますが、いままでマルチセッションの設定は行なっていませんでした。

フレッツ光メンバーズクラブのダイレクトメールが届いた機会に、マルチセッションでフレッツスクウェアにアクセスするように設定をしました。

平行してNintendoDS用にWEPで構成している無線LANのアクセスポイントをLANから切り離してインターネットとの通信だけを行なうようにしたので、それは改めて別の記事にまとめます。

2010/10/12追記: この記事でのppp周りのスクリプトには十分でない処理があり正しく動作しません。 その点をフォローするように書き直す予定ですが、規模が膨らむため時間がかかりそうです。 そのためこの記事を修正していて、修正個所はこの囲み(Note)でフォローしています。

作業の流れ

今回行なった作業は次のような流れになりました。

  • /etc/ppp以下のファイルを編集して、パスワードなどのflets用PPPoE設定を加える
  • /etc/network/interfacesを編集して、flets用ネットワークデバイス(ppp1)の設定を加える
  • ルーティング情報の追加
  • DNSを変更して、fletsドメインの問合せ先を追加

DNSについてはeucalyptusのテストのために、ドメイン毎にforwarderのIPアドレスを指定できるようにしていたので、そこに"flets"ドメインの検索だけをNTTのDNSサーバに投げるようにしています。

一から作るのも難しくはないですが、/etc/resolv.confを取り敢えず修正すれば簡単なデバッグはすぐに出きる事も覚えておくと良いかもしれません。

PPPoEの設定の追加

alixで使っているPPPoE用のソフトウェアは、debian lennyなので ppp-2.4.4rel-10.1 + pppoe-3.8-3 です。

現在契約しているプロバイダとの接続はPPPoEで既に行なっているので、それを真似て設定ファイルを準備していきます。

接続用のパスワードを設定する

/etc/ppp/pap-secretsに追加した1行

"guest@flets" * "guest"
/etc/ppp/peers以下に設定ファイルを作成する

今回は flets という名前のファイルを作成することにしました。 この名前は/etc/network/interfacesファイルの中で使います。

dsl-providerはpppoeパッケージが配置するデフォルトの接続用ファイルで、既にISPに接続するために安定して動いている設定が入っています。

$ sudo ls /etc/ppp/peers/dsl-provider /etc/ppp/peers/flets

作成したfletsファイルの最下行に設定しておいた user行 をflets網へのアクセス用IDに変更します。

/etc/ppp/peers/fletsの変更した個所

user "guest@flets"

短い設定ファイルなのでコメントと空行を除いた内容を書いておきます。

sudo egrep -v '^#|^$' /etc/ppp/peers/fletsの実行結果

noipdefault
nodefaultroute
hide-password
lcp-echo-interval 20
lcp-echo-failure 3
connect /bin/true
noauth
persist
mtu 1454
noaccomp
default-asyncmap
plugin rp-pppoe.so eth0
user "guest@flets"

2010/10/12追記 "defaultroute"オプションを指定していると、ifup/ifdown時にppp0を巻き込んでデフォルトゲートウェイが変更されてしまいます。 今回は手動でルーティングを変更しますから、明示的に"nodefaultroute"に変更しました。

ここまででパスワードの登録と、それを呼び出す設定を追加しました。 この設定を有効にする設定をinterfacesファイルに設定します。

ネットワーク構成の追加

flets用のPPPoE接続をするように設定を追加します。

/etc/network/interfacesファイルの編集

次のような設定を追加します。

/etc/network/interfacesファイルへの追加内容


auto flets
iface flets inet ppp
  provider flets
  post-up /usr/local/sbin/ppp_flets_up.sh

ルーティングの設定

interfacesファイルに追加した ppp_flets_up.shスクリプト で、 ルーティングの削除や追加を行ないます。

ルーティング情報は、公式サイトの ルーティング情報で確認することができます。

これとは別に検索すると、 http://routing.flets/routing.htmlについての情報がみつかります。

routing.fletsは接続できない事にはアクセスできない情報ですし、サイトの役割も明確ではなかったので、公式サイトに載っている3つのルーティング情報を加えておく事にしました。

routing用スクリプト - Type 1

2010/10/12追記: "sleep 5"を入れているのは、ppp1デバイスが認識されておらず、routeコマンドの処理に失敗する場合があったために追加しました。

2010/10/12追記: 環境変数IFACEには物理デバイス名、LOGICALには論理デバイス名が入るはずでしたが、実際には両方ともが登録されていました。 動的に値を取得する方法は、とりあえずなさそうなので固定的に"ppp1"と決め打ちしています。

スクリプトの役割は閉じたネットワークであるfletsを向いたデフォルトルートの削除と、その閉じたネットワークに向かう限られたネットワークの追加です。

routing設定用スクリプト: /usr/local/sbin/ppp_flets_up.sh

#!/bin/bash
DEVICE="ppp1"
sleep 5
/sbin/route add -net 220.210.194.0 netmask 255.255.255.128 dev ${DEVICE}
/sbin/route add -net 220.210.198.0 netmask 255.255.255.192 dev ${DEVICE}
/sbin/route add -net 220.210.199.144 netmask 255.255.255.240 dev ${DEVICE}
routing用スクリプト - Type 2

この部分は上記の設定で十分なので参考程度に留めてください。

後からwgetでコピーしたrouting.htmlを処理するためのスクリプトも組んでみました。 routing.htmlファイルはスクリプトが配置されている場所と同じディレクトリにあるとします。

ifupから呼び出された場合にはIFACE環境変数にデバイス名が入っているはずなので、ppp1ではない場合を想定して、これを利用しています。

routing設定用スクリプト using routing.html: /usr/local/sbin/ppp_flets_up.sh

#!/bin/bash
BASEDIR="$(dirname $0)"
DEVICE="ppp1"
sleep 5
while read line
do
  eval $(echo $line | awk -F, '/Route.=Add/ {print "/sbin/route add -net ",$2,"netmask",$3,"dev ${DEVICE}"}')
done < ${BASEDIR}/routing.html

環境変数IFACEが設定されていない場合にはexitするべきでしたね…。

DNSへのfletsドメインの追加

閉じたネットワークにあるwww.fletsやrouting.fletsサイトにアクセスするためにはIPアドレスが必要です。

今回は flets をドメイン名とするホストのIPアドレスの解決をBIND9任せることにしました。

公式サイトでターゲットにする DNSサーバのIPアドレスがわかります。 やったことは/etc/bind/named.conf.localファイルに設定を追加してDNSをリスタートしただけです。

/etc/bind/named.conf.localに追加した設定内容

zone "flets" {
  type forward;
  forward only;
  forwarders { 220.210.194.67; 220.210.194.68; };
};

全体のforwardersセクションにはISPのDNSサーバを書いています。 全部をfletsのDNSサーバに投げても良いのかもしれませんが、閉じた場所にあるDNSがどこまで信用できるものかわからないので、fletsドメインだけの名前解決に利用しました。

起動方法

設定が終ればinterfacesファイルに書いた設定名をifupコマンドに指定するだけです。

$ sudo ifup flets

まだ時々挙動がおかしい気がします。しばらく様子見です。

まとめ

今回は既に動いている alix上にあるブロードバンドルータを変更したので、少し前提事項がありました。

基本はdebianが動いているx86マシンなので、特に変な事はないと思いますが、fletsにアクセスする時にルーティングとDNS周りを解決するのがちょっと面倒かもしれません。

マシンが一台だけなら仕組みを作るよりも、その時だけ/etc/resolv.confを手で変更するとか、そもそもブロードバンドルータを手作りなんてしない、っていうのが良さそうです。

2010/09/23

beagleboard用にlinuxカーネルを新しくしてみた

手元のbeagleboardのスペックは次のようになっています。

  • Rev. C3
  • X-Loader 1.4.2 (Feb 19 2009 - 12:01:24)
  • U-Boot 2009.01-dirty (Feb 19 2009 - 12:22:31)

以前は http://rcn-ee.net/deb/kernel/beagle/lenny/にあったbeagleboard用のkernelの配布場所が、サーバはそのままにディレクトリが /deb/lenny/へ変更になっていました。

beagleboard用にカーネルを新しくしたので、そこを踏まえてメモを残しておきます。

導入するkernelバージョンを決める

最近はkernel.orgをみるとstableなカーネルのバージョンが、かなり多数あります。

ここはstableの安定板である2.6.35.5をターゲットに、beagleboard上で現在使っている2.6.32.11-x13を置き換えることにしました。

さっそく開始

http://rcn-ee.net/deb/lenny/の2.6.35.5-x4/install-me.shを使う事にします。

beagleboardはUSB経由でLANに接続しているので、作業は全てbeagleboard上で行なうことにしました。

作業はとっても簡単

以前と比べればinstall-me.shは安定した動きをするようで、./tempではなく/tmpを使うようにしたり、ディレクトリを作成する作業もsudo経由で行なわれるなど権限に関する問題はほぼなくなったようです。

$ cd
$ wget http://rcn-ee.net/deb/lenny/v2.6.35.5-x4/install-me.sh
$ /bin/bash install-me.sh

これだけで作業は完了しました。

気になっていたhdparmの結果を確認してみる

# /sbin/hdparm -t /dev/mmcblk0

hdparmの出力結果

/dev/mmcblk0:
 Timing buffered disk reads:   54 MB in  3.02 seconds =  17.89 MB/sec

作業前は約5MB/secでしたが、現在はSDカードのスペックをほぼフルに出せています。

これが一番の目的だったので、もうしばらく遊べそうです。 beagleboard-xMもdigikey日本版で扱いが始まりましたが、買う余裕もないし、しばらくは手を出さないつもりです。

2010/09/16

Vistaの「プログラムから開く」で、どっちがGUI版Vimか分からなくなった

なんだか説明するのが面倒なのですが、Explorerでファイルを右クリックすると表示されるメニューの中に「プログラムから開く」というのがあります。

これが、下のような状態になってしまい、GUI版Vim (gvim.exe)ともう片方のコンソール(CUI)版Vim (vim.exe)のどちらが、どっちなのか分からなくなってしまいました。

違うプログラムが同じ名前で表示されているメニュー

今回は最終的に、下の状態にもっていくというお話しです。

gvim.exeのみが表示されているメニュー

そもそもの問題を避けるために

Vistaでしか検証していませんが、次のようなルールを守れば、問題ないのかなと思われます。

  • 本家日本語版(kaoriya版vim)のどちらか片方だけを使う
  • 本家を使うなら「プログラムを開く」の近くに表示される「Vimで編集する」を選択する
  • (インストーラを使わない場合は特に)Vimを起動したら配置場所を変更しない
  • CUI版とGUI版のどちらかだけを使い続ける

普通は C:\Program Files\Vim\ にインストールしたら、その場所を変更すればまずいだろう、という事は想像がつくかもしれません。 けれどもインストーラの付属しないバイナリプログラムを単体でダウンロードした場合などでも、一度プログラムを実行するとその場所がレジストリに記録されてしまいます。

実行形式のプログラムは移動しないのがWindowsの作法という事なのかもしれません。

問題は以前にgvim.exeを起動した事があって、しばらく経ってから別の場所にダウンロードして起動した場合、どうやっても「プログラムを開く」から選択できなくなる可能性がありそうだという点でしょうか。

問題1 - gvim.exeファイルを移動したら「プログラムから開く」で選択できなくなった

一度「プログラムを開く」でgvim.exeを選択してから、別の場所にgvim.exeを移すと当然のように「プログラムを開く」メニューからは消えてしまいます。

そこで改めて「プログラムを開く」で選択するのですが、どういうわけかアイコンは追加されません。

結局のところ手動で regedit を起動し、次のように \HKEY_CURRENT_USER\Software\Classes\Applications\gvim.exe\shell\open\command を正しいpathに修正する必要がありました。 ()

正しいpathに手動で書き換える様子

反対に不正なpathに書き換えてしまえば、選択肢から消すことも可能です。 最終的にCUI版Vimのpathを正しくない場所を指すように変更してしまいました。

問題2 - 「プログラムから開く」にCUI版Vimが同じ名前で表示されてしまい、GUI版Vim

これは最初の図と同じ状態です。 ここまでの方法を踏まえると、既に問題は解決しているのですが、一応名前を"Vi Improved - A Text Editor"から Vi Improved - A GUI Text Editor に変更したいと思います。

これもレジストリで一箇所を変更したのですが、MuiCacheなので何かの表紙に変更されてしまうかもしれません。

バイナリエディタあたりでプログラムに登録されている名前を直接変更する方が確実そうですが、とりあえずテンポラリの方法として使えそうです。

変更する場所は \HKEY_CLASSES_ROOT\Local Settings\Software\Microsoft\Windows\Shell\MuiCache で、プログラムに対応するテキストを書き換えます。

Vimの表示名を変更している様子

2010/09/20追記: 結局のところ変更したMuiCacheのレジストリエントリは再起動後に元に戻ってしまいました。 CUI版vimは一覧に表示されないようになっているので、特に問題はありませんが、恒久的にはバイナリエディタを使うしかないのかなぁ、と思っているところです。

まとめ

ここでの事はVistaだけでの事なので、Windows7などでは通用しないかもしれません。 どうせ買うならIISのテストも兼ねて、Windows7 Professional以上のパッケージ版をVMWareで動かしたいところですが、3万円以上の出費は痛過ぎるので、当分無理でしょうね。

Windowsには詳しくないので間違った事があれば優しく指摘して頂ければ幸いです。

2010/09/14

7-Zipで開けないアーカイブを開いてみた 〜再考〜

前回の投稿ではまとめきれていなかったので、情報を整理しておこうと思いました。

7-Zipが悪いわけではない

表示されたメッセージは次のようなもので、圧縮形式の問題であることがわかります。

7-Zipが表示したエラーメッセージ

7-Zip公式サイトのFAQの中に、WinZIPが互換性のない圧縮形式を使うことの記述があります。

%TEMP%以下に展開されるsetup.exeは起動可能

自己展開形式ファイルを実行すると、%TEMP%以下の WZSEn.TMP フォルダ(nは0からの数字)に展開され、その中にあるsetup.exeを最後に実行します。

展開処理を途中で止めて、手動で%TEMP%以下にあるsetup.exeを実行すると問題なくインストーラが起動します。

インストーラから起動したsetup.exeが異常終了

procmon.exe (from SysinternalSuite)というツールを使って、実行時の処理を眺めていたらsetup.exeが呼ばれているものの RC=24 で終了している事が分かりました。

setup.exeがRC=24で終了しているprocmon出力

まとめ

いまのところはインストーラから起動した場合だけ、setup.exeが正常に起動しないことだけが分かっています。

かなり中途半端なのですが、とりあえずトラブルシュートの手法はいろいろ得られたので、 当面は現状に満足して、こん件はこのまま放置することになりそうです。

MacOS X上のVirtualBox SDKでAPIの動きを調べてみた

Ubuntu LTS上にVMWare Workstationがあるのに、なぜかMacOS XでVirtualBoxを動かしています。

さて、VirtualBoxのAPIにはIStorageController::minPortCountというメソッドについての記述があります。

9.38.1.3 minPortCount (read-only)
unsigned long IStorageController::minPortCount
Minimum number of ports that portCount can be set to.

portCountに指定できる最小の数が定義されているはずなのですが、SATA以外の(SCSI, SAS, etc)オブジェクトでは初期化時点でportCountの戻り値はmaxPortCountと同じになります。

VirtualBoxのフロントエンドのコードを合せて読んでいくと、いろいろ小手先でやっている事があるようです。

portCount関連について、もう少し

minPortCountの値について、psude codeを使うとこんな感じでしょうか。

If controllerType == SATA, IStorageController::minPortCount == 1,
else, IStorageController::minPortCount == IStorageController::maxPortCount.

portCount自体もAPIに定義されている数とは違うように思われるので、「SATAバスに30までのストレージを順番に追加していく」みたいな処理は、空いているポート番号や(連番と仮定しても)総ポート数を知る必要がありますが、毎回ぶら下っているディスクを調べてあげなければなりません。

もっともフロントエンドでもmaxPortCountとportCount変数のみを参照していて、minPortCountは使われていないようです。

そもそもSATAの場合を特別扱いしているコードが散見され、portCountはAPI上ではmaxPortCount(30)に初期化されますが、フロントエンドではSATAだと 1 に再度設定してしまいます。

SCSIやIDEデバイスではportCountの数字が変動しないので、いろいろ不思議です。

処理の途中でportCount, minPortCount, maxPortCountを表示させると、SATAを使わない場合には全てaxPortCountと同じ値になっているのがわかります。

minPortCountメソッドの定義自体はmaxPortCountとほぼ同じで、対称性を維持するためには必要かもしれませんが、アジャイルな考え方になると不要なものに分類されそうな勢いです。

バスの使用状況を調べるといったニーズはあるだろうけれど、portCount周りは不要じゃないかなという印象でした。

Web APIを使ったVirtualMachineの追加の流れ

もともとはVM作成の処理を自動化したかったので、ここからが本題になります。

フロントエンドを使ってVMを新規に作成した場合には、ディスクの追加などの各種デバイスは自動的に準備されますが、APIを使う場合には、ほぼ空っぽのVM定義だけが準備されます。

HDDだけでなく、インストールに必要なDVDメディアの登録なども必要になります。

インストールまでのおおまかな処理は次のようになります。

  • IVirtualBoxインスタンスを通して、IMachineオブジェクトの作成 (IVirtualBox::createMachine())
  • 作成したVM定義の登録(IVirtualBox::registMachine()によるクローズ処理)
  • IVirtualBox::openSession()を通して、変更可能なIMachineインスタンスの再取得
  • IStorageControllerオブジェクトの登録 (IMachine::addStorageController())
  • 別途IVirtualBoxインスタンスを通して作成したIMediumオブジェクトのIStorageControllerへの割り当て (IMachine::attachDevice())
  • 以下、同様にIStorageControllerオブジェクトの取得と、メディアの登録をDVD, Floppyなどに対して繰り返す
  • メモリ割り当てや起動メディア順の入れ替えなど、定義情報の修正
  • IVirtualBox::openRemoteSession()によるVMの起動とインストール作業の開始

VMを作成した直後にはストレージコントローラは追加できないので、セッションを開かないといけないなど、いろいろと細かい手続きが必要になりました。

ここら辺のプロトタイプを作成した経験を踏まえて、すっきりとした内部構造を持つアプリケーションを設計して行こうとしています。

とりあえずは、ステータスのまとめまで。

2010/09/12

7-Zipで開けないアーカイブを開いてみた

Inspiron 640mで動いているWindows VistaではZIP等アーカイブファイルの展開に7-Zipを使っています。

個人的なWindows環境ではlhasaやlhaplusといったツールも以前は使っていたのですが、個々のプログラムではなくて、LZH形式自体の脆弱性が知られるようになってからはアンインストールしてしまいました。

7-Zipは圧縮効率とスピードとのバランスが気にいっているのですが、たまたまVista環境でうまく展開できないファイルを見つけたので他のプログラムを試す機会を得ました。

展開できないファイルとは…。

あまり大きな声ではいいたくないのですが、Vista機に昔を懐しんでDB2 Express-C 9.7.2 for Windows (ファイル名:db2exc_972_WIN_x86.exe) をインストールしようとしました。 これは自己解凍形式のEXEファイルなのですが、展開に失敗し、インストーラが立ち上がらない状態になってしまいました。

VMWare上のWindowsXPでは展開できるので、自分のVista環境のDLLやら過去に導入した何かが影響していると考えるのが妥当そうです。

DB2 Express-Cは無償版ですし、Forum等を検索をしても似たような事象は発見できなかったので、今回は自力で解決策を探ってみました。

とりあえず展開できないか、いろいろ試してみる

いまになって振り替えると、Windows版のlddコマンドでもあればリンクされているDLLを疑う事もできたのかなと思います。残念ながらWindows周りは詳しくないので、直線的に突進するしかありませんでした。

ファイル自身を実行する自己解凍機能がうまく動いていないようだったので、ファイルの拡張子を .exe から .zip へ手動で変更して、7-Zipで展開を試みました。

展開自体は行なわれたのですが、うまくいかず、最終的に展開に失敗したファイル群がレポートされるという結果になりました。

ただ、自己解凍形式のファイルであったも任意のアーカイバで展開できる事がわかったので、他のプログラムを探す事にしました。

7-Zipよりもう少し信頼性のあるアーカイバを探す

7-Zip自身がよく使われているので、これよりも確実に動きそうなフリー、もしくは、オープンソースなアプリケーションはないように思えました。

ZIP形式の由来はWikipediaによると、最初に PKWareという会社が開発し、現在はWinZipという会社と争うように暗号化などに対応した製品版の開発・販売を行なっている模様です。

そういえば以前いた会社ではWinZipが使えたなぁと思いつつ、ここら辺の製品が使えないか調べてみました。

最終的に圧縮ができない展開専用のアプリケーション ZIP Reader を、PKWareの Downloadsエリアで発見しました。

売り物ではないからか、 Products エリアにはリンクがないので、最初は見落したんですけどね。

ZIP Readerを試す

先ほどの拡張子を変更した、 db2exc_972_WIN_x86.zip ファイルをZIP Readerで展開すると無事に"db2exc_972_WIN_x86"フォルダが作られ、全ファイルが展開されました。

7-Zipではサイズがゼロだったreadmefirst.txtファイルもちゃんと読む事ができます。

この中のsetup.exeを実行して無事にVista機にDB2 Express-C 9.7.2を導入する事ができました。

さいごに

原因が不明なので、この結果だけでは「7-Zipを止めて、ZIP Readerを使おう」とはいえなそうです。

やはりldd的なコマンドを使って原因がDLLにないか、時間をみつけて確認することにしましょう。

DB2自体は慣れているせいもあって、端末からのテーブル作成などはすぐにできました。

LDAPサーバみたいに郵便番号データでも入れて、検索アプリを作ってみることにしましょう。

でもInterbaseをベースにしているFirebird 2.5が出たら、そっちに夢中になるかもしれません…。

2010/09/10

DRBDの不整合状態を修正してみた

DRBDをUbuntu 8.04でテストした時には、debian lennyとの間でocfs2がうまく動かなかったのですが、 Ubuntu 10.04になってからは問題なく動いていました。

ある時、vmwareが動かない事で/etc/rc2.d/以下のスクリプトの大半が実行されていない事に気がついたのですが、原因はDRBDでした。

drbdadmコマンドを使うだけで解決したのですが、単純に設定だけじゃなくてDRBDの裏の動きもある程度把握していないと複雑な状況に対応できないかなと感じました。

初期症状

いつの間にかDRBDのステータスが以下のようになっていまいました。

この結果、/etc/rc2.d/S06drbdが終了せずにいつまでも接続待ちのままプロセスが残り、後続の/etc/rc2.dにあるスクリプトが実行されない状態になってしまいました。

回復させるために手動で停止するか、/etc/rc2.d/S06drbd stopを実行して、処理を継続させる必要がありました。

主に参照する側の/etc/init.d/drbd status出力

drbd driver loaded OK; device status:
version: 8.3.7 (api:88/proto:86-91)
GIT-hash: ea9e28dbff98e331a62bcbcc63a6135808fe2917 build by root@athlon, 2010-08-04 17:46:47
m:res  cs            ro               ds                 p  mounted  fstype
0:r0   WFConnection  Primary/Unknown  UpToDate/DUnknown  C

主に書き込みが発生する側の/etc/init.d/drbd status出力

drbd driver loaded OK; device status:
version: 8.0.14 (api:86/proto:86)
GIT-hash: bb447522fc9a87d0069b7e14f0234911ebdab0f7 build by phil@fat-tyre, 2008-11-12 16:40:33
m:res  cs          st               ds                 p  mounted  fstype
0:r0   StandAlone  Primary/Unknown  UpToDate/DUnknown  -

対応方法

一方は単純に接続待ちになり、もう片方は StandAlone 状態になっていたので、StandAloneの方から手動で接続状態にすることにします。

もしどちらがPrimaryになるか自信がなければ、事前に不要な片側を初期化しておくのがベストでしょう。

$ sudo /sbin/drbdadm connect r0

この後でstatusを確認すると、無事に同期が始まっていました。

同期中の/etc/init.d/drbd status出力

drbd driver loaded OK; device status:
version: 8.3.7 (api:88/proto:86-91)
GIT-hash: ea9e28dbff98e331a62bcbcc63a6135808fe2917 build by root@athlon, 2010-08-04 17:46:47
m:res  cs          ro                 ds                     p  mounted  fstype
0:r0   SyncTarget  Secondary/Primary  Inconsistent/UpToDate  C
...    sync'ed:    46.9%              (1006128/1884328)K

ただ、ステータスが Primary/Secondary となっていたので、 WFConnection 状態だった側でPrimaryにしました。

$ sudo /sbin/drbdadm -- -o primary r0

最終的に復旧した状態

drbd driver loaded OK; device status:
version: 8.3.7 (api:88/proto:86-91)
GIT-hash: ea9e28dbff98e331a62bcbcc63a6135808fe2917 build by root@athlon, 2010-08-04 17:46:47
m:res  cs         ro               ds                 p  mounted  fstype
0:r0   Connected  Primary/Primary  UpToDate/UpToDate  C

2010/09/03

HDD換装後のInspiron 640mの熱暴走への対応

夏になってからInspiron 640mの熱による電源断が頻発するようになりました。

Travelstar 7K320が7200回転だから熱がこもるのかなぁと思っていたのですが、 ひょんなことからBIOSのメニューを見直して改善できたようなのでメモしておきます。

BIOSメニューの見直し

起動時にDellのロゴが表示されているところで、 F2 キーを押しているとBIOS設定画面が表示されます。

左側にメニューの中に PerformanceHDD Acoustic Mode という項目があります。

この設定値は次の3つが用意されています。

  • Bypass - デフォルト
  • Quiet
  • Performance

おそらく以前にBIOSの設定を全てデフォルトに変更した事が原因で、Bypassになっていたと思うのですが、これを Quiet に変更する事で症状をかなり改善することができました。

体感的にも発熱が抑えられている印象です。

メニューには Quiet を選択することで"Slow"になるとありますが、 体感速度が目立って遅くなったという事もないのでしばらくこれで使ってみようと思います。

その後、Performanceに設定したものの

まだ真夏日が続いて気温などの条件は変化していないはずですが、設定をPerformanceにしても特に問題は起っていません。

おそらくこれは、たまたまなのだと思いますが、 デフォルトのBypassにしている設定は変更した方が気休めにはなりそうです。