コグノスケ

AArch64 向け Linux デバッグ環境の構築

目次: GCC を調べる - まとめリンク

Linux をデバッグするには kgdb を使うと思いますが、QEMU + GDB でよりお手軽にデバッグができます。お手軽とは書いたものの、実際やったところ QEMU でかなり苦戦したのでメモしておきます。

ツールチェーンの設定

対象のアーキテクチャは AArch64 を選びました。お好きなアーキテクチャを使っていただいて構いませんが、Linux のコンフィグをどうするべきかと、QEMU の動かし方を知っているアーキテクチャにしてください。せっかく Linux をビルドしても動かせなくて詰みます。

ツールチェーンの構築の方法は昔の日記（2018年 7月 15日の日記参照）で構築手段をご紹介しています。crosstool-ng はデフォルトだと GDB がビルドされなかった気がするので、

CT_DEBUG_GDB=y

Debug facilities  --->
  [*] gdb  --->

この変更が必要になると思います。

Linux の設定

Linux カーネルは linux-next を使いました。新し目の LTS カーネルなども十分動くはずです。コンフィグの変更点は下記のとおりです。

CONFIG_RANDOMIZE_BASE=n（gdb でデバッグするときは、アドレスをランダムに変えられると困るため）

Kernel Features  --->
  [ ] Randomize the address of the kernel image


CONFIG_DEBUG_INFO_REDUCED=n（y だと gdb で構造体などの情報が見えなくなるため）

Kernel hacking  --->
  Compile-time checks and compiler options  --->
    [*] Compile the kernel with debug info
      [ ]   Reduce debugging information


CONFIG_MODULES=n（モジュールのインストールが面倒なので）

[ ] Enable loadable module support  ----

デフォルトのコンフィグだと、やたらと色々なドライバをビルドするので時間がかかります。グラフィクス系のドライバなどの明らかに不要なドライバは外しても良いと思います。

QEMU の設定（失敗編）

QEMU は様々なハードウェアを模倣できます。そのなかに Raspberry Pi 3b がありましたのでこれを使います。initrd イメージは buildroot で作りました。

qemu-system-aarch64 \
  -machine raspi3b \
  -kernel arch/arm64/boot/Image \
  -append "earlycon=pl011,0x3f201000 console=ttyAMA0" \
  -dtb arch/arm64/boot/dts/broadcom/bcm2837-rpi-3-b.dtb \
  -initrd ../buildroot/output/images/rootfs.cpio \
  -serial stdio \
  -s

起動してプロンプトまで表示されますが、キー入力を全く受け付けず操作不能になってしまいます。解決方法がわからなかったので諦めました。

ちなみに最近の linux-next を使う場合は、GPIO と pinctrl の初期化順を修正するパッチを当てないといけません。これを当てないと pinctrl が無効になってしまい、連鎖的に pinctrl に依存している SD カードのドライバなども無効化され「rootfs がマウントできない！」と panic になってしまいます。

この問題に気づくまでかなり時間がかかりました。バグだと思ってめっちゃ調べたのに、もうパッチが LKML に投稿されていたという体験は、linux-next を使っていると珍しくないですけどね。よりによって Raspberry Pi だけで起きるバグをタイムリーに引くとは思わなかった……完全に油断してた。

QEMU の設定

Raspberry Pi マシンの代わりに virt マシンを使うことにしました。

今回はユーザーランドは動けば OK ですから、Raspberry Pi のディスクイメージ Raspberry Pi OS Lite 64bit（公式ダウンロードサイト）を使用します。

QEMU で起動する場合 virtio を使用します。QEMU の virt マシンは残念ながら SD や mtd には対応していません。パラレルフラッシュはサイズが 64MB までのために Raspberry Pi OS のイメージは大きすぎると言われ起動できません。

