Qua Station(RTD1295)をClaude CodeでUbuntu 26.04＋mainline Linux 6.18導入記録（7）Linux 7.2→7.3 移植編 — Wi-Fi の無言死は上流の 1 行、翌日出た 7.3 は 2 行で一発起動

シリーズ目次（Qua Station を mainline Linux で動かす連載・全 7 本）

(1) 6.18クロスビルド・Ubuntu 26.04起動・シリアルレス診断手法
(2) SATA・PCIe・Wi-Fi・LEDのハードウェア復活
(3) rootfsをSSDへ移行
(4) ext4破損インシデントとUSB2.0/PCIe診断ログ洪水の解決
(5) 番外編: 作ったのに使えなかったBluetooth SPP非常口コンソールの話
(6) 配布イメージを作って GitHub で公開する
(7) Linux 7.2→7.3 移植編 — Wi-Fi の無言死は上流の 1 行、翌日出た 7.3 は 2 行で一発起動 ← 本記事

概要

au Qua Station（Realtek RTD1295）で動かしている mainline 系カーネルを、6.18.52 → 6.18.56 → 7.2.11 → 7.3 まで、一晩と翌日の一時間で上げた記録です。

6.18.56 への更新は起動失敗 2 回＋投入事故 1 回、3 回目の投入で成功。原因は全部こちらのミス（config の取り違え・initramfs の root 探索・BOOT 領域の空き不足）
7.2.11 への移植は、RTD1295 の周辺ドライバ一式（約 1.8 万行）を載せ替えて API 変更の修正は 5 件だけで通った
ところが起動 14 秒で無言死 → 再起動ループ。pstore も空。2 回の切り分けの末、引き金は rtlwifi が 7.x で workqueue を WQ_UNBOUND にした上流の 1 行と分かった（WQ_PERCPU に戻すと通る。なぜハングするかの機構は未特定）
おまけで、6.18 ではベンダードライバが必要だった 5GHz の RTL8812AE が、7.2 の mainline rtl8821ae でそのまま繋がった
この記事を限定公開で書いている途中に Linux 7.3 が出た。悔しいので追従したら、衝突 0・修正 2 行・実機で一発起動。現在 7.3.0 で本番稼働中
で、7.3 にして何が良くなったか……何もない！（第 3 部）

結論を先に。「新しい LTS が出てから追従する」より、先に次の系に乗って痛みを一回で済ませる作戦は、この機体では正解でした。 7.2 で衝突 4 件・コンパイルエラー 5 件・直したのは 1 行。その翌日の 7.3 は衝突 0・修正 2 行。前の晩の苦労がそのまま次の版の地ならしになりました。

成果物（パッチ・config・ビルド手順）は GitHub okura1234/quastation-linux の kernel/patches-7.3.0/ にまとめてあります。素の v7.3 に git am --3way で 8 本当たることを確認済みです。

前提・環境

項目	値
機体	au Qua Station HVD1（RTD1295 / Cortex-A53×4 / RAM 2GB）
起動	USB メモリの FAT 区画に `uImage` + DTB、rootfs は SATA SSD（Ubuntu 26.04）
カーネルの土台	6.18 系: symops/monarch-6.18（WD My Cloud Home 用の RTD1295 パッチ束）+ 自分の Qua 用パッチ 24 個（okura1234/monarch-6.18 `qua-dist`）。7.x 系: 素の mainline に RTD1295 差分をパッチとして当てる形（okura1234/quastation-linux `kernel/patches-7.x/`）
ビルド機	Ubuntu 26.04 の x86 ノート、`aarch64-linux-gnu-gcc` 15.2
役割	ADS-B 受信機（RTL-SDR + readsb ほか Docker 13 コンテナ）として常時稼働中＝本番機
作業の相棒	Claude Code（調査・ビルド・記録。実機の再起動と USB の抜き差しは人間）
シリアルコンソール	無し（これが毎回効いてくる）

第 1 部: 6.18.52 → 6.18.56（symops の更新に追従）

やったこと

symops が 10 月中旬に main を 6.18.56 へ上げていたので、自分の 24 パッチをその上に載せ替えました。

rebase

