panic(cpu 1 caller 0xfffffe001e36d0d0): DCP PANIC – ASSERT!AppleDCPDPTXPowerController.cpp:564 No device added after powering on the rails. HPD=0 – dcpav(27)
ASSERT!AppleDCPDPTXPowerController.cpp:564 No device added after powering on the rails. HPD=0
RTKit: RTKit-2758.40.19.release – Client: AppleDCP-811.40.8~1973-ipad14dcp.RELEASE
!UUID: a1000010-2140-1ed5-a178-80d201401ed5
ASLR slide: 0x00000000002d8000
macOS SequoiaにアップデートしたM2 MacBook Air、DCP PANICが頻発するようになりました。
macOS Sequoia 15.0.1、15.1の頃は、スリープ復帰後、macOSが再起動するようなことが毎日1回は発生する、そんな日常もありました。
macOS Sequoia 15.2にアップデート後、なぜかその頻度は低下し、1 week程度は持つような感じになっています。
フォーラム等ではスリープさせないようにするのが一つの手段のようですね。macやろうなのかは、ノーガード戦法です。標準的なスリープを維持しています。その状況でも発生頻度は下がっています。
同じ症状の方は、macOSを最新にアップデートしてみると、改善するかもしれません。
この先の内容読んでも、理解深めるだけで、解決はしないですm(_ _)m
DCPってなに？AppleDCPDPTXPowerControllerって？
DCPは、Display Co-Processorの略語。Display周りでCPUに変わって専用処理を担うものってことですかね。
AppleDCPDPTXPowerControllerは、Apple/DCP/DP/TXPowerContolloerに分解することができます。
AppleのDCP周りのDP[ディスプレイポート？]のTXPower（送信出力）コントローラーってことでしょうか。送信、受信という意味でTX/RXという用語をよく利用します。
No device added after powering on the rails. railsはレールなんでしょうか？これがよくわかってないです。直訳すると「レールの電源を入れた後にデバイスが追加されませんでした。」ですね。スリープ復帰後の手続きで本来あるべきデバイスが追加されなった？ってことでしょうか。
ここで言うデバイスは外付けではなく、内蔵のRetinaディスプレイを指しているのかなぁ。スリープ復帰後、内蔵ディスプレイを認識できなかったってことかなぁ・・とよくわかりません。Type-C接続で外付けディスプレイを使うこともあります。あり、なしどちらでもDCP PANICは発生していました。
DCP PANIC – ASSERT!AppleDCPDPTXPowerController.cpp:564 No device added after powering on the rails. HPD=0 – dcpav(27)を読み解くと
ASSERT!はよくあるデバッグの仕組みだと思います。テスト段階でよく利用されます。正解ではない場合、例外出力で記録する、本来、本番環境である我々に届いたmacOSでは動いていては困るようなソースが埋め込まれたままになっていると推測されます。
AppleDCPDPTXPowerController.cpp:564 そのエラーが発生した場所が564行目です。
No device added after powering on the rails. ASSERT文に埋め込めていたテキスト文です。
HPD=0 – dcpav(27) こちらもASSERT文に埋め込まれていたテキスト文で、数値は動作に応じて反映されているものと考えられます。HPDはHot Plug Deleteの略だとするとHPD=0はディスプレイケーブルの信号検知なし、と読み取れます。dcpavはAV出力系かなぁ？よくわかりません。
例えばこんな感じのコードが564行目に埋め込まれているんじゃないでしょうか？
assert(条件, “No device added after powering on the rails. ?=? – ?(?)”);
条件が成立して、ASSERT!が発生します。
DCP PANICの原因は？
macOS Sonoma利用中はDCP PANICというかPANIC自体発生は皆無でした。macOS Sequoiaアップデート後、APFS周り（AppleAPFSMediaBSDClient、AppleAPFSVolumeBSDClient）のPanicが発生するようになり、fsckで改善できた後、DCP PANICが頻発することとなりました。
DCP PANIC同様の症状は、アップルのフォーラムでも議論されていて、ハードウェア（TCON、ふたの角度センサー、ディスプレイ）の交換で直ったとの報告もありました。
ただコミュニティには多数の報告があります。衝撃や力を加えてmacのハードウェアを壊す、そんなことが多発するものでしょうか？
という疑問と、もともとmacOS Sonomaでは全く問題なかったことから、macOS Sequoiaのバグと思っています。申し訳ないです、裏付けは全くありません。妄想の可能性もあります。
DCP PANICはM2だけ？他でも出ているようです
AppleのコミュニティをリサーチするとDCP PANIC自体はM1、M3でも報告があるようです。
ASSERT!AppleDCPDPTXPowerController.cpp:564 No device added after powering on the rails.のパターンは、M2 MacBook Air特有っぽい感じです。このエラーのコミュニティ初めての報告は、2024/6/26discussionsのようです。
DCP PANICには以下のような種類があるようです。
- M1 MacBook Pro DCP PANIC – IOMFB int_handler_gated: failure: axi_rd_error
- M1 MacBook Pro DCP PANIC – ASSERT: AFKWorkloop_rtkit.cpp:251: [status == RTK_ST_OK]
- M3 MacBook Pro DCP PANIC – program_swap: Async Swap request landing on unsupported platform. Force panic
- M3 MacBook Pro DCP PANIC – apt firmware: piod ma_tagging.c:495 piodma_transaction_not_completed_tsq() → タイムマシン復元後直ったような記載ありdiscussions
macOSが問題で再起動するとレポートを送る仕組みがありますが
/System/Library/CoreServices/ReportCrash、落ちてます。
最近コンソールで見たところ、落ちまくっていることに気がつきました。
再起動後、問題の報告画面から毎回送信していましたが、これ届いてない可能性もあるかも😭
- Exception Type : EXC_BAD_ACCESS (SIGSEGV)
- Termination Reason : は2種類記録されていました。
- Namespace SIGNAL, Code 11 Segmentation fault: 11
- Namespace PAC_EXCEPTION, Code 1
Appleに届いているといいなぁ
vscode利用していると再起動の影響は最小限に
Visual Studio Codeは、編集中の状態で再起動、その後復帰すると以前の編集状態を維持してくれます（機能名はよく分かりませんが、標準でこの動作になっています）。
そのため、突然再起動しても、編集内容は救われる、その結果再起動の悪影響は最低限に抑えられている感じです。
まとめ：macOSのバグであってほしい
macOSのアップデートで、知らないうちに直ってました。そんなパターンを期待するpanicです。
panicが頻発していた頃、M2 MacBook Air買って失敗したかなぁ、Appleやめるかぁとも思いました。
希望を持って症状なし、直っちゃったを待ってます！
コメント