qemu-system-aarch64 \
  -machine virt -cpu cortex-a53 -smp 1 \
  -kernel arch/arm64/boot/Image -append "rw root=/dev/vda2" \
  -drive file=2022-01-28-raspios-bullseye-arm64-lite_resize.img,format=raw,if=virtio \
  -serial stdio \
  -s

最後の -s オプションは GDB の接続をポート 1234 で待機するオプション -gdb tcp::1234 の短縮形です。カーネルのブート部分などをデバッグする場合は、GDB を接続するまで停止していてほしいので -S も一緒に付けると良いです。

デバッグしよう

前置きがだいぶ長くなりましたがこれでデバッグ環境が整いました。GDB を QEMU に接続するには target remote コマンドを使います。

$ aarch64-unknown-linux-gnu-gdb vmlinux

GNU gdb (crosstool-NG 1.24.0.501_5bf4485) 10.2
Copyright (C) 2021 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "--host=x86_64-build_pc-linux-gnu --target=aarch64-unknown-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<https://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
    <http://www.gnu.org/software/gdb/documentation/>.

For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from vmlinux...


(gdb) b start_kernel

Breakpoint 1 at 0xffff800009e10c64: file init/main.c, line 931.


(gdb) target remote :1234

Remote debugging using :1234
0x0000000040000000 in ?? ()


(gdb) c

Continuing.

