<?xml version="1.0" encoding="UTF-8"?>
<rdf:RDF
 xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
 xmlns="http://purl.org/rss/1.0/"
 xmlns:content="http://purl.org/rss/1.0/modules/content/"
 xmlns:taxo="http://purl.org/rss/1.0/modules/taxonomy/"
 xmlns:dc="http://purl.org/dc/elements/1.1/"
 xmlns:syn="http://purl.org/rss/1.0/modules/syndication/"
 xmlns:admin="http://webns.net/mvcb/"
>
<channel rdf:about="http://blog.gcd.org/">
<title>仙石浩明の日記</title>
<link>http://blog.gcd.org/</link>
<description>京都大学大学院工学研究科情報工学専攻修了。株式会社日立製作所で遺伝的アルゴリズムおよびネットワーク基盤技術の研究に従事。1997年に情報処理学会山下記念研究賞受賞。1998年、電気学会先端システム技術の産業応用調査専門委員会委員。2000年、KLab株式会社取締役CTOに就任。1995年以来、TCP/IPパケットリピータ「stone」や、Palm上の時刻表ツール「Time Table Viewer」などを開発・発表する。また、堅牢で安定したサイト gcd.org を運営し、会員にサービスを提供。そこで得たサーバー構築ノウハウを日経Linuxで、2000年4月から 2年間連載
</description>
<dc:language>ja</dc:language>
<admin:generatorAgent rdf:resource="http://blog.livedoor.com/?v=2.0" />
<items>
 <rdf:Seq>
  <rdf:li rdf:resource="http://blog.gcd.org/archives/51211439.html" />
  <rdf:li rdf:resource="http://blog.gcd.org/archives/51210316.html" />
  <rdf:li rdf:resource="http://blog.gcd.org/archives/51206955.html" />
  <rdf:li rdf:resource="http://blog.gcd.org/archives/51205701.html" />
  <rdf:li rdf:resource="http://blog.gcd.org/archives/51198587.html" />
  <rdf:li rdf:resource="http://blog.gcd.org/archives/51184583.html" />
  <rdf:li rdf:resource="http://blog.gcd.org/archives/51172127.html" />
  <rdf:li rdf:resource="http://blog.gcd.org/archives/51168556.html" />
  <rdf:li rdf:resource="http://blog.gcd.org/archives/51165789.html" />
  <rdf:li rdf:resource="http://blog.gcd.org/archives/51159342.html" />
  <rdf:li rdf:resource="http://blog.gcd.org/archives/51156663.html" />
  <rdf:li rdf:resource="http://blog.gcd.org/archives/51134879.html" />
  <rdf:li rdf:resource="http://blog.gcd.org/archives/51130717.html" />
  <rdf:li rdf:resource="http://blog.gcd.org/archives/51128784.html" />
  <rdf:li rdf:resource="http://blog.gcd.org/archives/51128306.html" />
 </rdf:Seq>
</items>
</channel>

