Raspberry Piで見かけた「irq/173-vc4 hdmi hpd」は何者か

はじめに htop を眺めていたらこんな名前のスレッドが並んでいた。 irq/173-vc4 hdmi hpd connected irq/174-vc4 hdmi hpd disconnected irq/175-vc4 hdmi cec rx irq/176-vc4 hdmi cec tx HDMIは挿していないのに connected も disconnected もいるので、少し気になって調べた。 調べた範囲では、HDMIドライバが作る割り込み処理用のカーネルスレッドで、特に異常なものではなさそう。 以下はそのメモ なお番号は環境によって違う。 名前の読み方 部分 意味 irq/173 IRQ番号173の割り込みを処理するカーネルスレッド vc4 Raspberry Piのディスプレイ周りを担当するLinuxのDRMドライバ hpd Hot Plug Detect。HDMIの抜き挿しの検知 cec HDMI経由でテレビなどを操作する仕組み。rxが受信、txが送信 なぜHDMIを挿していなくてもいるのか カーネルのソースを見ると、vc4のHDMIドライバは初期化のときに devm_request_threaded_irq() で割り込みを登録している。このとき渡す名前の文字列が、そのままスレッド名(irq/番号-名前)になる。 以下はLinux mainlineのコードをさらに簡略化したもの。 Raspberry Pi OSのカーネルは独自のツリーなので細部は違うかもしれない。 /* drivers/gpu/drm/vc4/vc4_hdmi.c より */ ret = devm_request_threaded_irq(&pdev->dev, hpd, NULL, vc4_hdmi_hpd_irq_thread, IRQF_ONESHOT, "vc4 hdmi hpd connected", vc4_hdmi); つまりスレッドは HDMIが挿さったとき ではなく ドライバが割り込みの待ち受けを登録したとき に作られる。 ...

2026年10月20日 · 1 min

Raspberry Pi 2台構成のWiFi APでSSIDが起動時に出ない問題を解決した

構成 自宅NWの冗長化目的で Raspberry Pi を2台使い、WiFiアクセスポイントを組んでいる。 ホスト名 チャンネル SSID pi-1 1 your-ssid pi-2 11 your-ssid 同一SSIDで別チャンネルにする構成は ESS(Extended Service Set) と呼ばれ、クライアントが自動的に電波の強い方に接続する。WPA2-PSKで普通に成立する冗長化構成。 ブリッジ構成で bridge interface(br0)にWiFiインタフェース(wlan0)を参加させ、hostapdで電波を飛ばしている。 問題 OS再起動後、SSIDが片方または両方スキャンに出ない。 systemctl status hostapd は active (running) エラーログも一見出ていない hostapdを手動で再起動すると出る 調査 チャンネルの干渉を疑う 最初にhostapd.confのチャンネル設定を確認した。 2.4GHz帯で実際に干渉しないチャンネルは 1、6、11 の3つだけ。元の設定は6と7だったため、ほぼ完全に干渉していた。 ch6 --|-- ch7 --|-- ← 隣接していてほぼ被る チャンネルを1と11に変更した。 # pi-1 channel=1 # pi-2 channel=11 BSSIDレベルで電波を確認 sudo iw dev wlan0 scan | grep -E "BSS |SSID|freq|signal" BSS xx:xx:xx:xx:xx:xx(on wlan0) freq: 2462 signal: -15.00 dBm SSID: your-ssid BSS xx:xx:xx:xx:xx:xx(on wlan0) freq: 2412 signal: -68.00 dBm SSID: your-ssid 両台ともビーコンは出ていた。ESSとして動作は成立している。 ...

2026年5月6日 · 2 min

自宅NWをKeepalivedとdnsmasqで作り直した話

背景 自宅のネットワーク構成が辛かった。 具体的には以下の問題があった。 ルータが1台構成で、死んだら自宅NW全滅 メンテナンスで定期的に落としたいとかあっても、コストが大きい DNS/DHCPがルータに同居していて、役割が混在している WireGuardで外部接続していたが、外部からの入り方がだるい。 特に「冗長化したい」という気持ちは何年も前からあったが、DNSとDHCPの同期という難問の前に何度も挫折してきた。 結論からいえば、DNS,DHCPの冗長化は諦めた。 諦めた上で出口のルータとDNS、DHCPは役割を分けた上で出口のルータとWIFIルータのみ冗長化を実施した。 設計方針 過去の失敗から学んだ一番の教訓はやはり「DNS/DHCPの冗長化は難しい」ということだ。 理論上可能ではあるが、私は万年初級自宅インフラエンジニアでいつまで経ってもできる目処が立たない。 それでいて、生成AIという過ぎた兵器を持ってしても、この問題は解決しなかったので、難しいというよりは不可能とした。 2台のサーバでDHCPを冗長化しようとすると、リースの同期問題が必ず発生する。同期ツールを使ったりしたが、どうしても同期しきれなかった。 そこで今回は思い切って諦めた上で役割を分離する方針にした。 ルータ(冗長化) → GWとTailscaleだけ担当 AP → hostapdのみ DNS/DHCP → 専用機1台に集約(冗長化しない) DNSとDHCPは単一障害点になるが、自宅ラボであれば許容範囲だと判断した。 てかどうしようもない。 構成 使用機材はすべてRaspberry Pi。封印していたタワーからも引っ張り出した。 ホスト 役割 ルータA (MASTER) Keepalived + Tailscale ルータB (BACKUP) Keepalived + Tailscale DNS/DHCP機 dnsmasq専用 AP x2 WIFI冗長化 ネットワークセグメントはひとつ。VIPをデフォルトゲートウェイ兼DNSとして各クライアントに配布する。 Keepalivedの設定 まずルータ2台にKeepalivedを入れる。 sudo apt install -y keepalived MASTER側の設定: vrrp_instance VI_1 { state MASTER interface lan-if virtual_router_id 51 priority 100 advert_int 1 authentication { auth_type PASS auth_pass xxxxxxxx } virtual_ipaddress { 192.168.xx.1/24 } } BACKUP側は state BACKUP と priority 90 に変えるだけ。シンプルだ。 ...

2026年4月18日 · 2 min