Breakpoint 1, start_kernel () at init/main.c:931
931     {

実行、ブレーク、ソースコードの表示もできています。良い感じですね！

Zephyr の Device Tree Overlay

目次: Zephyr を調べる - まとめリンク

Zephyr はプロジェクトごとに Device Tree を上書きできます。Device Tree Overlay と呼ばれたりもしますね。やり方は違いますが Linux でも似たような仕組みがあります。

具体的には samples/hello_world の下に boards というディレクトリを作成し、ボード名.overlay というファイルを作成するだけです。Zephyr のビルドシステムが勝手に検知してくれます。便利ですね。

今回は qemu_riscv64 向けに作りますからファイル名は qemu_riscv64.overlay になります。

samples/hello_world/
├── CMakeLists.txt
├── README.rst
├── boards
│   └── qemu_riscv64.overlay    ★これ★
├── prj.conf
├── sample.yaml
└── src
    └── main.c

/* samples/hello_world/boards/qemu_riscv64.overlay */

/ {
	resources {
		compatible = "test-overlay";
		value1 = <1>;
		value2 = <10>;
	};
};

Overlay が効いているかどうかはビルド後に生成される zephyr/zephyr.dts を見るとわかります。

/dts-v1/;

/ {
	#address-cells = < 0x1 >;
	#size-cells = < 0x1 >;
	compatible = "riscv-virtio";
	model = "riscv-virtio,qemu";
	flash@20000000 {
		bank-width = < 0x4 >;
		reg = < 0x20000000 0x2000000 0x22000000 0x2000000 >;
		compatible = "cfi-flash";
	};

/* (略) */

	chosen {
		zephyr,console = &uart0;
		zephyr,shell-uart = &uart0;
		zephyr,sram = &ram0;
	};
	resources {    /* ★追加された★ */
		compatible = "test-overlay";
		value1 = < 0x1 >;
		value2 = < 0xa >;
	};
};

Overlay の compatible とプロパティは適当です。当然 compatible に対応するコードはありませんが、今の段階ではエラーにはなりません。

Overlay の次は

デフォルトで無効化されているデバイスを有効にする（status = "okay"; を足したい）くらいであれば、Overlay ファイルの追加だけでも十分に役立ちます。

しかし Zephyr はもう少し複雑な機能も提供しています。次回は独自の compatible を扱う方法をご紹介したいと思います。

新しいニッケル水素電池の充電器を購入

目次: 電池 - まとめリンク

今までニッケル水素電池（以降 Ni-MH 電池）の充電には Panasonic BQ-391 を使っていました。が、端子の一部が青く錆びてきたため、先日、跡継ぎとして Panasonic BQ-CC87 を購入しました。Amazon で 2400円くらいでした。BQ-CC87 は USB での充電、USB の出力（つまりモバイルバッテリー）もできる 1台 2役の優れものです。

通常の充電器の使い方だと継ぎ足し充電は避けるべきですが、BQ-CC87 は継ぎ足し充電もできる（Panasonic のサイトへのリンク）とのことで、とても良い商品だと思います。が……どうも我が家の電池達と相性が悪くて困っています。

出力側の困った現象

我が家にある Ni-MH 電池は 5種類あって、

• Panasonic EVOLTA HHR-3MKS（単3 1900mAh）2本
• Panasonic EVOLTA HHR-3MWS（単3 1900mAh）2本
• Panasonic EVOLTA HHR-3MRS（単3 2000mAh）10本
• Panasonic EVOLTA HHR-4MWS（単4 750mAh）2本
• SANYO eneloop HR-3UTGA/B（単3 1900mAh）4本

どれを使ってもスマホやタブレットを充電しようとすると、一瞬だけ 0.6A くらい出力しますが、すぐに出力が停止します。運が良いと出力が続きますが、

• 出力が 0.4A 程度しか出ない
• 数秒で停止する
• DC 出力ボタンを押し続けると 0.1A くらいの出力で安定？する（スマホ側が諦めるのか？）

こんな感じでまともに動作しているように見えません。うーん。

故障ではない

最初は機械側を疑ったんですが、新しい Ni-MH 電池を新たに 4本買い（Panasonic EVOLTA BK-4HCD, 単4 930mAh）、スマホの充電を試したところ 1A 出力できました。機械は壊れていないようです。

ここから推測できることは、単純に我が家にある電池がヘタっている or BQ-CC87 で使うには気合が足りないってことです。

充電もできない

もうひとつ困ったことに BQ-CC87 は充電する場合も我が家の電池と相性が悪く、すぐに止まってしまいます。その結果 DC 出力も充電もできない、どうしようもない状態の電池がどんどん増えてしまいます。

うちの電池そんなにダメなの？困ったね。

射的

目次: 射的 - まとめリンク

以前、ガスブローバックタイプのエアガンを買ったのですが、家だとうるさいし狭いです。往来の人に危険が及ぶので公の場所（公園、河川敷など）で撃つのも厳禁！！です。というわけで単なる飾りと化していました。

さすがに置物にするのは勿体ないので、どこか撃てる場所はないだろうか？と思って探すと、秋葉原に 7mのシューティングレンジのあるカフェ（バー？）がありました。末広町にあるトリガーハッピーというお店（お店のサイトへのリンク）です。

やってみた感想は「当たるけど当たらない」ですね。

エアガンの出来はとても良く、狙った方向に飛ぶので正しく狙えば当たります。けど、狙っている私が明後日の方向に狙いを付けているのでぜーんぜん当たりません。7m 先と思われる 9個の的を倒すのに 16秒くらいでした。たぶん早い人は半分くらいのタイムでクリアできるんじゃないかな……。

結果はさておき、普段できない遊びでなかなか面白かったです。また行ってみるかー。

Zephyr の Device Tree Overlay と独自の bindings

目次: Zephyr を調べる - まとめリンク

前回の続きです。Zephyr の Device Tree Overlay（2022年 1月 3日の日記参照）で独自の bindings を定義（compatible やプロパティの定義）する方法を紹介します。

前回はこんなノードを追加しました。

/* samples/hello_world/boards/qemu_riscv64.overlay */

/ {
	resources {
		compatible = "test-overlay";
		value1 = <1>;
		value2 = <10>;
	};
};

ノードを追加しただけではエラーにはなりませんが、コードから value1 の値を参照しようとするとビルドエラーになって怒られます。

詳細は Zephyr の Device Tree API マニュアル（Devicetree API - Zephyr Project Documentation）が参考になります。

// samples/hello_world/src/main.c

#include <zephyr.h>
#include <sys/printk.h>

void main(void)
{
	printk("Hello World! %s\n", CONFIG_BOARD);

	printk("value1:%d\n", DT_PROP(DT_INST(0, test_overlay), value1));
	printk("value2:%d\n", DT_PROP(DT_INST(0, test_overlay), value2));
}

$ ninja
...

zephyr/include/generated/devicetree_unfixed.h:308:34: error: 'DT_N_S_resources_P
_value1' undeclared (first use in this function); did you mean 'DT_N_S_resources
_PATH'?
  308 | #define DT_N_INST_0_test_overlay DT_N_S_resources
      |                                  ^~~~~~~~~~~~~~~~

このあとも大量に怒られる……。

Zephyr はコード内でデバイスツリーの値を参照すると、ビルド時に全て解決される仕組みです。そのためデバイスツリーに不都合な点があるとビルド時に猛烈に怒られます。Zephyr のデバイスツリー処理は Python とマクロマジックが駆使されていて、コンパイルエラーのメッセージからエラーの原因がすぐにわからないのが難点ですね……。

Linux は実行時に参照、書き換えが可能なので、Zephyr と Linux の大きく異なる部分と言えましょう。

デバイスツリー定義 yaml ファイル

問題の解決には dts/*.yaml を追加する必要があります。ファイル名は compatible 名.yaml になります。このファイルも Overlay ファイル同様に追加するだけでビルドシステムが勝手に感知して処理してくれます。便利ですね。

samples/hello_world/
├── CMakeLists.txt
├── README.rst
├── boards
│   └── qemu_riscv64.overlay
├── dts
│   └── bindings
│       └── test-overlay.yaml    ★これ★
├── prj.conf
├── sample.yaml
└── src
    └── main.c

# samples/hello_world/dts/bindings/test-overlay.yaml


description: |
    This binding provides AAA and BBB, something for CCC application in Zephyr.

compatible: "test-overlay"

properties:
    value1:
        type: int
        required: true
        description: |
          Identity of AAA of something. This is ...

    value2:
        type: int
        required: true
        description: |
          Identity of BBB of something. This is ...

追加した yaml ファイルは非常にシンプルで、compatible の名前と、value1, value2 という int 型のプロパティが必須だよ、ということを定義しただけです。

その他の bindings の定義については、Zephyr のマニュアル（Devicetree bindings - Zephyr Project Documentation）をご覧ください。

ファイルを追加したら改めてビルド＆実行しましょう。

$ ninja
...

[123/123] Linking C executable zephyr/zephyr.elf
Memory region         Used Size  Region Size  %age Used
             RAM:       23700 B       256 MB      0.01%
        IDT_LIST:          0 GB         2 KB      0.00%


$ ninja run

[0/1] To exit from QEMU enter: 'CTRL+a, x'[QEMU] CPU: riscv64
*** Booting Zephyr OS build v2.7.99-3416-g7dac931e3662  ***
Hello World! qemu_riscv64
value1:1
value2:10

うまく行きました。Device Tree Overlay と bindings は同じ C コードでボードごとに設定だけ変えたい場合に有用です。

この仕組みは tests 下にあるコードでよく使われています。例えば GPIO のテストがわかりやすいでしょう。2つのポートが通信できるか？割り込みが正常に入るか？などが GPIO テストの内容です。

実際に動作させるにはボードごとに配線やピン設定が違いますから、ボード A はピン 10 と 11 を使う、ボード B は 21 と 22 を使う、というようにボードごとに違う設定を与える必要があります。

設定はコードに書かずに Device Tree Overlay に逃がして、コードはテストしたい内容のみを記述することで設定もコードもすっきりする、ってわけです。

ガスガンが増えました

目次: 射的 - まとめリンク

ガスガンが増殖して 6個になりました。有名どころ＆異なる国を狙って買ってみました。有名どころは他もありますけど、さすがにもう要らないですね。射的で遊ぶにしても、同時にいくつも使わんし……。

いずれも東京マルイというメーカーのガスガンです。

イタリア: Beretta 92

アメリカ: Colt M1911

ベルギー: FN Five-seveN

オーストリア: GLOCK 19

ドイツ: H&K USP Compact

スイス: SIG SAUER P226

実銃は性能が違い（そもそも使用できる弾丸が違う、M1911 は .45 ACP、Five-seveN は 5.7x28mm マシンガンの弾、他は 9x19mm パラベラム弾）ます。しかしおもちゃであるガスガンは、見た目が違うだけで性能がほぼ全部同じです。趣味で選べば OK です。

デザインはベレッタ 92 と M1911 が好きですね。機能美＆シンプル。レールが付いているデザインはあんまり好きじゃないです。銃口側がシュッと細めのタイプが好きなんですね。たぶん。

持ちやすさは USP Compact が良かったです。他も特に不満はないです。ああ、でも M1911 と Five-seveN はグリップがでかすぎて若干持ちにくいかも？

あと説明書読んでいて驚いたんですが、操作方法が全然違います。特にセーフティー、デコックはモノによって全然違います。似た形なのに全く統一感がありません。使っている人たちは文句言わんのでしょうか？銃は不思議な世界ですね……。

メモ: 技術系？の話は Facebook から転記しておくことにした。追記。

Seagate の HDD のエラーレート

新しく Seagate ST8000VN004（SATA, 8TB）を買いました。最近の HDD にしては珍しく音がかなりうるさいです……印刷時のプリンターみたいな音がしています。音も気になるんですけど、さらに気になることがあって SMART でステータスを見てみると、

SMART Attributes Data Structure revision number: 10
Vendor Specific SMART Attributes with Thresholds:
ID# ATTRIBUTE_NAME          FLAG     VALUE WORST THRESH TYPE      UPDATED  WHEN_FAILED RAW_VALUE
  1 Raw_Read_Error_Rate     0x000f   081   068   044    Pre-fail  Always       -       129582469        ★★★★！？
  3 Spin_Up_Time            0x0003   096   096   000    Pre-fail  Always       -       0
  4 Start_Stop_Count        0x0032   100   100   020    Old_age   Always       -       2
  5 Reallocated_Sector_Ct   0x0033   100   100   010    Pre-fail  Always       -       0
  7 Seek_Error_Rate         0x000f   100   253   045    Pre-fail  Always       -       131692        ★★★★！？
  9 Power_On_Hours          0x0032   100   100   000    Old_age   Always       -       0
 10 Spin_Retry_Count        0x0013   100   100   097    Pre-fail  Always       -       0
 12 Power_Cycle_Count       0x0032   100   100   020    Old_age   Always       -       2
 18 Head_Health             0x000b   100   100   050    Pre-fail  Always       -       0
187 Reported_Uncorrect      0x0032   100   100   000    Old_age   Always       -       0
188 Command_Timeout         0x0032   100   100   000    Old_age   Always       -       0
190 Airflow_Temperature_Cel 0x0022   056   056   040    Old_age   Always       -       44 (Min/Max 34/44)
192 Power-Off_Retract_Count 0x0032   100   100   000    Old_age   Always       -       2
193 Load_Cycle_Count        0x0032   100   100   000    Old_age   Always       -       2
194 Temperature_Celsius     0x0022   044   044   000    Old_age   Always       -       44 (0 20 0 0 0)
195 Hardware_ECC_Recovered  0x001a   081   068   000    Old_age   Always       -       129582469
197 Current_Pending_Sector  0x0012   100   100   000    Old_age   Always       -       0
198 Offline_Uncorrectable   0x0010   100   100   000    Old_age   Offline      -       0
199 UDMA_CRC_Error_Count    0x003e   200   200   000    Old_age   Always       -       0
240 Head_Flying_Hours       0x0000   100   253   000    Old_age   Offline      -       0 (243 14 0)
241 Total_LBAs_Written      0x0000   100   253   000    Old_age   Offline      -       129529342
242 Total_LBAs_Read         0x0000   100   253   000    Old_age   Offline      -       53127

Raw_Read_Error_Rate や Seek_Error_Rate が凄まじい値をたたき出しています。比較対象として Western Digital WD40EFRX（SATA, 4TB）を見るといずれも 0 です。

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        ★★★★0です
  3 Spin_Up_Time            0x0027   162   162   021    Pre-fail  Always       -       6900
  4 Start_Stop_Count        0x0032   100   100   000    Old_age   Always       -       18
  5 Reallocated_Sector_Ct   0x0033   200   200   140    Pre-fail  Always       -       0
  7 Seek_Error_Rate         0x002e   200   200   000    Old_age   Always       -       0        ★★★★0です
  9 Power_On_Hours          0x0032   080   080   000    Old_age   Always       -       14956
 10 Spin_Retry_Count        0x0032   100   253   000    Old_age   Always       -       0
 11 Calibration_Retry_Count 0x0032   100   253   000    Old_age   Always       -       0
 12 Power_Cycle_Count       0x0032   100   100   000    Old_age   Always       -       16
192 Power-Off_Retract_Count 0x0032   200   200   000    Old_age   Always       -       2
193 Load_Cycle_Count        0x0032   170   170   000    Old_age   Always       -       92796
194 Temperature_Celsius     0x0022   112   100   000    Old_age   Always       -       38
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       -       20
200 Multi_Zone_Error_Rate   0x0008   100   253   000    Old_age   Offline      -       0

何だこりゃ、やられた！故障か？

どうやら正常らしい

しかし SMART で異常を検知できるほどなのに普通に読み書きできていて不思議だったので、もう少し調べてみると解説しているサイト（リンク: Seagate's Seek Error Rate, Raw Read Error Rate, and Hardware ECC Recovered SMART attributes）が見つかりました。

どうも気にしなくて良いみたいですね。試しに今まで使っていた Seagate ST4000VN008（SATA, 4TB）のステータスを見ると、Raw_Read_Error_Rate が凄い値になっています。

SMART Attributes Data Structure revision number: 10
Vendor Specific SMART Attributes with Thresholds:
ID# ATTRIBUTE_NAME          FLAG     VALUE WORST THRESH TYPE      UPDATED  WHEN_FAILED RAW_VALUE
  1 Raw_Read_Error_Rate     0x000f   082   065   044    Pre-fail  Always       -       156528383        ★★★★
  3 Spin_Up_Time            0x0003   094   094   000    Pre-fail  Always       -       0
  4 Start_Stop_Count        0x0032   100   100   020    Old_age   Always       -       36
  5 Reallocated_Sector_Ct   0x0033   100   100   010    Pre-fail  Always       -       0
  7 Seek_Error_Rate         0x000f   069   060   045    Pre-fail  Always       -       8577083        ★★★★
  9 Power_On_Hours          0x0032   100   100   000    Old_age   Always       -       153 (72 27 0)
 10 Spin_Retry_Count        0x0013   100   100   097    Pre-fail  Always       -       0
 12 Power_Cycle_Count       0x0032   100   100   020    Old_age   Always       -       13
184 End-to-End_Error        0x0032   100   100   099    Old_age   Always       -       0
187 Reported_Uncorrect      0x0032   100   100   000    Old_age   Always       -       0
188 Command_Timeout         0x0032   100   100   000    Old_age   Always       -       0
189 High_Fly_Writes         0x003a   100   100   000    Old_age   Always       -       0
190 Airflow_Temperature_Cel 0x0022   071   052   040    Old_age   Always       -       29 (Min/Max 21/33)
191 G-Sense_Error_Rate      0x0032   100   100   000    Old_age   Always       -       0
192 Power-Off_Retract_Count 0x0032   100   100   000    Old_age   Always       -       29
193 Load_Cycle_Count        0x0032   100   100   000    Old_age   Always       -       59
194 Temperature_Celsius     0x0022   029   048   000    Old_age   Always       -       29 (0 20 0 0 0)
197 Current_Pending_Sector  0x0012   100   100   000    Old_age   Always       -       0
198 Offline_Uncorrectable   0x0010   100   100   000    Old_age   Offline      -       0
199 UDMA_CRC_Error_Count    0x003e   200   200   000    Old_age   Always       -       0
240 Head_Flying_Hours       0x0000   100   253   000    Old_age   Offline      -       44 (25 151 0)
241 Total_LBAs_Written      0x0000   100   253   000    Old_age   Offline      -       10828710302
242 Total_LBAs_Read         0x0000   100   253   000    Old_age   Offline      -       112993489

故障かと思って勢いで Seagate に返品依頼をしてしまいました。故障ではないとわかったのでキャンセルしたいですが、キャンセルする方法がわかりません。頑張って探しましたが、Seagate のサイトの作りは本当にひどくて操作する気が起きなくなりました。まあ、送り返さなければそのうち消されるでしょう。もう放っておきましょう……。

HDD の異音の正体

先日（2022年 2月 12日の日記参照）購入した HDD にデータをコピーしていると、印刷中のプリンターのような「ガー、ガー」という音が発生していました。

HDD から聞こえる変なシーク音

一体何事か？故障なのか？とも思ったのですが原因がわかりました。ext4 ファイルシステムの lazyinit が原因でした。

本来 ext4 は mkfs が非常に遅く、TB 級の巨大な領域をフォーマットすると 10分以上時間が掛かります。lazyinit はこの苦痛を和らげるために mkfs で行うはずだった初期化（inode テーブルの 0 クリア）を後回しにする方式だそうです（参考: Ext4 Filesystem - Thomas-Krenn-Wiki）。

遅い mkfs を劇的に高速化する素敵な lazyinit ではありますが、mkfs のすぐ後に大量のデータを書き込む用途には不向きです。lazyinit が有効な領域をマウントすると ext4lazyinit というカーネルスレッドが定期的に書き込みに来ます。これによりシークが発生してデカい音がしますし、write の速度もかなり落ちます。

lazyinit の無効化

下記のように mkfs.ext4 のオプションで lazyinit を無効化できます。

# mkfs.ext4 -E lazy_itable_init=0,lazy_journal_init=0 /dev/sdc1

無効化することで write の速度も高速化し、異音も解決しました。

絶対に日本語を使ってはいけない Seagate のサポートサイト

Seagate のサポートサイト（リンク）は日本語に対応していてありがたいのですが、アカウントを作成する際は日本語を一切使わない方が良いです。

アカウントを「登録」する際は日本語を使っても文句を言わないのに、アカウントの「登録内容を変更」する場合は日本語を使うと文句を言われます。この時点で既におかしな挙動ではありますが、さらにおかしなことにアカウントの登録内容に日本語が含まれていると住所変更ができなくなるなどのおかしな挙動を示します。バグってる感満載です……。

もしアカウントの登録内容に日本語を含めてしまった場合、下記の手順で回避することができました。

アカウントの登録内容に日本語を使ってしまった場合

氏名に日本語を使ってアカウント登録すると「配送先住所」のところに日本語が出てきてしまいます（注: 画像は既に修正した後なので英語になっています）。困ったことに、このままだと交換の申請も住所変更も何もできなくなります。この状態を解消するには、

• 新たに英語のみのダミー住所を追加
• 日本語が使われている自分の住所 → ダミー住所へ切り替え
• 自分の住所を修正
• ダミー住所 → 自分の住所へ切り替え

とすると回避できます。ダミー住所の追加方法はわかりづらいので画像で説明します。

新たに住所を追加する

新たに英語のみのダミー住所を追加（中身は適当で良い、後で消すから）

日本語が使われている自分の住所 → ダミー住所へ切り替え

自分の住所を修正する方法は、ダミー住所を追加したときと同様です。

ダミー住所 → 自分の住所（修正後）へ切り替え

ダミー住所を消す

最近は多言語対応に失敗したサイトはあまり見かけないため、Seagate のサイトの悲惨さはかなり目立ちますね。日本での Seagate の HDD の人気を考えると、Seagate には文句が大量に来ているんじゃないでしょうか？このヘンテコなバグもいずれ修正されるでしょう。

射的 2回目

目次: 射的 - まとめリンク

秋葉原のトリガーハッピーでシューティングレンジに再チャレンジしました。初心者向けの的 9個を順不同に全て撃つモードをやっています。距離は 7m くらいですかね？測ったわけじゃないので知らんですが。

あと、的の名前を初めて知りました。G&G の M.E.T. というターゲットで、繋げる個数も可変でゲームも色々なモードがある多機能の製品みたいです。その割にはボタン 1個しか制御装置がない不思議インタフェースです。よくわからずボタンをバシバシ押していたら、モードが変わってしまって焦りました。

前回はアベレージ 20秒、ベスト 16秒ってところでしたが、今回はアベレージ 15秒、ベスト 12秒くらいでした。最近は毎日遊んでいたせい？か多少早くなったようです。楽しい。

今回は持ちにくい FN Five-seveN に代えて、ベレッタ 92（東京マルイ U.S. M9 ピストル）で挑みました。そこそこ好調でしたがかなり重い（※）のと、一発目をかなり外しました。ダブルアクションの影響でしょうかね？横方向がブレブレで全然当たりません。難しいなー……。

次にまたやるとしたら、ブレにくい M1911（シングルアクション）かグロック 19（トリガーセーフティー）がいいのかなあ？特にタイムを競う訳ではないですが、外すよりは当てる方が楽しいですし。

（※）U.S. M9 ピストルは「実銃と同じ重さ」がウリの製品で 1kg 近くあります。通常のガスガンは 700g くらいが多いかな？

液晶ボード燃える

目次: RISC-V - まとめリンク

HiFive1 に接続していた SPI 接続の液晶ディスプレイ（MSP2807）の調子がおかしいです。Raspberry Pi の USB ポートに繋ぐと HiFive1 ごと電源が落ちてしまいます。バックライトも付かず動作していないように見えます。

電力がギリギリなのか？と思って AC アダプタから直で電力を供給してみたところ、液晶ディスプレイのボードから煙と異臭が！！ボードが壊れてしまいました！

基板を見ると裏面にあるレギュレータ U1 のパッケージがコゲて穴が開いてます。回路的には 5V の供給ラインかな。他の部分は液晶で隠れていて見えませんが、壊れた可能性があります。

前は元気に動いていたのに急にどうしたんでしょうか？実はどっか短絡していておかしいまま動いていたのかなあ？？

不幸中の幸いと言いますか、AC アダプタや HiFive1 が道連れで壊れなかったのはラッキーでした。今のところそう見えるだけで壊れているかもしれないので、次回以降使うときは注意してみておかないと……。

メモ: 技術系の話は Facebook から転記しておくことにした。加筆修正。

液晶ボードが燃えた原因

目次: RISC-V - まとめリンク

昨日（2022年 2月 27日の日記参照）燃えた SPI 接続液晶ボード上のレギュレータ XC6206 ですが、燃えた原因が分かりました。GND と VCC の配線を逆に繋ぐ単純なミスでした。

HiFive1 側は GND を黒、VCC を赤にしました。しかし液晶ボード側を間違えて GND を赤、VCC を黒（＝逆に接続）にしていました。

本来 5V かけるべきところに -5V を印加した訳です。Torex の XC6206 のスペックシート（仕様書へのリンク）によれば入力定格 -0.3 〜 7V ですので -5V は定格 10倍以上。そりゃあ壊れますよ。あーあー……やっちまいました。