git fetch upstream main            # symops/monarch-6.18
git checkout -b qua-dist-6.18.56 qua-dist
git rebase upstream/main           # 衝突 2 件

衝突は 2 件。SATA の電源 GPIO 処理は symops 側が同じ事を実装していたので自分の版を捨て、README は Qua 版を採用。ビルドは一発で通りました。

ここまでは順調。問題は投入でした。

失敗 1: 起動しない（原因: config の取り違え）

uImage を差し替えて再起動 → 前面左の赤 LED が永久点滅、5 分待っても無応答。

原因は、ビルドに使った .config が配布イメージ用のものだったこと。配布イメージは rootfs を LABEL=qua-root で探す設定で、しかも CONFIG_CMDLINE_FORCE=y。本番の SSD のラベルは別物なので、initramfs が root を見つけられずに LED を点滅させていました。

稼働機と焼いた版の差分（本質はこの 1 行）

< CONFIG_CMDLINE="... root=PARTUUID=20a83e9c-04"   ← 稼働中
> CONFIG_CMDLINE="... root=LABEL=qua-root"         ← 焼いた版

教訓: config の正は稼働機の zcat /proc/config.gz。ツリーに転がっている .config を信用しない。

失敗 2: 直したのにまだ起動しない（原因: busybox findfs は PARTUUID を知らない）

config を稼働機のものに差し替えて再ビルド → 同じ赤点滅。

journal を見ると systemd に到達した痕跡が無い。initramfs の中で止まっている。原因は、配布イメージを作った時に initramfs の root 探索を busybox の findfs に一本化していたこと。

実機の busybox で確認

$ busybox findfs LABEL=qua-2604
/dev/sdb4
$ busybox findfs PARTUUID=20a83e9c-04
Usage: findfs LABEL=label or UUID=uuid      ← PARTUUID は非対応・exit 1

