HDDレコーダーが壊れました
別れは突然に
うちで約8年使用した東芝のブルーレイ/HDDレコーダー REGZA DBR-Z150がお亡くなりになりました。
嫁によるとなんか変な匂いがすると思ったら、正面パネルに「WAIT」の文字が点滅して起動しなくなったとのこと。
またブルーレイ/DVDのトレーも開きません。
多分、電源かなと思いつつ、今更修理してもなので、今日新しいレコーダーを買いに行きました。
新しいレコーダーは明日AMに届くとのことで、帰宅後にREGZAを開腹してみました。
ちなみに背面の電源ファン周りはこんな感じで「Java powered」とか書いてあります。
お前、Javaだったんかい！！道理で遅.....まあ、購入直後に見ていたはずですがすっかり忘れてました。
で、開腹するとこんな感じです。
この後、HDDの取り出しと、ブルーレイドライブを一回バラして中にメディアが閉じ込められていない事を確認して、ブルーレイドライブの方は元に戻しました。
HDDの方は、PCにUSB経由で外付けするアダプタ(SATA-USB)を使って、Ubuntuマシンに接続、状態をチェックしました。
partedでパーティション情報を確認した結果はこんな感じです。
(parted) print エラー: /dev/sdc: ディスクラベルが認識できません。 モデル: USB3.0 TO0SATA (scsi) ディスク /dev/sdc: 1000GB セクタサイズ (論理/物理): 512B/512B パーティションテーブル: unknown ディスクフラグ: (parted)
パーティションテーブルが見つからず、ファイルシステム等がどうなっているのか判りません。
testdiskというLinuxで動くパーティション解析ツールを使ってみたのですが、そちらも同じ結果。色々ググッてみると東芝のレコーダーの内蔵ディスクは一般的なPCのHDDの様なパーティションテーブルは無く、ファイルシステムがいきなり書かれている様です。バイト順がswapされたUDFだという話もあるのですが、全機種同じかは不明です。
なお外付けHDDの場合は普通にパーティションテーブルがあり、xfsでフォーマットされている事が判る様です。
smartctlでS.M.A.R.Tの診断情報を取り出してみます。
$ sudo smartctl -a -d sat,16 /dev/sdc
smartctl 6.5 2016-01-24 r4214 [x86_64-linux-4.4.0-143-generic] (local build)
Copyright (C) 2002-16, Bruce Allen, Christian Franke, www.smartmontools.org
=== START OF INFORMATION SECTION ===
Model Family: Western Digital AV-GP (AF)
Device Model: WDC WD10EUCX-63YZ1Y0
Serial Number: WD-WCC0T0751721
LU WWN Device Id: 5 0014ee 2b12a9d0f
Firmware Version: 51.0AB52
User Capacity: 1,000,204,886,016 bytes [1.00 TB]
Sector Sizes: 512 bytes logical, 4096 bytes physical
Device is: In smartctl database [for details use: -P show]
ATA Version is: ATA8-ACS (minor revision not indicated)
SATA Version is: SATA 3.0, 6.0 Gb/s (current: 6.0 Gb/s)
Local Time is: Sat May 30 16:28:44 2020 JST
SMART support is: Available - device has SMART capability.
SMART support is: Enabled
=== START OF READ SMART DATA SECTION ===
SMART Status not supported: Incomplete response, ATA output registers missing
SMART overall-health self-assessment test result: PASSED
Warning: This result is based on an Attribute check.
General SMART Values:
Offline data collection status: (0x00) Offline data collection activity
was never started.
Auto Offline Data Collection: Disabled.
Self-test execution status: ( 0) The previous self-test routine completed
without error or no self-test has ever
been run.
Total time to complete Offline
data collection: (18300) seconds.
Offline data collection
capabilities: (0x7b) SMART execute Offline immediate.
Auto Offline data collection on/off support.
Suspend Offline collection upon new
command.
Offline surface scan supported.
Self-test supported.
Conveyance Self-test supported.
Selective Self-test supported.
SMART capabilities: (0x0003) Saves SMART data before entering
power-saving mode.
Supports SMART auto save timer.
Error logging capability: (0x01) Error logging supported.
General Purpose Logging supported.
Short self-test routine
recommended polling time: ( 2) minutes.
Extended self-test routine
recommended polling time: ( 179) minutes.
Conveyance self-test routine
recommended polling time: ( 5) minutes.
SCT capabilities: (0x30b5) SCT Status supported.
SCT Feature Control supported.
SCT Data Table supported.
SMART Attributes Data Structure revision number: 16
Vendor Specific SMART Attributes with Thresholds:
ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE UPDATED WHEN_FAILED RAW_VALUE
1 Raw_Read_Error_Rate 0x002f 200 200 051 Pre-fail Always - 0
3 Spin_Up_Time 0x0027 172 116 021 Pre-fail Always - 4383
4 Start_Stop_Count 0x0032 083 083 000 Old_age Always - 17271
5 Reallocated_Sector_Ct 0x0033 200 200 140 Pre-fail Always - 0
7 Seek_Error_Rate 0x002e 200 200 000 Old_age Always - 0
9 Power_On_Hours 0x0032 060 060 000 Old_age Always - 29548
10 Spin_Retry_Count 0x0032 100 100 000 Old_age Always - 0
11 Calibration_Retry_Count 0x0032 100 100 000 Old_age Always - 0
12 Power_Cycle_Count 0x0032 086 086 000 Old_age Always - 14662
192 Power-Off_Retract_Count 0x0032 181 181 000 Old_age Always - 14658
193 Load_Cycle_Count 0x0032 199 199 000 Old_age Always - 5035
194 Temperature_Celsius 0x0022 108 104 000 Old_age Always - 39
196 Reallocated_Event_Count 0x0032 200 200 000 Old_age Always - 0
197 Current_Pending_Sector 0x0032 200 200 000 Old_age Always - 0
198 Offline_Uncorrectable 0x0030 100 253 000 Old_age Offline - 0
199 UDMA_CRC_Error_Count 0x0032 200 200 000 Old_age Always - 0
200 Multi_Zone_Error_Rate 0x0008 100 253 000 Old_age Offline - 0
SMART Error Log Version: 1
No Errors Logged
SMART Self-test log structure revision number 1
No self-tests have been logged. [To run self-tests, use: smartctl -t]
SMART Selective self-test log data structure revision number 1
SPAN MIN_LBA MAX_LBA CURRENT_TEST_STATUS
1 0 0 Not_testing
2 0 0 Not_testing
3 0 0 Not_testing
4 0 0 Not_testing
5 0 0 Not_testing
Selective self-test flags (0x0):
After scanning selected spans, do NOT read-scan remainder of disk.
If Selective self-test is pending on power-up, resume after 0 minute delay.
長いのですが、ざっくり言って顕著なエラー情報は無く、寿命的にはまだ半分くらいあるよという感じに見えます。
例えばPower_On_Hoursで60というのは想定稼働時間(設計寿命)の60%くらいの累積稼働時間ということらしいです。
エラーカウントや代替セクターの使用率も低い様なので、HDD自体は別目的にフォーマットして使えそうです。
ただ、3.5インチなので今となってはデカくて邪魔ですが、1TBあるのでバックアップか実験用途に良いかなと。
下記は電源ボードの一部をアップで撮ったものです。
写真右上の大きめの電解コンデンサー2つの足元に白い物質が広がっています。どちらかのコンデンサーから電解質が漏れだしたと推定。多分電源がイカレた原因はこれです。
内部のホコリとかなるべく掃除した状態で通電してみたのですが、電源ファンが回ったり、回らなかったりを繰り返し、電力が安定供給されない状態。
稀に起動まで行くのですが、長時間安定して動かない。目視で見る限り、電解コンの液漏れ以外、焼損とかは見当たらなかったのですが、通電続けて事故になってもいやなので、諦めました。
多分電解コン取り替えて、電源ボード掃除すれば復旧しそうには思うのですが、既に代替機を購入してしまったので、DBR-Z150は粗大ごみ行きです。
raspberry pi クロックダウン
raspberry piのクロック制御
あまり需要は無いかもしれないのですが、実はraspberry piはクロックダウン出来ます。
公式サイトに「Overclocking options in config.txt」というドキュメントがあり、ラズパイ内の各種クロック周波数や関連する電圧設定を変更出来る事が書かれています。
(出来るけど、正常動作するかは自己責任。当然適切に冷却したり、容量に余裕ある電源使ったり等必要です。)
/boot/config.txt内に各種ハードウェア設定値が記載されており、これを書き換える事で色々HWの挙動が変更可能で、その中でいくつかのクロック周波数の上限値の設定があります。
もちろん、ラズパイのモデル毎のSoCがHW的に許容する範囲である必要があります。
で、ラズパイに搭載されたARMのクロック周波数ですが、arm_freqという項目の他にarm_freq_minという項目があり、これを設定するとラズパイの動作クロックの下限値が変更可能な様です。
うちのラズパイはpi 2 Model Bで、通常は下限600MHz,上限900MHzで、cpufrequtilsでcpufreqのgovernorをOnDemandにしておくと(通常はこれがデフォルト?)、CPU負荷に応じてクロック周波数が切り替わります。
ちなみにうちのラズパイは電源との相性か、はたまたSoCにヒートシンクとか貼っていないせいか、900MHz駆動だと不安定動作していたので、かなり以前にgovernorをpowersaveに変更して常時下限クロック600MHz駆動にしてあります。
vcgencmdでARMクロックを測定すると以下のような感じで600MHz駆動を教えてくれます。
pi@raspberrypi:~ $ vcgencmd measure_clock arm frequency(45)=600062000 pi@raspberrypi:~ $ vcgencmd measure_clock arm frequency(45)=600000000 pi@raspberrypi:~ $ vcgencmd measure_clock arm frequency(45)=600000000 pi@raspberrypi:~ $ vcgencmd measure_clock arm
この状態で試しにconfig.txtにarm_freq_min=400という行を追加(root権限が必要なので、sudo nanoとかsudo viで編集)してrebootします。
しばらく待って、再度ログイン、ARMクロックを再測定します。
pi@raspberrypi:~ $ vcgencmd measure_clock arm frequency(45)=400042000 pi@raspberrypi:~ $ vcgencmd measure_clock arm frequency(45)=400000000 pi@raspberrypi:~ $ vcgencmd measure_clock arm frequency(45)=400000000 pi@raspberrypi:~ $
あと、下限を変更可能なのは判ったのですが、どこまで落とせるかは、公式サイトにも記載がありません。チップの仕様をチェックするしか無いのかな？
cpufreqドライバーのラズパイ対応のソースはチェックしましたが、firmware上のテーブルから下限値取得するみたいので、おそらくconfig.txtの下限値がそこに反映されているんじゃないかと思っています。
念のため、600MHz駆動時と400MHz駆動時で、byte UNIXBENCHからdhry2のみ単体走行させて比較しました。(全部測るとものすごく時間かかるので)
600MHz駆動時、byte UNIXBENCHのdhry2単体走行(10秒間x3回)
pi@raspberrypi:~/byte-unixbench/UnixBench/pgms $ ./dhry2 10 COUNT|20633470|1|lps pi@raspberrypi:~/byte-unixbench/UnixBench/pgms $ ./dhry2 10 COUNT|19905914|1|lps pi@raspberrypi:~/byte-unixbench/UnixBench/pgms $ ./dhry2 10 COUNT|20640950|1|lps
400MHz駆動時、byte UNIXBENCHのdhry2単体走行(10秒間x3回)
pi@raspberrypi:~/byte-unixbench/UnixBench/pgms $ ./dhry2 10 COUNT|13740372|1|lps pi@raspberrypi:~/byte-unixbench/UnixBench/pgms $ ./dhry2 10 COUNT|13745414|1|lps pi@raspberrypi:~/byte-unixbench/UnixBench/pgms $ ./dhry2 10 COUNT|13738639|1|lps
概ね、クロック比でスコアが変化している様です。
これが何の役に立つのか？ですが、Pi ZEROをバッテリー駆動とかで動かしている際に、そんなに性能は要らないケースでクロックと電圧ダウンで安定動作するポイント見つければ多少バッテリー駆動時間伸ばせるとかあるかもしれないです...あまり遅くすると周辺デバイスとのやり取りとかに時間かかってトータルでかえって電力食う可能性とかもあるので、あくまでも可能性としてですが...