<item rdf:about="http://blog.gcd.org/archives/51211439.html">
<title>なぜ DELL PowerEdge SC440 は ICH7R の Watchdog Timer 機能を利用できないのか？</title>
<link>http://blog.gcd.org/archives/51211439.html</link>
<description>
DELL PowerEdge SC440 は、
インテル 82801GR I/O コントローラー・ハブ (ICH7R) を使っている。
ところが、ICH7 にあるはずの 
ウォッチドッグ・タイマ (Watchdog Timer) 
機能が利用できない。
例えば Linux だとブート時に
「reboot disabled by hardware」すなわ...</description>
<dc:creator>hiroaki_sengoku</dc:creator>
<dc:date>2008-07-14T07:45:33+09:00</dc:date>
<dc:subject>ハードウェアの認識と制御</dc:subject>
<content:encoded><![CDATA[<p>
DELL <a href="http://www1.jp.dell.com/content/products/productdetails.aspx/pedge_sc440">PowerEdge SC440</a> は、
インテル 82801GR I/O コントローラー・ハブ (ICH7R) を使っている。
ところが、ICH7 にあるはずの 
ウォッチドッグ・タイマ (Watchdog Timer) 
機能が利用できない。
例えば Linux だとブート時に
「reboot disabled by hardware」すなわち
「ハードウェアによってリブートが禁止されている」とカーネル・ログに出力される:
</p>
<pre class="terminal">
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
</pre>
<p>
この「reboot disabled by hardware」とは何なのかを調べてみると、
<a href="http://www.intel.com/Assets/PDF/datasheet/307013.pdf">Intel I/O Controller Hub 7 (ICH7) Family Datasheet</a> の 78ページ、
Table 2-23. Functional Strap Definitions (Sheet 3 of 3) に、
</p>
<table class="ruler">
<tr><th>Signal</th><th>Usage</th><th>When Sampled</th><th>Comment</th></tr>
<tr><td>SPKR</td><td>No Reboot</td><td>Rising Edge of PWROK</td>
<td>
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).
</td></tr>
</table>
<p>
と書いてある。
つまり ICH7 の SPKR 端子 (Ball# A19) はスピーカ出力なのであるが、
入力端子としても使われていて、
PWROK 入力端子 (Ball# AA4) の立ち上がりエッジ時
(すなわち電源投入時) において SPKR 端子が H レベルであれば、
「No Reboot」モードに固定される。
</p>
<p>
「No Reboot」モードというのは、
TCO タイマ (つまり Watchdog Timer) による再起動を行なわないモードで、
通常はソフトウェアでこのモードの設定/解除が可能なのであるが、
SPKR 端子によって「固定される」と
No Reboot モードのまま変更できなくなる。
</p>
<p>
具体的には、
「No Reboot」モードの設定/解除は、
ICH7 の「NO REBOOT bit」に 1/0 を書込むことによって行ない、
逆にこの「NO REBOOT bit」を読むことによって現在のモードを確認できる。
Linux カーネルの drivers/watchdog/iTCO_wdt.c に、
このビットを解除し、解除できたか確認するコードがある:
</p>
<pre class="code">
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 &amp;= 0xffffffdf;
		writel(val32, iTCO_wdt_private.gcs);

		val32 = readl(iTCO_wdt_private.gcs);
		if (val32 &amp; 0x00000020)
			ret = -EIO;
	...
	return ret; /* returns: 0 = OK, -EIO = Error */
}
</pre>
<p>
この 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 モード固定なので) 利用不可能であることを示す。
</p>
<p>
というわけで、
DELL PowerEdge SC440 で Intel TCO Watchdog Timer が利用できない理由は、
電源投入時に SPKR 端子に電圧がかかってしまっていて、
No Reboot モード固定になっているためだろう。
SPKR 端子は内部的にプルダウン (20kΩ) されているので、
SPKR 端子につながっているスピーカを切り離せば SPKR 端子は L レベルになり、
Watchdog Timer が利用できるようになるはず。
</p>
<a href="http://blog.gcd.org/archives/51211439.html">続きを読む</a>]]>
</content:encoded>
</item>
<item rdf:about="http://blog.gcd.org/archives/51210316.html">
<title>外国のメーカに修理/交換してもらうとき課税される関税・消費税を減免する方法</title>
<link>http://blog.gcd.org/archives/51210316.html</link>
<description>
ハードディスクが故障したので、RMA 手続きを行なった上でメーカへ送り返したら、わずか4日で代替品が返ってきた (6月28日)。
RMA++ と思っていたら、
10日後の 7月8日にシンガポールのフェデラル・エクスプレスから
「請求書在中」と書かれた AIR MAIL な封書が送られ...</description>
<dc:creator>hiroaki_sengoku</dc:creator>
<dc:date>2008-07-11T10:25:53+09:00</dc:date>
<dc:subject>ハードウェアの認識と制御</dc:subject>
<content:encoded><![CDATA[<p>
<a href="http://blog.gcd.org/archives/51205701.html">ハードディスクが故障したので、RMA 手続きを行なった上でメーカへ送り返したら、わずか4日で代替品が返ってきた</a> (6月28日)。
RMA++ と思っていたら、
10日後の 7月8日にシンガポールのフェデラル・エクスプレスから
「請求書在中」と書かれた AIR MAIL な封書が送られて来た。
え～ せっかく RMA を誉め称えるブログを書いたのに、
今になって何か追加で請求されるとわ... orz と、
暗澹たる気持ちで開封してみると...
</p>
<p>
どきどきしながら「請求書 INVOICE」と書かれた一枚目の書類に目を通すと、
請求額は 1000円。
そんなに高額の請求ではなかったので一安心。
内訳を見ると、
</p>
<table class="ruler">
<tr><td>Other Charges　</td>
<td>消費税／付加価値税(Consumption Tax/VAT)</td>
<td align="right">500</td></tr>
<tr><td>Other Charges　</td>
<td>関税・消費税特別手数料(D/T Advancement Fee)　</td>
<td align="right">500</td></tr>
<tr><th>合計(Total)</th><th></th><th align="right">　1,000</th></tr>
</table>
<p>
関税？
日本って工業製品に対して関税なんてかけていたっけ？
と思いつつ<br />
二枚目の「輸入許可通知書」に目を通すと、
</p>
<table class="ruler">
<tr><th>税科目</th><th>税額合計</th><th>個数</th></tr>
<tr><td>D 関税</td><td align="right">￥0</td><td align="right">0</td></tr>
<tr><td>F 消費税</td><td align="right">￥400</td><td align="right">1</td></tr>
<tr><td>A 地方消費税</td><td align="right">￥100</td><td align="right">1</td></tr>
</table>
<p>
なるほど、
メーカが申告した価格 (CIF) $108.00 に対して約 5% の消費税がかかる、
ということで納税額が 500円なのか。
でも「関税・消費税特別手数料」って何なのだろう？
少なくともこの「輸入許可通知書」には「特別手数料」の文字は見当たらない。
</p>
<p>
まあ高々 1000円だから払っちゃおうか、という考えが頭をよぎる。
ご丁寧にコンビニ払いの用紙まで添付されている。
コンビニ払いか銀行振込を選択可能なようだ。
</p>
<p>
消費税ってのはいわゆる付加価値税のことである
(なぜ VAT (= 付加価値税) という世界的に一般的な名称ではなく、
「消費税」という聞きなれない名称にしたのやら...)。
物品に価値が加わったときにその増分に対して一定割合 (現在は 5%) 
を納税するのが趣旨であるが、
故障したハードディスクを交換したことが「付加価値」に該当するのだろうか？
</p>
<p>
確かに私にとっては、
故障したハードディスクは価値ゼロで、
交換してもらったハードディスクは 13000円 (現時点での WD10EACS の小売価格)
くらいの価値があるから一見価値が増えたように見えるが、
より厳密に考えると「故障したハードディスク」には「RMA 保証」がついていた
(だからこそ交換してもらうことができた) ので、
13000円の価値があったと言ってもよい。
</p>
<p>
そもそも消費税は、このハードディスクを買ったときに支払っている。
当時は 28140円もしたから、なんと 1340円 (本体価格 26800円の 5%) も、
消費税を払っているわけである。
この上、さらに 500円も消費税を払わされてはかなわない。
これは同一物に対する二重課税ではないのか～っ。
もんもんと考えているうちに、だんだんハラが立ってきた (^^;)。
</p>
<p>
というわけで、
なんとかこの理不尽な課税を回避できないか試みることにした。
もちろん、たかが 500円の課税であるので回避できたところで、
かけた労力に見合うわけはないのだが、
まあなにごとも経験である。
軽減できる税金は最大 500円であっても、
軽減交渉という経験はプライスレス。
</p>
<a href="http://blog.gcd.org/archives/51210316.html">続きを読む</a>]]>
</content:encoded>
</item>
<item rdf:about="http://blog.gcd.org/archives/51206955.html">
<title>Western Digital RMA チームから届いた文字化けメールを解読してみた</title>
<link>http://blog.gcd.org/archives/51206955.html</link>
<description>
「故障した HDD WD10EACS を RMA (Return Merchandise Authorization, 返却承認) 手続きで交換してみた」で書いたように、
RMA 手続きを行なった上で Western Digital へ故障したハードディスク ドライブ 
(以下 HDD と略記) を送ったら、
激しく文字化けしたメールが送...</description>
<dc:creator>hiroaki_sengoku</dc:creator>
<dc:date>2008-07-03T07:36:11+09:00</dc:date>
<dc:subject>プログラミングと開発環境</dc:subject>
<content:encoded><![CDATA[<p>
「<a href="http://blog.gcd.org/archives/51205701.html">故障した HDD WD10EACS を RMA (Return Merchandise Authorization, 返却承認) 手続きで交換してみた</a>」で書いたように、
RMA 手続きを行なった上で Western Digital へ故障したハードディスク ドライブ 
(以下 HDD と略記) を送ったら、
激しく文字化けしたメールが送られてきた。
</p>
<blockquote>
あとは HDD が送られてくるのを
のんびり待つだけと思っていたら、
わずか一日後 6/26 18:44 に Western Digital からメールが来た。
しかし文字化けがひどくて読めない。
最初は何語で書いてあるかすら判然としなかったのだが、
どうやら Shift JIS で書かれた文面を quoted-printable エンコードする際に
なにか問題があったようだ。
例えば 0x82 が「,」に、0x95 が「.」に置き換わってしまっている。
置換が規則的でないので、
暗号解読よろしく一文字一文字置き換え規則を推測していくしかない。
<div align="right"><a href="http://blog.gcd.org/archives/51205701.html">故障した HDD WD10EACS を RMA 手続きで交換してみた</a> から引用</div>
</blockquote>
<p>
文面を再現するのに時間がかかりそうだなぁ～と思っている間に、
交換品の HDD が届いてしまったので、
「暗号」解読するモチベーションを失ってしまっていたのだが、
</p>
<blockquote>
Posted by 通りすがり    2008年07月02日 00:36<br />
結局、メールにはなんて書いてあったのでしょうか？
<div align="right"><a href="http://blog.gcd.org/archives/51205701.html#comments">同ページ コメント欄</a> から引用</div>
</blockquote>
<p>
というコメントを頂いてしまったので、
暗号解読してみることにした。
</p>
<p>
以下、Western Digital からの文字化けメールを全文引用 (一部伏字) する:
</p>
<pre class="code">
From: "Western Digital RMA" &lt;noreply@wdc.com>
To: &lt;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&lt;,=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&lt;,=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&lt;=C6"=FA'?,=C9"=AD'-,=B5,=DC,=B7=81B

^=C8?=BA,=CCfhf?fCfu,=F0 Western Digital =
,=CDZ=F3-=CC,=B5,=DC,=B5,=BD=81F

     fVfSfAf&lt;"=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&lt;=B5,=F0Sm"F,=B5,=C4,=AD,=BE,=B3,=A2=81B

-A'-&lt;=C6Z=D2,=CCfVfXfef?,=CC=8DX=90V,=C91?c&lt;=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'-&lt;=C6Z=D2=81F     Fedex
"z'-'=C7=90=D5"=D4=8D?=81F XXXXXXXXXXXX

     fVfSfAf&lt;"=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&amp;l=3Djp&amp;p=3Dm&amp;r=3D8083XXXX&amp;f=3De

"=AD'-,=C6=8D=AB.=EF,=CC=8F=EE.=F1
  - http://websupport.wdc.com/rd.asp?t=3D103&amp;l=3Djp&amp;p=3Drp

RMAfXfe=81[f^fX,=CC?{--
  - =
http://websupport.wdc.com/rd.asp?t=3D104&amp;l=3Djp&amp;p=3Dv&amp;r=3D8083XXXX&amp;z=3D21=
3-XXXX

Western Digital fTf|=81[fgfz=81[f?fy=81[fW
  - http://websupport.wdc.com/rd.asp?t=3D105&amp;l=3Djp&amp;p=3Dh

^=C8=8F=E3=81A
WD RMA f`=81[f?
http://websupport.wdc.com/rd.asp?t=3D105&amp;l=3Djp&amp;p=3Dh
</pre>
<p>
ヘッダに「quoted-printable」と書いてあるとおり、
quoted-printable エンコーディングを行なったのだろうが、
のっけから「<tt>^=C8?=BA,=C9.\Z=A6,=B3,=EA,=BD</tt>」となっていて、
一体何語なんだ？と思わせる始まり方である。
</p>
<blockquote>
ちなみに quoted-printable というのは 8bit データを、
「印字可能 (printable)」つまり 7bit の英数字・記号だけで表現するための方法 
(エンコーディング) で、
印字可能でない 8bit データは 16進数で表わして前に「=」をつける
(「=」自身は「=3D」で表現する)。
例えば「<tt>^=C8?=BA,=C9.\Z=A6,=B3,=EA,=BD</tt>」は、
16進数で書くと
「<tt>5E C8 3F BA 2C C9 2E 5C 5A A6 2C B3 2C EA 2C BD</tt>」
という 8bit データ列を意味する。
</blockquote>
<p>
腕に覚えのあるかたは、解答を見ずに解読を試みてはいかがだろうか？
</p>
<a href="http://blog.gcd.org/archives/51206955.html">続きを読む</a>]]>
</content:encoded>
</item>
<item rdf:about="http://blog.gcd.org/archives/51205701.html">
<title>故障した HDD WD10EACS を RMA (Return Merchandise Authorization, 返却承認) 手続きで交換してみた</title>
<link>http://blog.gcd.org/archives/51205701.html</link>
<description>
廉価な 1TB SATA ハードディスク ドライブ (以下 HDD と略記) として有名な、
Western Digital 製 WD Caviar GP WD10EACS は、
省電力・静音を謳っている。
環境に優しいのは結構なことだが、
その実現方法:


IntelliPower - きめ細かく調整された　ディスク回転速...</description>
<dc:creator>hiroaki_sengoku</dc:creator>
<dc:date>2008-06-30T08:12:57+09:00</dc:date>
<dc:subject>ハードウェアの認識と制御</dc:subject>
<content:encoded><![CDATA[<p>
廉価な 1TB SATA ハードディスク ドライブ (以下 HDD と略記) として有名な、
Western Digital 製 <a href="http://www.wdc.com/jp/products/Products.asp?DriveID=336">WD Caviar GP WD10EACS</a> は、
省電力・静音を謳っている。
環境に優しいのは結構なことだが、
その実現方法:
</p>
<blockquote>
<b>IntelliPower</b> - きめ細かく調整された　ディスク回転速度　転送速度　及びキャッシュサイズの調和により飛躍的な省電力と確実なパフォーマンスを提供します<br />
<b>IntelliPark</b> - 風損を減らす為のアイドル時の自動ヘッド退避によりドライブは消費電力を低減する<br />
<b>IntelliSeek</b> - 電力消費量、ノイズおよび振動を低減させるために、最適なシーク速度を計算します。<br />
<div align="right"><a href="http://www.wdc.com/jp/company/greenpower.asp">GreenPower ハードドライブ</a> から引用</div>
</blockquote>
<p>
のうち、特に「アイドル時の自動ヘッド退避」というのがいただけない。
ヘッドを退避すれば空気抵抗が減ってモーターの負荷が減るから
低消費電力が実現できる (実際、アイドル時の消費電力は際立って低い)、
ということなのだろうが、
常時使用する PC (特にサーバ) だと「自動ヘッド退避」の回数が
とんでもないことになる。
SMART 情報を見ると:
</p>
<pre class="terminal">
# 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
	...
</pre>
<p>
わずか 3826 時間 (159日、約5ヶ月) で、
実に 11327回もの自動ヘッド退避が行なわれている。
</p>
<p>
この異常な回数の自動ヘッド退避が原因かどうかは分からないが、
この 1TB HDD は 2007年11月30日に 28140円で購入してから
わずか 5ヶ月余りの 2008年5月2日に故障した。
こんなに早く故障するとは思ってもいなかったので、
<a href="http://www.tzone.com/diy/topics/service/hdd.jsp#ai">T-Zone の延長保証</a>
(200円の追加で通常3ヶ月保証を最長6ヵ月保証) を掛けていなかった。
6ヶ月ではどーせ故障しないから保証を掛けるだけ無駄と判断したのだった
(ついでに言うと、6ヶ月では故障しないだろうと高を括っていて、
まだ一部バックアップしていないデータがあったので、
復旧にえらく手間取った。1TB もあると復旧も一筋縄にはいかない)。
</p>
<p>
運が悪かったとあきらめるしかない 
(二度とグリーン・パワー・ハードディスクは買わないぞっ！) と思っていたら、
RMA (Return Merchandise Authorization, 返却承認) という
メーカによる保証があるということを同僚から教えてもらった
(<a href="http://sengoku.blog.klab.org/archives/50936687.html">社内IRC</a> で 
HDD の故障を嘆いていたら、哀れに思って教えてくれたらしい ^^;)。
RMA番号を取得した上で故障品をメーカへ送ると、
代替品を送り返してくれる、という保証。
</p>
<blockquote>
ステップ3<br />
製品が故障していて交換が必要と判断された場合、
RMA タイプを下から選択して RMA（返却承認）手続きを開始してください。<br />
<br />
Standard Replacement<br />
お客様から故障製品を受け取ったあとに代替製品を送付します。
RMA が作成されてから30日以内に故障製品を返送してください。
<div align="right"><a href="http://websupport.wdc.com/warranty/rmainfo.asp?custtype=end&amp;lang=jp">エンドユーザー向け製品交換</a> から引用</div>
</blockquote>
<p>
Western Digital の 
<a href="http://websupport.wdc.com/warranty/serialinput.asp?custtype=end&amp;requesttype=warranty&amp;lang=jp">エンドユーザー向け保証確認</a>ページで、
故障した HDD のシリアル番号を入力してみると、
</p>
<div align="center">
<img src="http://www.gcd.org/sengoku/picts/WDC_RMA_02.jpg" alt="交換に適合するドライブ" width="387" height="394" />
</div>
<p>
おお、「限定保証期間内」と表示された。
有効期間は再来年の 12月まで、三年間もあるらしい。
もしかしたら交換してもらえるかも？と期待が膨らむ。
といっても RMA なんて今まであることすら知らなかったわけで、
どうやって故障品を送ったらいいのか見当もつかない。
</p>
<a href="http://blog.gcd.org/archives/51205701.html">続きを読む</a>]]>
</content:encoded>
</item>
<item rdf:about="http://blog.gcd.org/archives/51198587.html">
<title>HP ProLiant ML115 で、IPMI ハードウェア・ウォッチドッグ・タイマー ipmi_watchdog を使ってみる</title>
<link>http://blog.gcd.org/archives/51198587.html</link>
<description>
「ハードウェア・ウォッチドッグ・タイマー iTCO_wdt のススメ」へのリンクを張って頂いた:


HP ML115 には IPMI (Intelligent Platform Management Interface) という
便利なインターフェイスが内蔵されています。
... (中略) ...
IPMI 機能の一つ、watchdog timer...</description>
<dc:creator>hiroaki_sengoku</dc:creator>
<dc:date>2008-06-13T08:17:13+09:00</dc:date>
<dc:subject>ハードウェアの認識と制御</dc:subject>
<content:encoded><![CDATA[<p>
「<a href="http://blog.gcd.org/archives/51077399.html">ハードウェア・ウォッチドッグ・タイマー iTCO_wdt のススメ</a>」へのリンクを張って頂いた:
</p>
<blockquote>
HP ML115 には IPMI (Intelligent Platform Management Interface) という
便利なインターフェイスが内蔵されています。
... (中略) ...
IPMI 機能の一つ、watchdog timer 機能を利用してみようと思います。<br />
... (中略) ...<br />
watchdog timer の動作に関しては、
<a href="http://blog.gcd.org/archives/51077399.html">こちら</a>の方が
詳しいので興味ある方はご確認ください。
さて、どうやって watchdog を起こすかというと、
先ほどインストールしたドライバと ipmitool を利用します。
<div align="right"><a href="http://www10.big.or.jp/~and/gba/watchdog.html">Watchdog Timer / IPMItool (Jun 1,2008)</a> から引用</a></div>
</blockquote>
<p>
うっ、ML115 の IPMI には、
ウォッチドッグ・タイマーの機能もあったのか (何たる不覚 orz)。
今まで <a href="http://blog.gcd.org/archives/51156663.html">ML115</a> では、
<a href="http://blog.gcd.org/archives/50459506.html">ソフトウェア版ウォッチドッグ (softdog.ko モジュール)</a> を
使っていたので、
速攻で IPMI のハードウェア・ウォッチドッグ・タイマーに乗り換えてみた。
</p>
<p>
Linux カーネル・ソースの Documentation/IPMI.txt を見ると、
</p>
<pre class="code">
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=&lt;t> pretimeout=&lt;t> action=&lt;action type>
      preaction=&lt;preaction type> preop=&lt;preop type> start_now=x
      nowayout=x ifnum_to_use=n
</pre>
<p>
ブート時に「modprobe ipmi_watchdog」を実行するだけで使えそうである。
タイムアウトを「timeout=<tt>&lt;t></tt>」で指定できるが、
私のマシンでは「蹴り代行」デーモンを走らせている
(「<a href="http://blog.gcd.org/archives/51077399.html">ハードウェア・ウォッチドッグ・タイマー iTCO_wdt のススメ</a>」参照) ので、
デフォルトのタイムアウトである 10 秒のままでも問題無い。
</p>
<p>
「action=<tt>&lt;action type></tt>」には、タイムアウト時の挙動を指定する。
「reset」(ハードウェア・リセット)、
「power_cycle」(電源OFF してから電源ON)、
「power_off」(電源OFF) を指定できるが、
デフォルトは「reset」なので、これも指定しなくて構わない。
</p>
<p>
「nowayout=0」を指定すると、
/dev/watchdog をクローズ時にウォッチドッグ・タイマーが止まる。
ウォッチドッグ・タイマーは、
いったん動き出したら何が起ろうと止めるべきではないと思うし、
デフォルトは「nowayout=1」(つまりクローズしても止まらない) なので、
これも指定する必要はない。
</p>
<p>
というわけで、ipmi_watchdog を使ってみる:
</p>
<pre class="code">
# modprobe ipmi_watchdog
# echo @ > /dev/watchdog
</pre>
<p>
/dev/watchdog が存在しない場合は、「mknod /dev/watchdog c 10 130」を実行して、
/dev/watchdog を作成しておく。
</p>
<p>
10秒後、勝手にリセットがかかった (めでたしめでたし)。
リセットを防ぐには 10秒以内に /dev/watchdog へ書込み続けなければならない。
例えば、
</p>
<pre class="code">
#!/bin/sh
while true; do
    echo @ > /dev/watchdog
    sleep 5
done
</pre>
<p>
といったスクリプトを走らせ続ける。
このスクリプトだとシンプルすぎて、
システムに異常が起きたときも動き続けてしまう
(だからタイムアウトが発生しない) 恐れがあるので、
while ループの中にシステム異常を検知する 
(異常が起きたときは 10秒以上時間がかかる) ようなコマンドを入れておくとよい。
</p>
<p>
何かの都合でタイマーを止めたい (止めるべきではないが) ときは、
「V」を /dev/watchdog に書込む。
</p>
]]>
</content:encoded>
</item>
<item rdf:about="http://blog.gcd.org/archives/51184583.html">
<title>x86_64 な Linux カーネルで i386 プログラムを実行するときの注意点 ── ivtv ドライバの ioctl インタフェース
</title>
<link>http://blog.gcd.org/archives/51184583.html</link>
<description>
64bit Linux (x86_64 別名 amd64) は、
CONFIG_IA32_EMULATION を有効にしておくことにより、
32bit プログラム (i386 別名 ia32) を走らせることができる。
したがって 64bit へ移行する際は、
全プログラムを一度に 64bit 化する必要はなく、
まずカーネルだけ 64bi...</description>
<dc:creator>hiroaki_sengoku</dc:creator>
<dc:date>2008-05-12T09:12:42+09:00</dc:date>
<dc:subject>プログラミングと開発環境</dc:subject>
<content:encoded><![CDATA[<p>
64bit Linux (x86_64 別名 amd64) は、
CONFIG_IA32_EMULATION を有効にしておくことにより、
32bit プログラム (i386 別名 ia32) を走らせることができる。
したがって 64bit へ移行する際は、
全プログラムを一度に 64bit 化する必要はなく、
まずカーネルだけ 64bit 化しておいて、
各プログラムは (バージョンアップの機会などに) 徐々に 64bit 化していけばよい。
ただし 32bit プログラムがカーネルの機能を呼び出す場合は、
各機能それぞれが 32bit プログラムからの呼び出しに対応していることが前提となる。
</p>
<blockquote>
32bit プログラムからの呼び出しに対応するといっても、
基本的には引数の型を変換するだけである。
x86_64 の整数データモデルは LP64、
つまり long int 型とポインタ型が 64bit で
(引数の型として多用される) int型は 32bit のままなので、
変換が不要なケースも多い。
</blockquote>
<p>
例えば ioctl システムコールはファイル・ディスクリプタ 
(file descriptor, 以下 fd と略記) ごとに
カーネルが実行すべき機能は変わってくるわけで、
その実装は各デバイス・ドライバに委ねられることが多い。
したがって 32bit プログラムからの ioctl 呼び出しに応えられるか否かは、
各ドライバが 32bit 対応しているか否かに依存する。
不幸にしてドライバが対応していない場合は、
</p>
<pre class="code">
ioctl32(tv:11028): Unknown cmd fd(5) cmd(40045613){t:'V';sz:4} arg(081ec8b4) on /dev/video0
</pre>
<p>
などといったカーネル・メッセージ (dmesg) が出力される。
このメッセージは、
カーネル・ソース中 fs/compat_ioctl.c の compat_ioctl_error が出力している:
</p>
<pre class="code">
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) &amp; _IOC_SIZEMASK,
            (unsigned int)arg, fn);
    ...
}
</pre>
<p>
fs/compat_ioctl.c は 32bit 版 ioctl システムコールを実装していて、
32bit プログラムが ioctl システムコールを呼び出すと、
この中の compat_sys_ioctl ルーチンが呼ばれる:
</p>
<pre class="code">
asmlinkage long compat_sys_ioctl(unsigned int fd, unsigned int cmd,
                unsigned long arg)
{
    ...
        if (filp->f_op &amp;&amp; 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;
}
</pre>
<p>
つまりドライバ側で file 構造体の compat_ioctl 関数ポインタ
(filp->f_op->compat_ioctl) が定義されていればそれが呼ばれ、
未定義ならば上記のような「Unknown cmd」エラーが出力される。
</p>
<p>
ちなみにこのエラーメッセージの「tv:11028」は、
ioctl を呼び出した 32bit プロセスの名前 (コマンド名) とプロセスID であり、
fd(5), cmd(40045613), arg(081ec8b4) は、
それぞれ
ioctl システムコールの第一 (つまり fd 番号)、
第二 (ioctl リクエスト番号)、第三引数 (ioctl リクエストの引数) であり、
最後の on /dev/video0 は
(第一引数の) fd 番号に対応するファイルのパス名である。
</p>
<p>
そして、この tv コマンドは
「<a href="http://blog.gcd.org/archives/51172127.html">ビデオキャプチャ・カード GV-MVP/RX2W を使って Linux 2.6.24.4 でテレビ録画</a>」で紹介した
<a href="http://www.gcd.org/sengoku/docs/tv">perl スクリプト</a> であり、
その名称から推測できるとおりテレビ録画を行なうためのスクリプトである。
</p>
<p>
このスクリプトでは 
<a href="http://sourceforge.net/project/showfiles.php?group_id=73219">Video::ivtv モジュール</a>を利用していて、
このモジュールが /dev/video0 つまり TV キャプチャ・デバイスに対して、
ioctl システムコールを呼び出している。
上記エラーはスクリプト中 $IvTV->stopEncoding($TunerFD); 
を実行したときに発生した。
</p>
<p>
その名称から推測できる通り、
stopEncoding メソッドはキャプチャ・デバイスに対して
エンコーディングの停止を指示するためのもので、
内部で ioctl(fd, VIDIOC_STREAMOFF) などと
ioctl 呼び出しを行なっている。
VIDIOC_STREAMOFF は videodev2.h にて、
</p>
<pre class="code">
#define VIDIOC_STREAMOFF    _IOW  ('V', 19, int)
</pre>
<p>
と定義されていて、このマクロを展開すると 40045613 (16進) となり、
上記カーネル・メッセージ「cmd(40045613)」と一致する。
</p>
<p>
というわけで、(少なくとも Linux 2.6.24.7 に含まれる) ivtv ドライバは、
残念ながら 32bit 対応していないことが分かった。
もちろん x86_64 なカーネルではなく、
i386 カーネルを使えば 32bit プログラムから ivtv ドライバを使うことができるが、
x86_64 なカーネルでは、32bit プログラムからの ioctl システムコールを 
64bit カーネルが受付けられる形に変換できないということだ。
</p>
<p>
とはいうものの、
32bit だろうが 64bit だろうが 
ioctl のインタフェースに大した変わりはないはずだ。
どうして ivtv ドライバは 32bit 呼び出しをサポートしていないのだろう？ と
思いながらドライバのソースを眺めていると...
drivers/media/video/compat_ioctl32.c を見つけた。
名前からしていかにも 32bit 版 ioctl のように見える。
</p>
<p>
compat_ioctl32.c の中の v4l_compat_ioctl32 ルーチンは、
32bit な ioctl 呼び出しを受付けて
引数を 64bit へ変換し (といっても int 型はどちらも 32bit だが)、
本来の (64bit な) ioctl を呼び出し直す仕組みになっている。
なぜ ivtv ドライバは、このルーチンを利用していないのだろうか。
</p>
<pre class="code">
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) &amp;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;
}
</pre>
<p>
ざっと見た感じ、
ivtv ドライバからこの v4l_compat_ioctl32 ルーチンを呼んでも
特に問題は無いように思われる。
</p>
<p>
そこで、ivtv ドライバの file 構造体 (の中の file_operations 構造体) の
compat_ioctl 関数ポインタに、
v4l_compat_ioctl32 を設定してみた。
</p>
<pre class="code">
--- 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,
 };
</pre>
<p>
このパッチをあてることにより、
x86_64 なカーネル上で i386 な Video::ivtv モジュールを使って、
ビデオキャプチャ・カード GV-MVP/RX2W を
コントロールすることができるようになった。
一週間ほど使ってみた (多数の TV 番組を予約録画した) が、
今のところ問題は起きていない。
</p>
]]>
</content:encoded>
</item>
<item rdf:about="http://blog.gcd.org/archives/51172127.html">
<title>ビデオキャプチャ・カード GV-MVP/RX2W を使って Linux 2.6.24.4 でテレビ録画</title>
<link>http://blog.gcd.org/archives/51172127.html</link>
<description>
ついに Linux 2.6.24 で
I-O DATA 製 ハードウェア MPEG-2 エンコーダ搭載TVキャプチャボード
GV-MVP/RX2W (2006年7月5日生産終了)
が標準カーネルのままでテレビ視聴が可能になった。
もはやカーネルのバージョンを上げるたびにパッチを当て直す必要はない。
仕様が...</description>
<dc:creator>hiroaki_sengoku</dc:creator>
<dc:date>2008-04-15T07:57:34+09:00</dc:date>
<dc:subject>ハードウェアの認識と制御</dc:subject>
<content:encoded><![CDATA[<p>
ついに Linux 2.6.24 で
I-O DATA 製 ハードウェア MPEG-2 エンコーダ搭載TVキャプチャボード
<a href="http://www.iodata.jp/prod/multimedia/tv/2004/gv-mvprx2w/index.htm">GV-MVP/RX2W</a> (2006年7月5日生産終了)
が標準カーネルのままでテレビ視聴が可能になった。
もはやカーネルのバージョンを上げるたびにパッチを当て直す必要はない。
仕様が公開されていないハードウェアを解析してドライバを開発し、
それを標準カーネルにマージすべく働き掛けた方々の努力に敬意を表したい。
</p>
<p>
この TVキャプチャボードのおかげで、
私はリアルタイムでテレビを視聴する習慣を無くすことができた。
録画したものを見れば「飛ばし読み」や「斜め読み」が可能だし、
1TB のディスクに録りだめしておいて優先順位をつけて見ることもできる。
ニュースやスポーツ以外であれば放送日に見る必要はそもそもないし、
下らないと判明した時点で視聴を打ち切って
別の録画した番組を見るようにすれば、
駄作をだらだらと見続けて時間を無駄にすることもない。
</p>
<p>
この手のハードウェアは、
Linux などのオープンソースな OS で動いてこそ真価を発揮するのだと思う。
視聴方法は人によって様々であるから、
全てのユーザニーズを満たすような万能なソフトウェアを、
ハードウェアメーカが製品出荷時に開発することなど、
そもそも無理な話ではないのか？
</p>
<p>
ハードウェアメーカはドライバ (あるいはハードウェア仕様) の公開だけにとどめ、
ソフトウェアの開発は他者に任せてはどうか。
餅は餅屋というではないか。
一つの万能ソフトウェアより、
ニーズに応じて単機能なソフトウェアを使い分ける方が合理的だし、
さらに言えばどんな OS 上でそのソフトウェアが動いて欲しいかは、
ユーザによって異なるだろう。
</p>
<p>
例えば私の場合、
24時間365日、安定して録画し続けることが最優先であるし、
「使い易い」グラフィカルなユーザインタフェースよりは、
<a href="http://www.gcd.org/sengoku/docs/tv">perl スクリプト</a>から
自由にコントロールできることのほうが重要である。
私もノートPC では Windows VISTA を使用しているが、
録画サーバの OS に Windows を使う気にはなれない。
</p>
<p>
GV-MVP/RX2W は生産終了になって久しく、
後継の GV-MVP/RX3 や GV-MVP/GX2W はまだ Linux では使えないらしい
(はたして地上アナログ停波までに使えるようになるだろうか?)。
I/Oデータの製品は Linux で使えないことが多いので注意が必要だろう。
Windows のみ対応しているハードウェア製品だと、
サポートが打ち切られて Windows の新 OS に対応しなくなった段階で、
使うことができなくなってしまう
(サポート終了を理由に VISTA 対応版を出していないハードウェア製品は多い)。
もっとも、メーカ側からすると早く使えなくして、
新製品に買い換えてもらいたいのだろうが。
</p>
<p>
なお冒頭で「パッチを当て直す必要はない」と書いたが、
GV-MVP/RX2W には 
DeEmphasis (DEM) モードを設定すると常にモノラル音声になるという問題がある。
標準カーネルでは DEM ON がデフォルトになっているので、
Linux 2.6.24.4 に以下のパッチをあてて、
DEM OFF をデフォルトにしてみた。
このパッチをあてることにより、
デフォルトで二か国語/ステレオ放送の録画ができるようになる。
</p>
<pre class="code">
--- 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   |
</pre>
]]>
</content:encoded>
</item>
<item rdf:about="http://blog.gcd.org/archives/51168556.html">
<title>なぜ、「購入 VS 賃貸」 という比較がナンセンスなのか？</title>
<link>http://blog.gcd.org/archives/51168556.html</link>
<description>
分譲マンション (あるいは一戸建) を (ローンで) 購入するのと、
賃貸マンションを借りる (賃借) のと、どちらが得か？
という比較の話をよく聞く。
大抵は、ケース・バイ・ケースで片付けてしまうか、
「購入派 VS 賃貸派」などと個人の価値観に帰着させてしまうこと...</description>
<dc:creator>hiroaki_sengoku</dc:creator>
<dc:date>2008-04-07T08:30:51+09:00</dc:date>
<dc:subject>自己啓発</dc:subject>
<content:encoded><![CDATA[<p>
分譲マンション (あるいは一戸建) を (ローンで) 購入するのと、
賃貸マンションを借りる (賃借) のと、どちらが得か？
という比較の話をよく聞く。
大抵は、ケース・バイ・ケースで片付けてしまうか、
「購入派 VS 賃貸派」などと個人の価値観に帰着させてしまうことが
多いようである。
例えば、
「ローンも家賃も月々の支払いは似たようなものであるが、
購入の場合はローンを完済すれば資産になるのに対し、
借りる場合は家賃を永遠に払い続けなければならない。
一方、
購入の場合は地価が下がったり住環境の変化などのリスク要因もあるから、
購入が得とも限らない」等々...
</p>
<p>
本当に、ケース・バイ・ケースあるいは価値観の問題なのだろうか？
</p>
<p>
まず注意しておきたいのは、
「購入」と「賃借」は、対立概念ではないということ。
当たり前の話だが、
「購入」の反対は「売却」であり、
「賃借」の反対は「賃貸」である。
マンションを購入しても、
必ずしもそこに住まなければならないわけではない
(税制などを考えれば住む方が得であるケースも多いが)。
購入するにしても借りるにしても、
どこかに「住む」はずであるから、
共通部分である「住む」は除外して比較を行なうべきであろう。
</p>
<p>
どうやって「住む」を除外したらよいか？
</p>
<p>
マンションを購入して (他者に賃貸するのではなく) 自らそこに住む場合、
自分自身に対して「賃貸」したと考えればよい。
つまり「賃借人」である自分が、「大家」である自分に家賃を払ってそこに住む、
と考えるわけである。
このように考えれば、
「自宅としてマンションを買う」という行為は、
「マンションを買って (自分自身に) 賃貸」という行為 (つまり不動産投資) と、
「マンションを賃借して住む」という行為に分解できる。
</p>
<table>
<tr><td>買う</td><td>　⇒　</td><td>不動産投資 + (自分から)賃借して住む</td></tr>
<tr><td>借りる</td><td>　⇒　</td><td>(他人から)賃借して住む</td></tr>
</table>
<p>
このように考えれば、
「賃借して住む」の部分は両者に共通であるから除外して比較することができる。
</p>
<p>
つまり「買うか？ 借りるか？」という比較は、<br />
「不動産投資を行なうか？ 行なわないか？」という比較になる。
</p>
<blockquote>
4000万円の新築マンションを購入するとして、
頭金を800万円（購入価格の2割）、
残り3200万円を金利3％、
35年返済で借りるとした場合、
月々の返済額は12万3000円となる。
頭金800万円を加えた総返済額は約5970万円。
これに固定資産税、維持管理費等の支払いが約1700万円。
結局7670万円の支払いをして、マンションが自分の資産となるわけである。
<div align="right"><a href="http://allabout.co.jp/house/mansionbeginner/closeup/CU20010120A/">購入ＶＳ賃貸　どっちが得か？</a></div>
</blockquote>
<p>
ここで、
(自分自身に) 月額 12万3000円の家賃で賃貸すると考える。
もちろん家賃の額は任意に設定して構わないのであるが、
ここでは簡単化のため、
家賃をローンの月々の返済額と同額の 12万3000円に設定してみる。
</p>
<blockquote>
4/19追記: 任意に設定して構わないといっても、
賃借人としての自分が「払ってもよい」と思える額であることが大前提である。
どーせ自分自身に払うのだからいくら高くても懐は痛まない、
などと考えてはいけない。
月々のローン返済額と同程度の家賃を払うくらいなら購入したほうがお得
(つまり 12万3000円以上だと払いたくない)、
と考える人が多数派であるようなので、
設定する家賃は月額 12万3000円を上限とすべきだろう。
</blockquote>
<p>
すると、賃借人 (つまり自分) から払ってもらった家賃を、
そのままローンの支払いにあてることができて、
固定資産税と維持管理費等の支払いだけでマンションが自分の資産になるわけである。
つまり「大家」としての自分は、
頭金800万円と固定資産税と維持管理費等の1700万円の合計 2500万円だけで、
(35年後には) 4000万円のマンションを手にいれることができる。
</p>
<p>
おいしい話のように聞こえるだろうか？
</p>
<p>
もしこの話がおいしい話に聞こえるなら、
マンションは購入すべきという結論になるわけだが、
よく考えてみて欲しい。
まず、 35年後に 4000万円の価値をもっているかどうかは、
そのときのマンション相場次第である。
</p>
<blockquote>
ここで考慮しなければならないのは、
「果たして地価が今後どのように変動していくか」である。
地価が毎年上昇し続ければマンションの資産価値も上がり続けるので問題ないが、
今の景気を考えると地価の上昇はしばらく期待できず
「地価はもう上がらない」という意見が多い。
正直そのあたりが誰にも明言できないところに
「買うか？借りるか？」の議論がいつの時代もされ、
結局「どっちなの？」に終始してしまうのである。
<br />
ここで地価が変動しないと仮定すると、35年後の資産価値は2510万円となる。
<div align="right"><a href="http://allabout.co.jp/house/mansionbeginner/closeup/CU20010120A/">同ページから引用</a></div>
</blockquote>
<p>
地価が変動しないと仮定すると、この話は
「頭金800万円と固定資産税と維持管理費等の1700万円の合計 2500万円で、
(35年後には) 2510万円の資産価値を持つマンションが手にはいる」
という話に変質してしまう。
</p>
<p>
おいしいと思えた話に影が差してこないだろうか？
</p>
<p>
とはいえ、
2510万円の資産価値を持つマンションが (35年後とはいえ) 手に入るのだし、
もしかしたら地価が上昇してマンション相場が大幅に値上がりするかも知れない。
先行きが見えない株に投資するよりは、
大化けするかもしれない「不動産」に投資したい、
と判断する人もいるかもしれない。
</p>
<blockquote>
賃貸の場合は頭金800万円と税金等の1700万円も不要なので、
購入しなければ2500万円の現金資産が残り、
結局は地価が変動しなければどちらも同じなのである。
<div align="right"><a href="http://allabout.co.jp/house/mansionbeginner/closeup/CU20010120A/">同ページから引用</a></div>
</blockquote>
<p>
「結局は地価が変動しなければどちらも同じ」だから、
ケース・バイ・ケースあるいは価値観の問題ということなのだろうか？
</p>
<p>
実はそうはならない。
</p>
<p>
なぜなら、
「頭金800万円と固定資産税と維持管理費等の1700万円の合計 2500万円で、
(35年後には) 2510万円の資産価値を持つマンションが手にはいる」
という理解は間違っているからだ。
</p>
<p>
支払額が合計 2500万円と思った人は、
800万円を (例えば) 銀行に預けておけば、
(低金利の昨今とはいえ) 35年もたてばそれなりの利息がつくということを忘れている。
毎年払い続ける固定資産税と維持管理費等だって、
総額 1700万円も払うわけだから、
同じ金額を 35年間もかけて積み立てていけば
利息が加算されて 1700万円を大きく上回る額になる。
</p>
<p>
不動産投資を行なうか、行なわないか、という比較をするのであれば、
不動産投資を行なわない場合に
同じ元手 (総額 2500万円) を
他の投資先へ振り向けた時の収益を含めて考慮しなければ、
フェアな比較とは言えないだろう。
他への投資でどのくらいの利回りが期待できるかは投資先に依存するが、
ここでは簡単化のため、
(ローン金利と同率の) 3% の利回りが期待できると仮定してみる。
</p>
<p>
最初に 800万円を投資し、
1500万円を毎年均等に (つまり毎年 49万円ずつ) 追加投資して、
3% の利回りがあると仮定すると、
35年で 5214万円にもなる。
</p>
<p>
つまり、
</p>
<blockquote>
新築価格が 4000万円のマンションを 35年ローンで買ってもいいのは、<br />
ローン完済時に 5214万円以上で売却することが期待できる場合に限られる。
</blockquote>
<p>
「土地神話」が崩れた今、
マンションを買うという行為は、
「投資」以外のなにものでもない。
そして、
「個人の投資は必ず余裕資金ですべき」という鉄則は
なにも「株投資」の場合だけに当てはまるものではなく、
どんな投資についても当てはまる金言である。
</p>
<p>
結構な高金利で借金して得たお金で投資する人がいたらどう思うだろうか？
「借金して得たお金」というのは
「余裕資金」から最もかけ離れた資金と言えるだろう。
そんな投資はやめておけ、と誰しも思うのではなかろうか？
</p>
<p>
しかしながら多くの人が行なっている
「ローン組んでマンションを買う」という行為は、
「借金して得たお金で投資する」という行為となんら変わらないのである。
</p>

<a href="http://blog.gcd.org/archives/51168556.html">続きを読む</a>]]>
</content:encoded>
</item>
<item rdf:about="http://blog.gcd.org/archives/51165789.html">
<title>4月1日に「仙石浩明CTO の日記」に掲載した記事の全文引用</title>
<link>http://blog.gcd.org/archives/51165789.html</link>
<description>
以下は、2008年4月1日 0:00 に 仙石浩明CTO の日記 にて公開した記事ですが、
4月1日限定公開なので、4月1日のうちにこちらへ全文引用しておきます。


～ 引用ここから ～


本日4月1日、KLabエージェント株式会社を設立しました

本日4月1日、KLab株式会社の 
...</description>
<dc:creator>hiroaki_sengoku</dc:creator>
<dc:date>2008-04-01T18:00:09+09:00</dc:date>
<dc:subject>技術者の成長</dc:subject>
<content:encoded><![CDATA[<p>
以下は、2008年4月1日 0:00 に <a href="http://sengoku.blog.klab.org/">仙石浩明CTO の日記</a> にて公開した記事ですが、<br />
4月1日限定公開なので、4月1日のうちにこちらへ全文引用しておきます。
</p>
<div align="center">
～ 引用ここから ～
</div>
<hr />
<h2>本日4月1日、KLabエージェント株式会社を設立しました</h2>
<p>
本日4月1日、<a href="http://www.klab.org">KLab株式会社</a>の 
100% 子会社として、<br />
KLabエージェント株式会社を設立いたしました。
</p>
<p>
<a href="http://dsas.blog.klab.org/">DSAS開発者の部屋</a>を見て、
「<a href="http://dsas.blog.klab.org/archives/50946231.html">いっしょにDSASをつくりたい</a>」と言ってくださるかたは、
おかげさまで徐々にですが増えつつあります。
技術が心の底から好きで、
自身のスキルを最大限伸ばすにはどんな会社がいいのか真剣に考え、
そして KLab が考える
「<a href="http://sengoku.blog.klab.org/archives/53861672.html">技術者の成長にとって一番役に立つ会社</a>」に共感して頂けるかたには、
ぜひ仲間になって頂きたいですし、
そういった方々に応募していただけるのは大変ありがたいことです。
</p>
<p>
<b>ところが！</b>
</p>
<p>
<a href="http://dsas.blog.klab.org/">DSAS開発者の部屋</a>を見て、
DSAS開発者と一緒に働きたいと希望していながら、
何を血迷ったか (失礼)、
転職斡旋会社に KLab への転職を依頼するかたが、
少なからずいらっしゃいます。
</p>
<p>
一般論でいえば、
転職斡旋会社 (正式名称で言えば、職業紹介会社) に求職者が登録するのは、
どの会社が自分に適しているか探しきれないから、ですよね？
世の中には星の数ほど会社があり、
個人の力では自分に適した会社を探しきれないからこそ、
職業紹介会社の存在意義があるわけです。
</p>
<p>
すでに転職したい会社が決まっているなら、
その会社に直接応募したほうが話が早いですし、
「<a href="http://blog.gcd.org/archives/50984831.html">転職エージェントは、誰の『エージェント』なのか？</a>」ということを考えれば、
実は「話が早い」どころではないことが分かるはずだと思うのです。
したがって、
転職したい会社が決まっているのに転職エージェントを利用するというのは、
百害あって一利無し (暴言) であるはずなのですが、
私ごときには推し量ることができない、
海よりも深い理由が応募者にはきっとあるのでしょう。
</p>
<p>
そこで、一計を案じました。
KLab に直接応募するのをためらっている人のために、
KLab への転職を斡旋する会社を作ろう。
名付けて「<a href="http://www.KLabAgent.jp/">KLabエージェント株式会社</a>」。
もちろん、職業安定法が定める有料職業紹介事業者
(求人企業から斡旋料を頂くので、求職者は無料) ですから、
KLab 以外の求人企業への<a href="http://www.mhlw.go.jp/general/seido/anteikyoku/jukyu/syoukai/index.html">職業紹介</a>も行ないますが、
一番の強みはもちろん KLab への転職斡旋が最速であること。
なんたってオフィスが KLab 内にありますから、
採用面接のスケジュール調整から待遇等の条件交渉まで一気通貫、
応募者にとって最も有利な KLab への転職をお約束します。
</p>
<p>
登録は、
<a href="mailto:recruit@KLabAgent.jp">担当者宛に直接メール</a>で
今すぐ! お申し込み下さい。
</p>

<div align="right">
<a href="http://www.KLabAgent.jp/">KLabエージェント株式会社</a><br />
代表取締役 CEO &amp; CTO<br />
&amp; 職業紹介責任者<br />
仙石浩明
</div>
<hr />
<div align="center">
～ 引用ここまで ～
</div>
]]>
</content:encoded>
</item>
<item rdf:about="http://blog.gcd.org/archives/51159342.html">
<title>フレッツ・ドットネットを解約したら、フレッツ網 router へ ping6 できなくなった！</title>
<link>http://blog.gcd.org/archives/51159342.html</link>
<description>
昨年12月26日に、
NTT東日本から
「BフレッツにおけるＩＰｖ６映像視聴等機能の標準装備について」
というお知らせが来た。
3月3日より、
「Bフレッツ」に IPv6 映像視聴等機能を標準装備するので、
フレッツ・ドット・ネットの契約が不要になるとのこと。


現在...</description>
<dc:creator>hiroaki_sengoku</dc:creator>
<dc:date>2008-03-19T15:32:29+09:00</dc:date>
<dc:subject>システム構築・運用</dc:subject>
<content:encoded><![CDATA[<p>
昨年12月26日に、
NTT東日本から
「BフレッツにおけるＩＰｖ６映像視聴等機能の標準装備について」
というお知らせが来た。
3月3日より、
「Bフレッツ」に IPv6 映像視聴等機能を標準装備するので、
フレッツ・ドット・ネットの契約が不要になるとのこと。
</p>
<blockquote>
現在、ＩＰｖ６映像視聴等機能は「フレッツ・ドットネット」にて
提供しておりますが、
平成２０年３月３日（月）以降は、
ブロードバンド映像サービスのみ をご利用の場合は、
「フレッツ・ドットネット」のご契約が不要になります。
これにより解約を希望されるお客さまにつきましては、
平成２０年３月３日（月） より※３受付を開始いたします。
　なお、ブロードバンド映像サービス以外で、
「FdNネーム」「FdNディスク」「FdNディスクビューセレクト」「FdNナンバー」等
「フレッツ・ドットネット」サービス※４をご利用の際には、
引き続き「フレッツ・ドットネット」のご契約が必要となりますのでご注意ください。 
</blockquote>
<p>
私は IPv6 機能のためだけに「フレッツ・ドットネット」を契約していて、
「FdNネーム」「FdNディスク」「FdNディスクビューセレクト」「FdNナンバー」等の
サービスを利用したことはない
(「ブロードバンド映像サービス」も利用していない)
ので、
<a href="http://www.flets/">フレッツ・スクウェア</a>トップから、
サービス申込受付を選んで、「フレッツ・ドットネット」を解約した。
</p>
<p>
<b>ところが！</b>
</p>
<p>
フレッツ網側の v6 ルータが ping に反応しなくなった。
</p>
<pre class="terminal">
senri % ping6 -n router.flets.gcd.org
PING router.flets.gcd.org(2001:c90:XXXX:XXXX:2d0:2bff:fe30:b91a) 56 data bytes
From 2001:c90:XXXX:XXXX:2d0:2bff:fe30:b91a icmp_seq=1 Destination unreachable: Administratively prohibited
From 2001:c90:XXXX:XXXX:2d0:2bff:fe30:b91a icmp_seq=2 Destination unreachable: Administratively prohibited

--- router.flets.gcd.org ping statistics ---
2 packets transmitted, 0 received, +2 errors, 100% packet loss, time 1000ms
</pre>
<p>
ちなみに、
この v6 ルータからの router advertisement は正常に流れてきている:
</p>
<pre class="terminal">
senri # tcpdump -i eth1 -vvv ip6
tcpdump: listening on eth1, link-type EN10MB (Ethernet), capture size 96 bytes
	...
13:02:02.904899 fe80::2d0:2bff:fe30:b91a > ff02::1: icmp6: router advertisement(chlim=64, pref=medium, router_ltime=1800, reachable_time=0, retrans_time=0)(src lladdr: 00:d0:2b:30:b9:1a)(mtu: mtu=1500)[ndp opt] [class 0xe0] (len 64, hlim 255)
</pre>
<p>
v6 ルータ越えの通信が全て禁止されてしまったらしく、
フレッツ網に接続している他サイトとの IPv6 通信も同様に禁止されて 
(Administratively prohibited) しまった。
例外は、<a href="http://flets-v6.jp">フレッツ・スクウェアv6</a> へのアクセス:
</p>
<pre class="terminal">
senri % ping6 -n flets-v6.jp
PING flets-v6.jp(2001:c90:ff:1::1) 56 data bytes
64 bytes from 2001:c90:ff:1::1: icmp_seq=1 ttl=52 time=5.05 ms
64 bytes from 2001:c90:ff:1::1: icmp_seq=2 ttl=52 time=4.55 ms

--- flets-v6.jp ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1001ms
rtt min/avg/max/mdev = 4.554/4.803/5.053/0.258 ms
</pre>
<p>
おそらく「ブロードバンド映像サービス」を提供するサーバへの IPv6 通信も
許可されているのだろう。
つまり、
「ＢフレッツにＩＰｖ６映像視聴等機能を標準装備」
という NTT東日本の発表のココロは、
IPv6 映像サービスへの IPv6 通信＊のみ＊許可するということであって、
それ以外の IPv6 通信は対象外ということのようだ。
</p>
<p>
<a href="http://www.ntt-east.co.jp/release/0712/071226a_2.html">「フレッツ・ドットネット」サービスの概要</a>には、
「フレッツ・ドットネットサービス機能一覧」として、
</p>
<blockquote>
・FdNネームが1つ利用できます。<br />
・FdNディスク(100MB)で、ファイル共有が利用できます。<br />
・FdNディスク(100MB)には、最大10のグループメンバーを登録できます。<br />
※NTT東日本が無料で提供する専用ソフトウェア「FLET'S.Netメッセンジャーにより、
ファイル転送やビデオチャットが利用できます。
</blockquote>
<p>
が列挙されているのみであって、
IPv6 通信の許可/不許可について言及していないのは、
とてもミスリーディングな記述だと思う。
</p>
<p>
慌てて再度フレッツ・ドットネット契約を
(<a href="http://www.flets/">フレッツ・スクウェア</a>で) 申込むと、
10分ほどで再び IPv6 通信ができるようになった:
</p>
<pre class="terminal">
senri % ping6 -n router.flets.gcd.org
PING router.flets.gcd.org(2001:c90:XXXX:XXXX:2d0:2bff:fe30:b91a) 56 data bytes
64 bytes from 2001:c90:XXXX:XXXX:2d0:2bff:fe30:b91a: icmp_seq=1 ttl=64 time=3.11 ms
64 bytes from 2001:c90:XXXX:XXXX:2d0:2bff:fe30:b91a: icmp_seq=2 ttl=64 time=0.920 ms

--- router.flets.gcd.org ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1001ms
rtt min/avg/max/mdev = 0.920/2.019/3.118/1.099 ms
</pre>
<p>
フレッツ網を経由した IPv6 通信を利用しているかたは、
たとえフレッツ・ドットネットサービスを利用していなくても、
フレッツ・ドットネットを解約すべきではないので、
ご注意のほどを！
</p>
]]>
</content:encoded>
</item>
<item rdf:about="http://blog.gcd.org/archives/51156663.html">
<title>HP ProLiant ML115 と DELL PowerEdge SC440 を買ってみた</title>
<link>http://blog.gcd.org/archives/51156663.html</link>
<description>
HP と DELL がエントリ・サーバ (タワー型) のキャンペーン販売を行なっていたので、
試しに買ってみた。
どちらも 2万円以下。




    HP ProLiant ML115
    DELL PowerEdge SC440
価格
    15,750円 (21,000円割引)
    19,800円 (46,875円割引)
プロセッ...</description>
<dc:creator>hiroaki_sengoku</dc:creator>
<dc:date>2008-03-14T08:27:29+09:00</dc:date>
<dc:subject>ハードウェアの認識と制御</dc:subject>
<content:encoded><![CDATA[<p>
HP と DELL がエントリ・サーバ (タワー型) のキャンペーン販売を行なっていたので、
試しに買ってみた。
どちらも 2万円以下。
</p>

<table align="center" class="ruler">
<tr><th></th>
    <th>HP <a href="http://h50146.www5.hp.com/products/servers/proliant/ml115/">ProLiant ML115</a></th>
    <th>DELL <a href="http://www1.jp.dell.com/content/products/features.aspx/pedge_sc440_rs">PowerEdge SC440</a></th></tr>
<tr><td>価格</td>
    <td>15,750円 (21,000円割引)</td>
    <td>19,800円 (46,875円割引)</td></tr>
<tr><td>プロセッサ</td>
    <td>AMD Athlon 3500+</td>
    <td>Pentium Dual-Core E2180</td></tr>
<tr><td>チップセット</td>
    <td>nVidia MCP55S Pro</td>
    <td>Intel 3000</td></tr>
<tr><td>グラフィック</td>
    <td>Matrox G200e (ServerEngines)</td>
    <td>ATI ES1000</td></tr>
<tr><td>メモリ</td>
    <td colspan=2>PC2-5300 ECC Unbuffered DDR2 SDRAM 512MB</td></tr>

<tr><td>HDD</td>
    <td colspan=2>80GB SATA 7200rpm</td></tr>
<tr><td>光学ドライブ</td>
    <td>TSSTcorp CD-ROM TS-H192C</td>
    <td>TSSTcorp DVD-ROM TS-H352C</td></tr>
</table>

<p>
PowerEdge というと (ラック・マウント型の) 爆音サーバのイメージが強かったので、
自宅で 24時間通電は難しいのではないかと思っていたのだが、
普通のデスクトップPC 並に静かで驚いた。
ProLiant のほうは、爆音というほどではないがそれなりにファンの音がする。
</p>
<p>
ProLiant ML115 は、
ビデオ・メモリが 2MB しかなくて画面の解像度の限界が 1024x768 16bit だったり、
光学ドライブが DVD でなかったり、
PCI が 3.3V 専用だったりと、
デスクトップPC として使うには少々難がある
(もちろんサーバとして使う場合は問題無い)。
</p>
<p>
それに比べると PowerEdge SC440 は、
デスクトップPC としても使える。
手持ちのサウンド・カード Vortex2 SQ2500 
(5V PCI なので ProLiant ML115 では使用不可) を差して 
Ubuntu をインストールしてみた。
ただし、DRI (Direct Rendering Infrastructure) は使えないので、
ビデオ再生などには向かない。
</p>
<p>
また、PowerEdge SC440 は
ECC 付メモリしか使えないので、
安価なメモリを使いたい場合は不便。
一方 ProLiant ML115 はECC 無しメモリも利用できるので、
私は ProLiant ML115 の 512MB ECC 付 DDR2/667 メモリを
PowerEdge SC440 へ移し、
ProLiant ML115 には、
4800円で購入した KINGBOX 1GB ECC 無し DDR2/800 2枚組を差して使っている。
</p>
]]>
</content:encoded>
</item>
<item rdf:about="http://blog.gcd.org/archives/51134879.html">
<title>リモートの p0f (passive fingerprinting) の結果を参照してスパム対策を行なう</title>
<link>http://blog.gcd.org/archives/51134879.html</link>
<description>
p0f は、
通信相手の OS を受動的に特定するツールで、
迷惑メール送信などの
スパム行為を行なう「敵」を知る手段として有用である。
例えば、もし (あくまで仮定の話だが) 受信するメールのほとんどすべてが 
Linux や FreeBSD などの UNIX 系サーバから送信される...</description>
<dc:creator>hiroaki_sengoku</dc:creator>
<dc:date>2008-01-31T08:55:19+09:00</dc:date>
<dc:subject>システム構築・運用</dc:subject>
<content:encoded><![CDATA[<p>
<a href="http://lcamtuf.coredump.cx/p0f.shtml">p0f</a> は、
通信相手の OS を受動的に特定するツールで、
迷惑メール送信などの
<a href="http://itpro.nikkeibp.co.jp/members/ITPro/SEC_CHECK/20020125/1/">スパム行為を行なう「敵」を知る</a>手段として有用である。
例えば、もし (あくまで仮定の話だが) 受信するメールのほとんどすべてが 
Linux や FreeBSD などの UNIX 系サーバから送信されるメールであって、
Windows マシンから送られてきたメールのほとんどすべてが迷惑メールであったなら、
Windows マシンからのメールを排除するという対策は合理的なものとなるだろう。
</p>
<blockquote>
もちろん、Windows を使ってマトモなメールを送ってくるケースもあるだろうから、
Windows から送られたメールを全て排除するのは現実的ではないが、
p0f での判定結果と、
その他の手段 
(例えば<a href="http://blog.gcd.org/archives/50742935.html">送信元 IP アドレス</a>) 
での判定結果を組合わせて
迷惑メールであるか否かの判断を行なえば、
より精度の高い迷惑メール排除が可能になる。
</blockquote>
<p>
ところが、
p0f は通信相手から送られてくる IP パケットを元に、
通信相手の OS を特定するツールであるから、
間にファイアウォールや NAT (IPアドレス・ポート変換) を行なう機器があると、
通信相手ではなくファイアウォールや NAT について調べてしまう。
だから、メールを受信するサーバがファイアウォールの内側にある場合は、
意味ある結果が得られないし、
外側にある場合だとメールを受信するサーバとは別の場所 
(つまりファイアウォールの内側) で
スパム判定を行ないたくなるものだろう。
例えばメールサーバは DMZ 上にあるが、
迷惑メール判定は LAN 内のマシンで行ないたい場合など。
</p>
<p>
<a href="http://www.gcd.org/Welcome.ja.html">私の個人サイト GCD</a> は、
b フレッツに PPPoE 接続している。
p0f は調べる通信のインタフェース名を -i オプションで指定する必要があるが、
(1) PPPoE だからインタフェース名 (ppp0～) が変わることがある。
また、
PPPoE を行なうゲートウェイマシンは二台ある (冗長構成) ので、
(2) アクティブ側で p0f を実行しないと意味がない。
さらに、
メールサーバは (メールボックスを一ヶ所にまとめたかったので) 一台だけであり、
(3) 異なるサーバ上 (アクティブ側のゲートウェイ) で動いている p0f の結果を
メールサーバから参照しなければならない。
</p>
<p>
以上 (1) ～ (3) の 3点を満たすための構成を考えてみた。
</p>
<p>
まず (1) と (2) は、pppd の ip-up スクリプトから p0f を実行すればよい。
例えば、ip-up で
</p>
<pre class="code">
command=$0
interface=$1
	...
case $command in
    *ip-up)
	p0f -i $interface -Q /var/run/p0f-sock \
	    'port 25 and (not src net 192.168.0.0/16)' \
	    -u stone -d -t -o /var/log/p0f.log
	;;
    *ip-down)
	killall p0f
	;;
esac
</pre>
<p>
などと p0f を起動し、ip-down で p0f を終了させる。
これでアクティブ側のゲートウェイ上でのみ p0f が動く。
</p>
<p>
p0f による判定結果は、
p0f の -Q オプションで指定した UNIX ドメイン・ソケット
(上記の例では、 /var/run/p0f-sock) を介して
問合わせることができるが、
UNIX ドメイン・ソケットなので当然のことながら
別のマシンからは問合わせることができない。
そこで <a href="http://www.gcd.org/sengoku/stone/Welcome.ja.html">stone</a>
に転送させる:
</p>
<pre class="code">
stone /var/run/p0f-sock 12345 &amp;
</pre>
<p>
アクティブ側のゲートウェイは、
仮想ルータの IP アドレス 192.168.1.1 を持っているので、
「192.168.1.1:12345」へアクセスすれば、
それを stone が /var/run/p0f-sock へ中継してくれるので、
(3) p0f の結果を参照できる。
</p>
<p>
p0f の結果を参照するサンプルプログラムとして、
p0f には perl で書かれた p0fq.pl と、
C で書かれた p0fq.c が付属しているが、
あいにくどちらも UNIX ドメイン・ソケットにしか対応していない (当たり前)。
ちょっといじってリモート上の p0f へ 
(stone 経由で) アクセスできるようにしてみる。
</p>
<p>
p0fq.pl へのパッチ:
</p>
<pre class="code">
--- test/p0fq.pl.org	2006-08-21 23:11:10.000000000 +0900
+++ test/p0fq.pl	2008-01-31 08:00:14.652880068 +0900
@@ -30,8 +30,14 @@
                  $src->intip(), $dst->intip(), $ARGV[2], $ARGV[4]);
 
 # Open the connection to p0f
-my $sock = new IO::Socket::UNIX (Peer => $ARGV[0],
+my $sock;
+if ($ARGV[0] =~ /^[\-\w]+:\d+$/) {
+    $sock = new IO::Socket::INET (PeerAddr => $ARGV[0],
                                  Type => SOCK_STREAM);
+} else {
+    $sock = new IO::Socket::UNIX (Peer => $ARGV[0],
+				  Type => SOCK_STREAM);
+}
 die "Could not create socket: $!\n" unless $sock;
 
 # Ask p0f
</pre>
<p>
「IO::Socket::UNIX」を「IO::Socket::INET」に変更するだけで済む。
</p>
<p>
p0fq.c へのパッチ:
</p>
<pre class="code">
--- test/p0fq.c.org	2006-08-21 21:29:49.000000000 +0900
+++ test/p0fq.c	2008-01-31 08:05:55.499326450 +0900
@@ -16,6 +16,7 @@
 
 #include &lt;sys/types.h>
 #include &lt;sys/socket.h>
+#include &lt;netdb.h>
 #include &lt;stdio.h>
 #include &lt;stdlib.h>
 #include &lt;unistd.h>
@@ -40,6 +41,7 @@
   struct p0f_response r;
   _u32 s,d,sp,dp;
   _s32 sock;
+  char *str;
   
   if (argc != 6) {
     debug("Usage: %s p0f_socket src_ip src_port dst_ip dst_port\n",
@@ -55,12 +57,37 @@
   if (!sp || !dp || s == INADDR_NONE || d == INADDR_NONE)
     fatal("Bad IP/port values.\n");
 
+  if ((str=strchr(argv[1], ':'))) {
+    struct addrinfo *ai = NULL;
+    struct addrinfo hint;
+    int err;
+    *str++ = '\0';
+    hint.ai_flags = 0;
+    hint.ai_family = AF_INET;
+    hint.ai_socktype = SOCK_STREAM;
+    hint.ai_protocol = IPPROTO_TCP;
+    hint.ai_addrlen = 0;
+    hint.ai_addr = NULL;
+    hint.ai_canonname = NULL;
+    hint.ai_next = NULL;
+    err = getaddrinfo(argv[1], str, &amp;hint, &amp;ai);
+    if (err) {
+      if (err == EAI_SYSTEM) pfatal("getaddrinfo");
+      else fatal("getaddrinfo(%s,%s): %s\n",
+		 argv[1], str, gai_strerror(err));
+    }
+    memcpy(&amp;x, ai->ai_addr, ai->ai_addrlen);
+    sock = socket(ai->ai_family, ai->ai_socktype, ai->ai_protocol);
+    freeaddrinfo(ai);
+    if (sock &lt; 0) pfatal("socket");
+  } else {
   sock = socket(PF_UNIX,SOCK_STREAM,0);
   if (sock &lt; 0) pfatal("socket");
 
   memset(&amp;x,0,sizeof(x));
   x.sun_family=AF_UNIX;
   strncpy(x.sun_path,argv[1],63);
+  }
 
   if (connect(sock,(struct sockaddr*)&amp;x,sizeof(x)))  pfatal(argv[1]);
 
</pre>
<p>
getaddrinfo を呼び出すための準備に行数を費やしているので
複雑に見えるかも知れないが、
本質は プロトコル・ファミリ (protocol family) を 
AF_UNIX から AF_INET に変更しただけである。
</p>
<p>
(p0f を実行しているマシンとは異なるマシン上で) p0fq を実行してみる:
</p>
<pre class="code">
% p0fq 192.168.1.1:12345 81.36.137.136 2943 60.32.85.220 25
Genre    : Windows
Details  : 2000 SP4, XP SP1+
Distance : 21 hops
Link     : pppoe (DSL)
</pre>
<p>
上記は、
メール送信元 (81.36.137.136 のポート 2943番) が
GCD の MX (60.32.85.220 のポート 25番) へメールを送ってきた通信の
p0f による判定結果。
メールサーバで、
メールヘッダにメール送信元のポート番号も出力するようにしておけば、
メールを受信するユーザが自前のメール振り分けプログラム (procmail など) を使って
p0f の判定結果を参照できる点がミソ。
</p>
<p>
81.36.137.136 はスペインのプロバイダの IP アドレスらしいが、
逆引きしてみると 136.Red-81-36-137.dynamicIP.rima-tde.net となるので
動的に割当てられているアドレスなのだろう。
これは p0f の結果に pppoe (DSL) と出ていることと符合する。
そして Windows 2000 SP4 か Windows XP SP1 以降を使って
送信していることが分かる。
</p>]]>
</content:encoded>
</item>
<item rdf:about="http://blog.gcd.org/archives/51130717.html">
<title>BIOS アップデートにより、ハードディスクが Power-Up In Standby 状態になっていても起動できるようになった</title>
<link>http://blog.gcd.org/archives/51130717.html</link>
<description>
「1/9 以降、Windows VISTA 搭載 レッツノートのハードディスクが突然死する可能性がある」問題を解決するための BIOS が公開された。


レッツノート (1/21):


本BIOSの導入によって現象を回避することが可能ですが、
詳細が判明次第、弊社Webサイトにてご報告い...</description>
<dc:creator>hiroaki_sengoku</dc:creator>
<dc:date>2008-01-22T11:02:32+09:00</dc:date>
<dc:subject>ハードウェアの認識と制御</dc:subject>
<content:encoded><![CDATA[<p>
「<a href="http://blog.gcd.org/archives/51128306.html">1/9 以降、Windows VISTA 搭載 レッツノートのハードディスクが突然死する可能性がある</a>」問題を解決するための BIOS が公開された。
</p>
<p>
レッツノート (1/21):
</p>
<blockquote>
本BIOSの導入によって現象を回避することが可能ですが、
詳細が判明次第、弊社Webサイトにてご報告いたしますので、
引き続き弊社Webサイトからお知らせを覧いただきますようお願いします。
<br />
<font color="red">ただし、本現象がすでに発生している場合は、
対策のBIOSアップデートプログラムを導入できません。</font><br />
大変お手数ですが、下記の修理相談窓口に修理のご相談をお願いします。
<div align="right"><a href="http://askpc.panasonic.co.jp/info/info_r6.html">CF-R6M/CF-R6Aシリーズご使用のお客様へのご案内</a> から引用</div>
</blockquote>
<p>
Lenovo ThinkPad (1/15):
</p>
<blockquote>
注意：Windows Vistaを使用しているシステムで、
電源投入時に"2100: Initialization error on HDD0 (Main hard disk drive)"と
表示され、
HDDから起動できなくなることがある問題を修正しました。
<div align="right"><a href="http://www-06.ibm.com/jp/domino05/pc/download/download.nsf/jtechinfo/MIGR-63685">ファームウェア・アップデート・ユーティリティ 2.5インチ SATA ハード・ディスク・ドライブ用</a> から引用</div>
</blockquote>
<p>
レッツノートの BIOS アップデートは Windows 上から実行する必要があるので、
「本現象がすでに発生している場合は」、
まず「<a href="http://blog.gcd.org/archives/51128784.html">Windows VISTA 用の更新プログラム KB943899 が原因で突然死したハードディスクを復旧させる方法</a>」などを用いてハードディスクをスピン・アップさせ、
Windows を正常起動させておく必要がある。
「修理相談窓口に修理のご相談を」するのは「大変お手数」なので、
ハードディスク以外の方法 (USB メモリからの起動など) で
起動する手段を提供すべきだと思うのだが...
</p>
<p>
さっそくレッツノートで BIOS アップデートを行なってみた。
</p>
<p>
試しに、
ハードディスクを故意に Power-Up In Standby 状態にしてみる。
すなわち、
「<a href="http://blog.gcd.org/archives/51128784.html">Windows VISTA 用の更新プログラム KB943899 が原因で突然死したハードディスクを復旧させる方法</a>」 の 
「お手軽パック」などを使って Linux を起動し、
hdparm コマンドを使って Power-Up In Standby 状態にしてみる:
</p>
<pre class="terminal">
# 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
# 
</pre>
<p>
おお、fool proof 機能付とは、なかなか親切なコマンドだ。
<font color="red">とても危険</font>なので、
「何をしようとしているか分かっている」場合のみ、
「--yes-i-know-what-i-am-doing」オプションを付けて再実行する:
</p>
<pre class="terminal">
# /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
# 
</pre>
<p>
これで、ハードディスクが Power-Up In Standby 状態になった。
つまり電源投入時にスタンバイ・モードに入り、
明示的に spin up 命令を送らない限りは回転を始めない。
だから、
レッツノートの以前の BIOS ではハードディスクを認識できず起動に失敗していた。
</p>
<p>
Ctrl-Alt-Del を押して再起動すると、
ハードディスクから正常にブートした。
再び「お手軽パック」を使って Linux を起動し、
ハードディスクの状態を確認してみる:
</p>
<pre class="terminal">
# /mnt/hdparm -I /dev/sda | grep Power-Up
                Power-Up In Standby feature set
# 
</pre>
<p>
Power-Up In Standby 機能が無効になっていた。
新しい BIOS は、
ハードディスクに spin up 命令を送るだけでなく、
Power-Up In Standby 機能を無効にする命令も送っているようだ。
</p>
]]>
</content:encoded>
</item>
<item rdf:about="http://blog.gcd.org/archives/51128784.html">
<title>Windows VISTA 用の更新プログラム KB943899 が原因で突然死したハードディスクを復旧させる方法</title>
<link>http://blog.gcd.org/archives/51128784.html</link>
<description>
昨日書いた
「1/9 以降、Windows VISTA 搭載 レッツノートのハードディスクが突然死する可能性がある
」を大変多くの方に読んで頂けた。
頂いたコメントで目立ったのが、
復旧方法が万人向けではない、という点。
確かに Linux 2.6.22 以上の LiveCD を自前で調達しな...</description>
<dc:creator>hiroaki_sengoku</dc:creator>
<dc:date>2008-01-18T09:40:43+09:00</dc:date>
<dc:subject>ハードウェアの認識と制御</dc:subject>
<content:encoded><![CDATA[<p>
昨日書いた
「<a href="http://blog.gcd.org/archives/51128306.html">1/9 以降、Windows VISTA 搭載 レッツノートのハードディスクが突然死する可能性がある</a>
<a href="http://b.hatena.ne.jp/entry/http://blog.gcd.org/archives/51128306.html"><img style="border:0;" src="http://b.hatena.ne.jp/entry/image/http://blog.gcd.org/archives/51128306.html" alt="" /></a>」を大変多くの方に読んで頂けた。
頂いたコメントで目立ったのが、
復旧方法が万人向けではない、という点。
確かに Linux 2.6.22 以上の LiveCD を自前で調達しなければならないというのは、
よほど普段から Linux を使いこなしていない限りは難しいだろう。
</p>
<p>
というわけで、
突然死したハードディスクを復旧させる「<a href="http://www.gcd.org/sengoku/archives/linux-2.6.23.12_syslinux_hdparm.zip">お手軽パック</a>」を作ってみた。
もちろん無保証である。
いかなる損害が発生しても私は何の責任も負えない、
ということに同意して頂けるかたのみに対して使用を許諾する。
</p>
<p>
まず、<a href="http://www.gcd.org/sengoku/archives/linux-2.6.23.12_syslinux_hdparm.zip">この zip アーカイブ</a> をダウンロードして、
USB メモリへ展開する。
以下の例では USB メモリが「ドライブ D」になっているが、
実際の USB メモリのドライブ名で読み替えて欲しい。
</p>
<pre class="terminal">
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:\>
</pre>
<p>
Windows のコマンド プロンプト にて、
D:\syslinux.exe を以下のように実行する。
もちろん、引数の「D:」は USB メモリのドライブ名で読み替える。
</p>
<pre class="terminal">
D:\>syslinux.exe -ma D:

D:\>
</pre>
<p>
これで Linux 2.6.23.12 がブート可能な USB メモリができた。
このメモリをレッツノートに差して起動する。
BIOS 設定で USB から起動可能にしておくのを忘れずに。
</p>
<p>
ハードディスクが回転しないのであるから、
以下のメッセージが表示されて止まってしまうが、
</p>
<pre class="terminal">
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

&lt;F2>キーを押すとセットアップを起動します。
</pre>
<p>
ここで構わず &lt;F1>キーを押すと、
USB メモリからの起動が始まる。
</p>

<p>
linux が起動すると /bin/sh が実行されてプロンプト「#」が表示されるが、
その後 USB メモリが認識されてカーネル・ログが出力される。
</p>
<pre class="terminal">
	...
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
</pre>
<p>
プロンプトの後にカーネル・ログが出力されてしまっているため紛らわしいが、
Enter キーを押せばプロンプトが表示される。
</p>
<p>
このカーネル・ログでは [sdb] と表示されているが、
レッツノートに接続した USB デバイスが他にもあれば、
sdc や sdd になっているかもしれない。
その場合は、以下の sdb を sdc なり sdd なりで読み替えて欲しい。
</p>
<p>
以下のように mount コマンドを実行して、
USB メモリを /mnt へマウントする。
そして USB メモリ上の hdparm コマンドを実行してみる:
</p>
<pre class="terminal">
# 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

# 
</pre>
<p>
以上のように、
レッツノートのハードディスク (/dev/sda) の諸元が表示されれば成功である。
以下のように hdparm を実行して「Power-Up In Standby feature」を無効にすれば、
ハードディスクの復旧が完了する。
</p>
<pre class="terminal">
# /mnt/hdparm -s0 /dev/sda

/dev/sda:
 spin-up: setting power-up in standby to 0 (off)
# 
</pre>
<p>
後は、Ctrl-Alt-Del を押すなどして再起動すれば、
ハードディスクから正常にブートする。
USB メモリを抜くのを忘れずに。
</p>
]]>
</content:encoded>
</item>
<item rdf:about="http://blog.gcd.org/archives/51128306.html">
<title>1/9 以降、Windows VISTA 搭載 レッツノートのハードディスクが突然死する可能性がある</title>
<link>http://blog.gcd.org/archives/51128306.html</link>
<description>
先日 1/10 (運悪く出張初日だった *_*) に、
レッツノート CF-R6MWVAJP のハードディスク・ドライブ (以下、HDD と略記) が
回転しなくなり (スピン・アップしない) 往生した。
電源を入れても、
BIOS が


Phoenix TrustedCore(tm) NB
Copyright 1985-2004 Phoeni...</description>
<dc:creator>hiroaki_sengoku</dc:creator>
<dc:date>2008-01-17T08:59:30+09:00</dc:date>
<dc:subject>ハードウェアの認識と制御</dc:subject>
<content:encoded><![CDATA[<p>
先日 1/10 (運悪く出張初日だった *_*) に、
レッツノート CF-R6MWVAJP のハードディスク・ドライブ (以下、HDD と略記) が
回転しなくなり (スピン・アップしない) 往生した。
電源を入れても、
BIOS が
</p>
<pre class="terminal">
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

&lt;F2>キーを押すとセットアップを起動します。
</pre>
<p>
というメッセージをビープ音とともに出力して止まってしまう。
HDD が壊れたのかと思い、
BIOS で HDD を起動ドライブから外して USB メモリからブートを試みたが、
起動ドライブから外しても内蔵 HDD に問題があると先に進めないようだ。
</p>
<blockquote>
HDD を完全に取り除いてしまえば USB メモリからブートするらしいが、
このような中途半端な死にかただとスピン・アップ待ちになってしまって、
そこから先に進めなくなる
(後で知ったのだが、
実は上記画面で止まっているとき &lt;F1&gt; を押すと、
ブートを継続できて USB メモリ等からブートできる)。
</blockquote>
<p>
昔、HDD のスピンドル (spindle) が固着して、
スピン・アップ (spin up) しなくなる症状に見舞われたことがあったが、
今回はつい数分前まで全く正常に動いていた HDD が、
突然スピン・アップしなくなったのであって、
あからさまに症状が異なるように思われた。
しかもごく短い距離を移動するためにレッツ・ノートを閉じただけなので、
途中衝撃なども一切与えていない。
機械的な障害ではないように思われた。
</p>
<p>
とはいえ、
いちおー無駄な抵抗は試みた (^^;)。
すなわち、
HDD が回転しなくなったときに、
HDD を振り回すことによってトルクを与える手法や、
あるいは結露等で回路に異常がおきたときに、
結露を霧散させる手法 (平たく言うとしばらく放置しただけ ;) を試したのだが、
HDD が回転音を発することは無かった。
出張初日で、
代替マシンの調達もままならず、
Advanced/W-ZERO3[es] に USB キーボードをつないで急場をしのいだものの、
えらく難儀した。
</p>
<div align="center">- o -</div>
<p>
結論から言うと、
想像通りハードウェア的にはなんら故障していなかった。
単に HDD が
「電源投入時にスタンバイ・モードに入る (power-on in standby)」
状態になっていただけだった。
</p>
<blockquote>
1/9 に行なわれた Windows Update <a href="http://support.microsoft.com/?kbid=943899">KB943899</a> が原因らしいです。
おそらくこの Update のバグで、
HDD に power-on in standby を有効にする命令が
送られてしまうことがあるのでしょう。
私の CF-R6 は 1/10 に発症しましたが、
他にも同様の発症例が多数あるとか。
</blockquote>
<p>
例えば、
Linux の hdparm コマンドのマニュアルには、
次のような記述がある。
</p>
<pre class="code">
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.  <font color="red">VERY DANGEROUS</font>.  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.
</pre>
<p>
「<font color="red">VERY DANGEROUS</font>」と書いてある通り、
HDD がひとたびこの「power-on in standby」モードになってしまうと、
電源を投入してもスピン・アップしなくなる (スタンバイ状態になる)。
HDD が沢山あるサーバなどで、
全ディスクが一斉に回転を始めると、
突入電流が電源の許容範囲を超えてしまったりするわけで、
それを回避するためのモードらしい。
つまり、
電源を投入したあと、
おもむろに HDD を一台づつスピン・アップしていくことにより、
回転開始にともなう突入電流を分散させることができるというわけ。
</p>
<p>
実験してみる 
(<font color="red">非常に危険</font>なので何をやっているか完全に理解するまでは
<font color="red">真似しないでください</font>):
</p>
<pre class="terminal">
# 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
<font color="red">	   *	Power-Up In Standby feature set</font>
	   *	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
# 
</pre>
<p>
「Power-Up In Standby feature set」が有効になっていることが分かる。
この状態で再起動する (HDD の電源をいったん切る) と、
冒頭に引用した「0200: ハードディスクエラーです。 0」を表示して止まってしまう。
&lt;F1&gt; を押して HDD 以外から起動させると、
</p>
<pre class="terminal-scroll">
[    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
<font color="red">[   72.481099] end_request: I/O error, dev sda, sector 0</font>
[   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
</pre>
<p>
何度も HDD へリクエストを再送した末、「I/O error」になる。
Linux 2.6.22 以降の場合、
I/O error にはなるものの HDD デバイス自体は認識しているので、
hdparm コマンドからコントロールすることができる。
</p>
<blockquote>
逆に言うと、古いカーネルだとデバイス認識も行なわれないので、
hdparm コマンドすら使えなくなってしまい
<font color="red">以下の方法では復旧できない</font>。
現時点では Knoppix などの LiveCD の多くは、
2.6.21 以前のカーネルのまま (例えば Knoppix v5.1.1 は 2.6.19) なので注意。
</blockquote>
<p>
hdparm を使って「Power-Up In Standby feature」を無効にする:
</p>
<pre class="terminal">
# 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
# 
</pre>
<p>
これで、電源投入時に HDD は自動的に回転を始めるようになる。<br />
再起動すれば HDD から正常にブートする。
</p>]]>
</content:encoded>
</item>

</rdf:RDF>