本番の cmdline は root=PARTUUID=…。90 秒待って「root not found」で LED 点滅、という initramfs の仕様どおりの挙動でした。稼働中だった旧版は、この変更より前の init（/sys/class/block/*/uevent から PARTUUID を引く方式）を抱えていたので無事だった、という構図。

教訓: 配布イメージ用の変更（LABEL 前提）を本番ツリーに混ぜない。initramfs を触ったら実機の busybox で全経路を試す。

失敗 3: 投入スクリプトが BOOT を食い潰して `uImage` が 0 バイトに

3 回目の投入で、スクリプトが途中で No space left on device。BOOT 区画は 98MB しかなく、「退避 1 本＋新版 1 本」でほぼ満杯なのに、古い世代を消す行を入れ忘れていました。

もっと悪いのは、cp a && cp b の && 連結は set -e を素通りすること。失敗したまま次の rm uImage が走り、0 バイトの uImage が出来上がりました。起動中だったので ADS-B は止まりませんでしたが、実はこの夜の最初の投入でも同じ型のミスをしていて、稼働版 uImage（9/21 ビルド）の唯一のコピーを rm で失っています。cmp の結果を見てから消していれば防げました。

教訓: 投入スクリプトは「消す物」と df を先に書く。cmp は単独行にして set -e で止める。

4 回目で成功

6.18.56-run43 復帰後

6.18.56-run43 / コンテナ 13 / Wi-Fi 2 枚とも UP / RTL-SDR・USB-LAN・起動 USB 全部あり
PCIe の診断ログ行: 121/boot → 15/boot

第 2 部: Linux 7.2.11 への移植

動機

mainline 7.2 には RTD1295 の周辺ドライバ（クロック・SATA・PCIe・USB PHY・GPIO 等）がほぼ無い。symops も 6.18 LTS に腰を据えていて 7 系の計画は無し。つまり前例ゼロ、全部自前。

それでも「年末の次期 LTS が出てから追従する」より、今 7.2 に載せて痛みを一回で済ませておけば、LTS までの差分は 1〜2 リリース分で済む、という読みで着手しました。

差分の正体を測る

まず「どれだけ載せ替えるのか」を数字にしました。

差分の採取

git diff --stat v6.18.56 qua-dist-6.18.56
#  494 files changed, 31460 insertions(+), 22 deletions(-)
git diff --stat v6.18.56 qua-dist-6.18.56 -- arch drivers include kernel
#   72 files changed, 17817 insertions(+), 4 deletions(-)   ← カーネルソース分

削除行がほぼゼロ。つまり **RTD1295 対応は「既存コードの改変」ではなく「ドライバの追加」**で出来ていて、既存ファイルに触っているのは Kconfig/Makefile の追記と小さな改変だけ。これなら衝突で死ぬ種類の作業ではない、と判断できました。

v7.2.11 に当てる

worktree で当てる

git worktree add --detach ../linux-7.2 v7.2.11
cd ../linux-7.2
git apply --3way rtd1295-src.patch
git diff --name-only --diff-filter=U
# arch/arm64/boot/dts/realtek/Makefile
# drivers/net/ethernet/realtek/Kconfig
# drivers/power/reset/Kconfig
# drivers/power/reset/Makefile          ← 衝突 4 件、全部「両方残す」

コンパイルエラーは 5 件（4 ファイル）

フルビルドの前に、RTD 関連のディレクトリだけを make -k でコンパイルしてエラーを数えました。API の変更に当たったのは次の 4 ファイルです。

ファイル	7.2 で何が変わったか	対処
`clk/realtek/clk-rtd129x-scpu.c`	`clk_ops.round_rate` 廃止	`.determine_rate` に書き換え
`i2c/busses/i2c-rtk.c`	`linux/of_gpio.h` 削除	include を落とすだけ（使っていなかった）
`soc/realtek/rtk-memory-remap.c`	`struct reserved_mem` から `fdt_node` が消えた	`/reserved-memory` 配下を unit 名で再検索
`pci/controller/pcie-rtd129x.c`	`pci_msi_create_irq_domain` 廃止	`msi_create_parent_irq_domain` + `msi_parent_ops` に移植（Kconfig に `select IRQ_MSI_LIB`）

drivers/clk/realtek/clk-rtd129x-scpu.c（round_rate → determine_rate）

static int rtd129x_scpu_clk_determine_rate(struct clk_hw *hw,
					   struct clk_rate_request *req)
{
	const struct rtd129x_scpu_div *dv = rtd129x_scpu_find_div(req->rate);
	const struct rtd129x_scpu_freq *fv;

	if (!dv)
		return -EINVAL;
	fv = rtd129x_scpu_find_freq(req->rate * dv->div);
	if (!fv)
		return -EINVAL;
	req->rate = fv->rate / dv->div;
	return 0;
}

MSI は altera の実装を手本に、親ドメインだけ提供して per-device ドメインは msi_lib に任せる形へ。6.18 時代に踏んだ「affinity 未実装の親チップを呼ばれて NULL にジャンプ」の罠は、msi-lib も MSI_FLAG_NO_AFFINITY を見てくれるので、required_flags に入れておけば per-device ドメインにも強制されます。なお起動後に pcie-rtd129x の alloc_workqueue が WQ_PERCPU/WQ_UNBOUND 未指定の WARNING を 1 件出していて、これは後で WQ_PERCPU を足しました（無害）。

フルビルド: error 0 / warning 0。ここまで着手から約 2 時間。

起動 14 秒で無言死 → 再起動ループ

uImage を投入して再起動。ping が 1 回だけ返り、消え、44 秒後にまた 1 回返り、消える。前面の LED が消えて点く、を繰り返す。

6.18 に戻して journal を掘ると、7.2 の boot が 2 本残っていました。

7.2.11 の boot の最後の行（2 回とも同じ所）

[   13.671143] systemd-networkd[296]: wlan1: Configuring with /etc/systemd/network/16-wifi24-8192ee-fallback.network.
[   13.688458] systemd[1]: Found device sys-subsystem-net-devices-wlan0.device - RTL8812AE ...
...
[   13.938284] systemd[1]: Started systemd-rfkill.service - Load/Save RF Kill Switch Status.
（ここで途絶）

systemd には到達している（rootfs は OK）
途絶えるのは Wi-Fi のインターフェースを up する瞬間
CONFIG_PSTORE_CONSOLE=y なのに ramoops が空 → panic ではなく無言のハング、約 40 秒で watchdog 相当の再起動

切り分け 1: MSI を切っても同じ

真っ先に疑ったのは自分が書き換えた PCIe の MSI。RTD129X_PCIE_USE_MSI 0 にして INTx 経路で焼き直し → 同じ 14 秒で死亡。MSI は無罪。

切り分け 2: Wi-Fi ドライバを抜いたら上がった

rtlwifi はモジュールなので、modules から rtlwifi/ ディレクトリごと外して投入 → 起動して稼働。SATA・USB・xhci・Docker・Bluetooth・zram、全部 7.2 で動いている。死因は Wi-Fi の起動経路だけに絞れました。

ここで作戦を変えました。生きている 7.2 の上で、Wi-Fi を手で起こして死ぬ瞬間を見る。

再起動なしで死因を取る型

疑いのある修正を入れた rtlwifi の .ko だけを再リンク（make M=drivers/net/wireless/realtek/rtlwifi modules、LOCALVERSION は稼働版に合わせる）
実機の /tmp（tmpfs）に置く → 再起動すれば消えるので、死んでも Wi-Fi 無しの状態に自動復帰する
netconsole を母艦へ向けて張る
insmod → ip link set up → iw scan → wpa_supplicant、と一段ずつ

実機側（netconsole）

modprobe netconsole netconsole=6666@<実機IP>/eth0,6666@<母艦IP>/<母艦MAC>
echo 8 > /proc/sys/kernel/printk     # ← これを忘れると info 級が母艦に届かない

母艦側

nc -ulk 6666 | tee netconsole.log

引き金: rtlwifi の workqueue が 7.x で `WQ_UNBOUND` になっていた

6.18 と 7.2 の上流 rtlwifi の差分は 10 ファイル・+51/−71 行と小さく、生の MMIO アクセスの追加は無し。その中で目についたのがこれでした。なお、こちらのツリーは rtlwifi の pci.c に独自パッチ（RTD129x のページ式 MMIO ウィンドウ経由でレジスタを読み書きする 49 行）を持っています。

drivers/net/wireless/realtek/rtlwifi/base.c（6.18.56 → 7.2.11 の上流変更）

-	wq = alloc_workqueue("%s", 0, 0, rtlpriv->cfg->name);
+	wq = alloc_workqueue("%s", WQ_UNBOUND, 0, rtlpriv->cfg->name);

2025 年 11 月の上流パッチ（wifi: rtlwifi: add WQ_UNBOUND to alloc_workqueue users）で、rtlwifi の workqueue が per-CPU から unbound（どの CPU でも走る）になっていました。workqueue の WQ_PERCPU/WQ_UNBOUND の明示は 2025〜26 年に各ドライバで見直しが続いていて、wireless 系でも WQ_PERCPU を付け直すパッチが流れています（linux-wireless 2026-01）。

推測: RTD1295 は CPU0 周りが怪しい個体で（symops のツリーには AHCI 絡みの CPU0 割り込み喪失ハングへの sched/idle ワークアラウンドが入っていて、機構は不明とされている）、hw 起動時の work が別 CPU に飛ぶと、独自パッチの MMIO 窓の排他か SoC 側の何かが崩れる、という筋を疑っています。機構は未特定。まず 1 行戻して試しました。

修正

-	wq = alloc_workqueue("%s", WQ_UNBOUND, 0, rtlpriv->cfg->name);
+	wq = alloc_workqueue("%s", WQ_PERCPU, 0, rtlpriv->cfg->name);

生きた 7.2 の上での結果（netconsole 監視下・再起動なし）

insmod rtl8192ee      → probe OK、wlan0 生成
ip link set wlan0 up  → 生存
iw dev wlan0 scan     → BSS 10 件
wpa_supplicant        → wpa_state=COMPLETED、DHCP で IP 取得
ping -I wlan0 <GW>    → 応答

修正前の rtlwifi は同じカーネルの起動時に死に、修正後は up・scan・接続・疎通まで通った。引き金はこの 1 行で確定、と判断しました（なぜ落ちるかは別途）。

フル版で再起動 → Wi-Fi 込みで起動

rtlwifi 入りのフルビルド（7x05）を投入して再起動。

7.2.11-7x05

SSH 到達: uptime 22 秒（6.18 より体感で速い。同じ指標での比較は未計測）
コンテナ 13 / readsb 受信中 / USB 3 点 / Bluetooth active / WARNING 0
wlan0: 5GHz（RTL8812AE）freq=5220 wpa_state=COMPLETED   ← mainline rtl8821ae で接続

6.18 では mainline の rtl8821ae が Init MAC failed で動かず、起動時にベンダーの 8812ae.ko へバインドし直す service を仕込んでいました。7.2 ではそれが不要でした。

2.4GHz のリンク落ちにホストドライバ側で手を打つ（7x06）

「起動によって 2.4GHz が居ない」の正体は、列挙が済んだ後の数秒でその PCIe リンクが黙って落ちることでした。ホストドライバの割り込みハンドラは「リンクが上がった」しか見ておらず、落ちたことは誰も気づかず、次にドライバがコンフィグを読んだ時にタイムアウトする。生きている側のポートで ASPM Disabled・policy default を確認したので、ASPM が原因の線は薄い。

そこでホストドライバに「再トレーニング」の経路を足しました（kernel/patches-7.2.11/0006）。

init の末尾にあったリンク立ち上げ（EP の reset GPIO を叩く → LTSSM 有効化 → リンクアップ待ち → ウィンドウ設定）を rtd129x_pcie_link_bringup() に切り出し
コンフィグアクセスのタイムアウトが 3 回続いたら retrain_work を予約。死んだデバイスを外し → bringup → 上がったら既存の hotplug 用の work で slot を再スキャン。レート制限 10 秒
sysfs の retrain に書けば手でも起動できる（健全なポートで経路の動作確認ができる）

drivers/pci/controller/pcie-rtd129x.c

/* cfg アクセスの timeout が続いたら再トレーニングを予約する */
static void rtd129x_pcie_note_cfg_timeout(struct rtd129x_pcie_priv *data)
{
	if (++data->cfg_timeouts >= 3 && data->wq)
		queue_work(data->wq, &data->retrain_work);
}

