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 パッチをその上に載せ替えました。
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 を点滅させていました。
< 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 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 / コンテナ 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 に当てる
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） |
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 本残っていました。
[ 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、と一段ずつ
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 行）を持っています。
- 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);
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）を投入して再起動。
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に書けば手でも起動できる（健全なポートで経路の動作確認ができる）
/* 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 を叩いて経路を確認しました。
[ 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 の両方を残す）。
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 の変更点まとめ