正しいパソコンとの向き合い方
誤: ナナメ45度
（続き）
事の発端はこんな見た目をしていました。
Linux version 3.2.30 (*@*) (gcc version 4.4.7 (Debian 4.4.7-2) ) #1 SMP
Nov 23 05:59:45 * kernel: ata2.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
Nov 23 05:59:45 * kernel: ata2.00: BMDMA2 stat 0x6d0009
Nov 23 05:59:45 * kernel: ata2.00: failed command: READ DMA EXT
Nov 23 05:59:45 * kernel: ata2.00: cmd 25/00:00:72:43:02/00:01:83:00:00/e0 tag 0 dma 131072 in
Nov 23 05:59:45 * kernel: res 51/04:af:72:43:02/00:00:83:00:00/e0 Emask 0x1 (device error)
Nov 23 05:59:45 * kernel: ata2.00: status: { DRDY ERR }
Nov 23 05:59:45 * kernel: ata2.00: error: { ABRT }
Nov 23 05:59:45 * kernel: ata2.00: configured for UDMA/100
Nov 23 05:59:45 * kernel: ata2: EH complete要約すると「HDDが device error でfailしたよ、とりあえずリンク再起動して動作継続中だよ」といったところですか。リザルトステータスが device error、ということはHDDが自己診断的に「おらーはしんじまっただー」と言っているぞという意味で、ええと比較的ピンチです。このディスクの中身には一応まだ用があります。もっともリンク再起動しただけで動作継続できている上にSMART的にも特段の異常フラグが立っていないあたり、不健康には違いなくとも今のところ致命傷には至っていない程度の状態と想像します。ぶっちゃけ何らかの突発事故でたまにこういう事が起こることもあるので、再発しない場合はあまり気にしなくても問題ないかもしれません。これだけなら。
・・・しかし6日後。
Nov 29 05:36:32 * kernel: ata2.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
Nov 29 05:36:32 * kernel: ata2.00: BMDMA2 stat 0x6d0009
Nov 29 05:36:32 * kernel: ata2.00: failed command: READ DMA EXT
Nov 29 05:36:32 * kernel: ata2.00: cmd 25/00:00:1a:c2:ca/00:01:89:00:00/e0 tag 0 dma 131072 in
Nov 29 05:36:32 * kernel: res 51/04:cf:1a:c2:ca/00:00:89:00:00/e0 Emask 0x1 (device error)
Nov 29 05:36:32 * kernel: ata2.00: status: { DRDY ERR }
Nov 29 05:36:32 * kernel: ata2.00: error: { ABRT }
Nov 29 05:36:32 * kernel: ata2.00: configured for UDMA/100
Nov 29 05:36:32 * kernel: ata2: EH complete余裕で再発しやがりました。状況と経緯は初回とほぼ同じですね。これまで2年くらい一度もfailしていなかった玉が急にfailしだしていて、しかもそれがたった6日で反復しているということは、これはもう断じて突発事故ではありません。どこかに不良があります。問題です。大変に問題です。
そしてさらにその数時間後・・・
Nov 29 10:09:20 * kernel: ata2.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6 frozen
Nov 29 10:09:20 * kernel: ata2.00: failed command: READ DMA EXT
Nov 29 10:09:20 * kernel: ata2.00: cmd 25/00:00:c2:1c:cf/00:01:95:00:00/e0 tag 0 dma 131072 in
Nov 29 10:09:20 * kernel: res 40/00:cf:1a:c2:ca/00:00:89:00:00/e0 Emask 0x4 (timeout)
Nov 29 10:09:20 * kernel: ata2.00: status: { DRDY }
Nov 29 10:09:20 * kernel: ata2: hard resetting link
Nov 29 10:09:20 * kernel: ata2: SATA link up 1.5 Gbps (SStatus 113 SControl 310)
Nov 29 10:09:20 * kernel: ata2.00: configured for UDMA/100
Nov 29 10:09:20 * kernel: ata2: EH completeこれはかなりいやな感じです。リザルトステータスが timeout に変わりました。ピンチです。「おらーはしんじまっただー♪」が「おらーはしんじまった・・・ガクッ」に変わったということです。動作自体はリンク再起動で継続できているものの、アクセス中に timeout が発生するようだとディスク内の残存データの救出がうまくいかなくなる可能性が跳ね上がります。
普通に考えればこの時点でもう何が何でも玉ごと交換すべき状況・・・だと思うんですが、それにしては玉の音響的にはとても健康そうな気がするのがふと引っかかったのです。そういえば最近ぺんぎんのSATAドライバに何か不具合があるんじゃ的な話を赤帽方面で見かけたような気がします。というわけでたまにはkernelコンパイルして再起動してみることにしました。不具合を抱えている可能性の高い玉をスピンダウン/アップするというのは一般的に自殺行為と見なされますが、再起動するだけならスピンダウンはかからないのでたぶん問題ないでしょう。
Linux version 3.2.32 (*@*) (gcc version 4.4.7 (Debian 4.4.7-2) ) #1 SMP
Dec 2 00:09:56 * kernel: ata2.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6 frozen
Dec 2 00:09:56 * kernel: ata2.00: failed command: READ DMA EXT
Dec 2 00:09:56 * kernel: ata2.00: cmd 25/00:00:d7:8a:c2/00:04:53:00:00/e0 tag 0 dma 524288 in
Dec 2 00:09:56 * kernel: res ff/ff:ff:ff:ff:ff/ff:ff:ff:ff:ff/ff Emask 0x2 (HSM violation)
Dec 2 00:09:56 * kernel: ata2.00: status: { Busy }
Dec 2 00:09:56 * kernel: ata2.00: error: { ICRC UNC IDNF ABRT }
Dec 2 00:09:56 * kernel: ata2: drained 65536 bytes to clear DRQ
Dec 2 00:09:56 * kernel: ata2: hard resetting link
Dec 2 00:09:56 * kernel: ata2: SATA link up 1.5 Gbps (SStatus 113 SControl 310)
Dec 2 00:09:57 * kernel: ata2.00: configured for UDMA/100
Dec 2 00:09:57 * kernel: ata2: EH complete
Dec 2 00:55:55 * kernel: ata2.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6 frozen
Dec 2 00:55:55 * kernel: ata2.00: failed command: READ DMA EXT
Dec 2 00:55:55 * kernel: ata2.00: cmd 25/00:00:ef:6c:91/00:04:53:00:00/e0 tag 0 dma 524288 in
Dec 2 00:55:55 * kernel: res ff/ff:ff:ff:ff:ff/ff:ff:ff:ff:ff/ff Emask 0x2 (HSM violation)
Dec 2 00:55:55 * kernel: ata2.00: status: { Busy }
Dec 2 00:55:55 * kernel: ata2.00: error: { ICRC UNC IDNF ABRT }
Dec 2 00:55:55 * kernel: ata2: drained 65536 bytes to clear DRQ
Dec 2 00:55:55 * kernel: ata2: hard resetting link
Dec 2 00:55:56 * kernel: ata2: SATA link up 1.5 Gbps (SStatus 113 SControl 310)
Dec 2 00:55:56 * kernel: ata2.00: configured for UDMA/100
Dec 2 00:55:56 * kernel: ata2: EH complete
Dec 2 01:47:37 * kernel: ata2.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6 frozen
Dec 2 01:47:37 * kernel: ata2.00: failed command: READ DMA EXT
Dec 2 01:47:37 * kernel: ata2.00: cmd 25/00:00:52:5a:f1/00:04:7e:00:00/e0 tag 0 dma 524288 in
Dec 2 01:47:37 * kernel: res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout)
Dec 2 01:47:37 * kernel: ata2.00: status: { DRDY }
Dec 2 01:47:37 * kernel: ata2: hard resetting link
Dec 2 01:47:37 * kernel: ata2: SATA link up 1.5 Gbps (SStatus 113 SControl 310)
Dec 2 01:47:38 * kernel: ata2.00: configured for UDMA/100
Dec 2 01:47:38 * kernel: ata2.00: device reported invalid CHS sector 0
Dec 2 01:47:38 * kernel: ata2: EH complete・・・だめです。全然だめです。リザルトステータスには何か得体の知れない違反が増えました。なんかもうとてもピンチです。きっと瀕死です。はやいとこデータ救出した方が身のためです。きっとそうです。
と一瞬思ったものの、何か不自然じゃないですかコレ。
リザルトステータスがFFベタと00ベタに変わっています。前回までは何か値が入っていました。どっちにしても中身は知りませんが。もちろんkernelを交換したのが原因でこういう見た目の変化が現れたという可能性は否定できないんですが、libataの現在の“それなりの成熟度”から考えるとその説明はあまり「もっともらしい」ように思えません。どちらかと言えばFFベタや00ベタは「存在すべき信号が何もない」的な状態から生じた結果であると思った方が「もっともらしい」気がするし、であれば玉自体ではなくリンクに不良がある可能性を疑った方がいいように思えます。
HDDは相変わらず音響的には健康そうです。一度くらいスピンダウンしてもたぶん死なないでしょう。死なない方に賭ける。
というわけで、事ここに至って初めて電源を落とし、I/F側でポートを入れ替えて再起動しました。I/F側のPHYが不良を抱えたのか、あるいはそれより先のケーブルからHDD側のPHYまでの間に不良が生じたのかの切り分けを試みるためです。同じポートで不良が再発するならI/F側、不良が入れ替えについて行くようならケーブルかHDD側です。
果たして賭にはすんなり勝って、普通に起動しました。そして・・・
Linux version 3.2.32 (*@*) (gcc version 4.4.7 (Debian 4.4.7-2) ) #1 SMP
Dec 2 02:15:08 * kernel: ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6 frozen
Dec 2 02:15:08 * kernel: ata1.00: failed command: READ DMA EXT
Dec 2 02:15:08 * kernel: ata1.00: cmd 25/00:00:57:c0:f7/00:04:77:00:00/e0 tag 0 dma 524288 in
Dec 2 02:15:08 * kernel: res ff/ff:ff:ff:ff:ff/ff:ff:ff:ff:ff/ff Emask 0x2 (HSM violation)
Dec 2 02:15:08 * kernel: ata1.00: status: { Busy }
Dec 2 02:15:08 * kernel: ata1.00: error: { ICRC UNC IDNF ABRT }
Dec 2 02:15:08 * kernel: ata1: drained 65536 bytes to clear DRQ
Dec 2 02:15:08 * kernel: ata1: hard resetting link
Dec 2 02:15:08 * kernel: ata1: SATA link up 1.5 Gbps (SStatus 113 SControl 310)
Dec 2 02:15:08 * kernel: ata1.00: configured for UDMA/100
Dec 2 02:15:08 * kernel: ata1: EH completeうん超速攻で再発しました。failするポートが1に移動した、つまり不具合がケーブル+HDDについて行ったということは、I/F側のPHYは推定無罪です。容疑者はケーブル+HDDに絞られます。
もちろんHDD側のPHYが死んでしまったら手も足も出せないので、その場合には結局玉の死亡と同義になりますが、リンク上に問題がある可能性が高いという見込みであれば先に試しておくべき事があります。そう、いつものアレです。即ち・・・
the correct way to use some digital equipments:
・・・いやだから冗談ではなくて。
HDD側の電源と信号の端子面を消しゴムでけしけししたら治りました。たぶん。
本当にそれ以外なにもしてないんですが、とりあえず今のところ再発していません。まだあまり時間がたっていないので安心するにはちょっと早いですが、一応その後でディスクの全面走査かけたので、リンク上の転送量としては既にここまでの再発期間の百倍くらいは流れているはずです。
もちろん実はやっぱりだめでもうじきに死ぬという可能性もありますけどね。さてどうなりますか。