投入した 7x06 では、その起動は 2.4GHz も最初から健全でした（3 回に 2 回の当たり側）。そこで健全なポートに手で retrain を叩いて経路を確認しました。

journalctl -k

[   87.368084] pcie-rtd129x 9804e000.pci: retrain: link lost (MAC_ST 0x0001ad10), resetting EP and retraining
[   87.380173] wlan1: deauthenticating ... (Reason: 3=DEAUTH_LEAVING)
[   87.647164] pcie-rtd129x 9804e000.pci: retrain: link up, rescanning slot
[   87.660107] pcie-rtd129x 9804e000.pci: scan slot (1)
[   87.683679] rtl8192ee 0000:00:00.0: enabling device (0000 -> 0002)
[   89.420056] wlan1: authenticated

EP リセットからリンクアップまで 0.3 秒、その後自動で再列挙されてドライバが付き直し、wlan1 は元の IP で復帰しました。本物の失敗（3 回に 1 回）で自動発火するかは、次の数回の起動で見ます。レビューで指摘された点（hotplug 用の work との競合）は、workqueue を ordered にして直列化し、初回列挙中は発火しないようにしてから焼きました。

第 3 部: この記事を書いている途中で Linux 7.3 が出た

7.2.11 に上げきって寝落ちし、起きてこの記事を限定公開で書いていたら、Linux 7.3 がリリースされていました（kernel.org の日付で 2026-10-18、日本時間だと月曜の朝）。よりにもよって。悔しいので、もう一度ビルドしました。

移植: 衝突 0、修正 2 行

7x06 の差分（v7.2.11 → 7x06、約 575KB）をそのまま v7.3 に当てました。

git diff --binary v7.2.11 HEAD > qua-7x06-delta.patch   # 7.2 の作業ツリーで
git worktree add --detach ../linux-7.3 v7.3
cd ../linux-7.3 && git apply --3way ../qua-7x06-delta.patch
git diff --name-only --diff-filter=U    # → 何も出ない（衝突 0）

config は olddefconfig で、消えたのは上流で廃止・改名された 4 項目だけ（PROC_SYSCTL、ARM64_WORKAROUND_REPEAT_TLBI → …_SYNC など）。RTD1295 関係は全部残りました。

-k 付きでフルビルドして出たエラーは 1 種類・2 か所 だけです。

drivers/irqchip/irq-rtd129x.c:290: error: implicit declaration of function 'irq_domain_add_linear';
    did you mean 'irq_domain_create_linear'?
drivers/pci/controller/pcie-rtd129x.c:818: （同じ）

7.3 で古い irq_domain_add_linear() が削除されたので、fwnode を取る版に置き換えるだけです。

-	rtk_domain = irq_domain_add_linear(np, nr_irq * IRQ_INMUX,
+	rtk_domain = irq_domain_create_linear(of_fwnode_handle(np), nr_irq * IRQ_INMUX,

再ビルドで make exit=0、Image 17,775,104 バイト、7.3.0-7x07。警告 1 件は MSI を切っている影響で使われなくなった変数でした。

実機投入: 一発起動

uImage 化（text_offset 0x280000、末尾 512KB ゼロ、end < 0x1b00000 の検算）、DTB は 7x06 と同一 sha（差し替え不要）、modules を tar --keep-directory-symlink で展開。BOOT 区画が 2.2MB しか空いていなかったので、一世代前の 7x05 を消して置きました（戻し先は 7x06 と 6.18.56 の両方を残す）。

7.3.0-7x07（reboot 22:29:40）

22:31:52 ping=UP 7.3.0-7x07 uptime 22.25
eth0  192.168.1.93 UP / wlan0 5GHz .57 UP / wlan1 2.4GHz .58 UP   ← 3 枚全部、初回で
Docker 13 / Bluetooth active / failed unit 0 / PCIe cfg timeout 0

6.18.56 のときは 4 回目、7.2 のときは 6 版目でやっと上がったのに、7.3 は一発でした。運ではなくて、7.2 で全部の穴に落ちておいたので、7.3 で落ちる穴が残っていなかっただけです。

ひとつだけ事故未遂を書いておくと、DTB をビルドツリーから取るときに Claude Code のグロブが外れて、Synology DS418j の DTB を掴んでいました。sha が 7x06 と違ったので気づいて取り直しましたが、気づかず焼いていたら赤 LED の夜が再開していたはずです。投入スクリプトには「DTB の sha が既知の値でなければ止まる」関門を足しました。

で、7.3 で何が良くなるのか

kernelnewbies の Linux 7.3 まとめを見ながら、この機体に効くかどうかを確かめました。

7.3 の目玉	Qua Station に効くか
性能の低い GPU の VRAM 管理を改善	❌ GPU（mali）は使っていない
sched_ext の cgroup ごとのスケジューラ	❌ 使い道がない
ext4 / btrfs の性能改善	🟡 rootfs は ext4。ただしボトルネックは USB-SATA ブリッジと A53 なので、差が出るかは測ってみないと分からない
failfs ＋ `fchroot(2)`	❌
SMB サーバーの Apple Time Machine 対応	❌ Samba を動かしていない
FUSE io_uring、`RWF_DONTCACHE`	❌

何もない！！

ADS-B で受かる飛行機の数は増えません。起動が速くなるわけでもありません。強いて挙げるなら、uname -r の数字が 1 つ増えて、ちょっと気分がいいくらいです。

そもそも 4.9 の頃から何が増えたのか

ついでに白状しておくと、この連載を (1) から読み返しても、メーカー出荷の 4.9 の頃と比べて増えた機能は、実はほとんどありません。 この箱の仕事は ADS-B の受信で、それは 4.9 でも 6.18 でも 7.3 でも同じように動きます。

7 本分の記事を使って手に入れたものを正直に並べると、こうなります。

5GHz の Wi-Fi（RTL8812AE）が繋がるようになった
以上

……本当に以上です。あとは「Ubuntu 26.04 が載る」「セキュリティ修正が届く側にいる」「LTS の寿命を気にしなくてよくなる」といった、使っていて体感できない類のものばかりです。メーカーが 4.9 のまま放置した判断は、商売としてはたぶん正しかったのだと思います。

それでも上げる理由は、①6.18 LTS もいつか終わるので、乗り換え先を今のうちに作っておく、②セキュリティ修正が届く側にいる、の 2 つです。あとは、自己満足です。

$ uname -r
7.3.0-7x07

綺麗な顔してるだろ。これ、最新カーネルなんだぜ。

元ネタは死んでいる側の台詞なので、panic していたら使えないところでした。起動して Wi-Fi が 2 枚とも繋がったので、言ってよいことにします。

詰まったポイントと原因（まとめ）

#	症状	真因	対処
1	6.18.56 が起動しない（赤点滅）	配布イメージ用 `.config`（`CMDLINE_FORCE` + `root=LABEL=`）	稼働機の `/proc/config.gz` を基準に
2	直しても同じ赤点滅	initramfs の busybox `findfs` が `PARTUUID=` 非対応	`/sys/class/block/*/uevent` から引く方式を復活
3	投入途中で `uImage` が 0 バイト	BOOT 98MB の空き不足 + `&&` 連結が `set -e` を素通り	消す物と `df` を先に、`cmp` を単独行に
4	7.2 で起動 14 秒・Wi-Fi up の瞬間に無言死	引き金は rtlwifi の `alloc_workqueue(… WQ_UNBOUND …)`（7.x 上流変更）。機構は未特定	`WQ_PERCPU` に戻す 1 行
5	7.2 ビルドで `r8169soc.c` がエラー	NETPOLL 有効化で内蔵 GMAC ドライバの古いコードが露出	Qua は GMAC 不使用なので無効化（副作用: USB-LAN が `eth1`→`eth0`）
6	7.2 起動時の WARNING	`pcie-rtd129x` の `alloc_workqueue` に `WQ_PERCPU` 未指定	追加
7	2.4GHz の Wi-Fi が起動によって居ない	その PCIe ポートのリンクが列挙後に落ちる（6.18/7.2 共通・9 回中 3 回）	ホストドライバに自動再トレーニングを追加（後述）

シリアルコンソール無しで真因に辿り着けた決め手は、(a) journal の boot 境界で「死ぬ局面」を固定できたこと、(b) pstore が空＝panic ではないと分かったこと、(c) ドライバを抜いた版で土台の健全性を先に確定したこと、(d) モジュールを tmpfs に置いて「死んでも自動復帰」の形で生きた機体上で試せたこと、の 4 つでした。

結果・振り返り

6.18.52 → 7.2.11 を一晩で、7.3 を翌日の一時間で。再起動 9 回、USB メモリの抜き差し 4 回（全部人間の手）
7.2 の土台は健全。Wi-Fi は上流の 1 行が原因で、修正後は 2.4GHz・5GHz とも動作確認
7.3 は衝突 0・修正 2 行・一発起動。「次の版が出たら差分を当て直す」型が 2 回連続で成立した
現在 7.3.0-7x07 で本番稼働中。BOOT に 7.2.11（uImage.7x06）と 6.18.56（uImage.run43）を戻し先として温存
起動が体感で速くなった（SSH 到達まで uptime 22 秒。6.18 側は同条件で未計測）。5GHz のベンダードライバ依存が消えた
GitHub の quastation-linux は 7.3 を主系統、6.18 を安定系統・戻し先という構成に組み替えた

残課題

2.4GHz（RTL8192EE）の PCIe リンクが間欠的に立ち上がらない（今夜 9 回中 3 回・6.18 でも発生＝カーネル版と無関係）。ホストドライバ側でリンクのリトライを足すか、remove 経路を直して生きたまま再初期化できるようにするのが次の課題
MSI は切り分け以降 off のまま。死因は WQ だったので on に戻せる見込み（未確認）
パッチは「汚いけど動く」状態。本流（mainline）への投稿は、書き直し・レビュー往復・実機 1 台での検証が趣味の範囲を超えるのでしない。代わりに、動作を変えない範囲で自分用に整理する（巨大な 1 本のパッチを主題別に分ける、実験用スイッチを整理する）予定
上流への報告: rtlwifi の WQ_UNBOUND 化でこの SoC が無言ハングする件。ただし自前の paged MMIO パッチ側の排他不足が露出しただけの可能性が消せていないので、そこを切り分けてから

Claude Code との分担について

今回も調査・ビルド・切り分けの設計・記録は Claude Code、実機の再起動と USB の抜き差しは人間、という分担でした。本番機の起動領域を書き換えるコマンドは Claude Code の安全機構に 2 回止められ、結局スクリプトにして人間が実行する形に落ち着きました。面倒ではありましたが、「本番機の起動領域を AI が黙って書き換えない」という縛りとしては正しく働いていたと思います。

一方で、失敗 1〜3 はどれも Claude Code 側の手順の甘さ（config をツリーから取った、退避を確認せず rm した、空き容量を計算しなかった）が原因で、それぞれ手順書に関門として書き足しました。

よくある疑問 3 つ（別セッションの Claude からの質問に答えたもの）

稼働後に別の Claude Code セッションが実機を見て、作業した側に投げてきた質問です。読む人も同じところを気にすると思うので、そのまま載せます。

Q1. wlan0 が UP なのは意図的? 有線と同一 LAN の 2 本繋ぎは ssh が固まるから使わないと決めていたはず。

6.18 時代と同じ構成で、今回は変えていません。決めていたのは「ssh の経路に wlan0 の IP を使わない」であって「wlan を上げない」ではない。Wi-Fi は有線が死んだ時の予備回線。

Q2. rtl8192ee（2.4GHz）の PCIe probe 失敗は 6.18 でも出ていた既知事象? 7.2 で新規? 実害は?

当初は「7.2 で初観測」と答えましたが、journal を boot ごとに数え直すと違いました。cfg read timed out（その PCIe ポートへのコンフィグ読み出しがタイムアウト＝リンクが落ちている）は、同じ夜の 6.18.56 の起動でも 2 回出ていました。9 回の起動で 3 回、カーネル版と無関係。つまり 2.4GHz 側の PCIe リンクが間欠的に立ち上がらない、ハード寄りの現象です。生きたままの復旧は試しましたが、remove+rescan は無反応、ホストドライバの unbind→bind は host probe failed (-28)（remove 経路が資源を返していない）で不可。復旧は再起動のみ。実害は 2.4GHz の予備回線がその起動で不在になるだけで、主経路・5GHz・ADS-B には影響なし。

Q3. 6.18 → 7.2 で何を変えた? NIC 名が eth1 → eth0 になった理由は?（7.2 → 7.3 はこれに irq_domain_create_linear の 2 行を足しただけ）

カーネル: v7.2.11 に RTD1295 差分（72 ファイル・+17.8k 行）を当て、API 修正 5 件 + rtlwifi の WQ_PERCPU 戻し
DTS/DTB: 変更なし（7.2 の DTB は 6.18 と同一 sha）
config: 稼働機の 6.18 config を olddefconfig。意図した差分は CONFIG_R8169SOC=n、CONFIG_NETCONSOLE=m、PCIe MSI off（切り分けの名残）の 3 つ
eth1 → eth0: 内蔵 GMAC のドライバ R8169SOC を切ったので、GMAC が eth0 を取らなくなり、USB-LAN（r8152）が eth0 に繰り上がった。.network が MAC 一致なので IP は付く。名前決め打ちのスクリプトだけ注意
initramfs: busybox findfs が PARTUUID= 非対応だったのを修正（これは 6.18.56 側の不起動の真因でもあった）

参考リンク

symops/monarch-6.18 — WD My Cloud Home 用 RTD1295 カーネル。本機の土台
okura1234/monarch-6.18 — Qua Station 向けパッチ（qua-dist ブランチ・6.18 系）
okura1234/quastation-linux — 配布セット。kernel/patches-7.3.0/（8 本）・kernel/patches-7.2.11/・config・ビルドスクリプト
wifi: rtlwifi: add WQ_UNBOUND to alloc_workqueue users — 今回の真因となった上流変更
linux-wireless: wireless 系ドライバの workqueue に WQ_PERCPU を付け直すスレッド（2026-01）
kernel.org releases — 7.3 / 7.2.11 / 6.18.57 の時点情報
Kernel Newbies: Linux 7.3 — 7.3 の変更点まとめ