Skip to content

NanoKVM Cube (LT6911UXC) advertises HDCP on Apple Silicon Mac but authentication never completes, causing a macOS HDCP auth storm and eventually a WindowServer watchdog kernel panic #822

Open
Open
NanoKVM Cube (LT6911UXC) advertises HDCP on Apple Silicon Mac but authentication never completes, causing a macOS HDCP auth storm and eventually a WindowServer watchdog kernel panic#822

Description

@lcolok
lcolok
opened on Jun 21, 2026

English version first, 中文版在后半部分 (scroll down for the Chinese version).

English version

Summary

NanoKVM Cube with the LT6911UXC HDMI-to-MIPI CSI bridge appears to advertise HDCP2.2 capability to an Apple Silicon Mac, but HDCP authentication never completes, which causes macOS to retry continuously and can eventually lead to a WindowServer watchdog kernel panic on a headless Mac mini M4.

Environment

  • Capture device: Sipeed NanoKVM Cube with hardware identifier CUBE_B
  • NanoKVM SoC: SG2002 (RISC-V)
  • NanoKVM software version: v2.3.6
  • NanoKVM kernel: 5.10.4
  • Capture chip: Lontium LT6911UXC HDMI-to-MIPI CSI bridge
  • LT6911UXC bus/address: I2C bus 4, 7-bit address 0x2B
  • LT6911UXC chip ID: measured from bank 0x81, registers 0x00/0x01 read as 0x17/0x04, confirming LT6911UXC
  • NanoKVM sensor configuration: LONTIUM_LT6911_2M_60FPS_8BIT
  • NanoKVM sensor driver: libsns_lt6911.so
  • Captured host: Apple Mac mini M4, model identifier Mac16,10
  • macOS: macOS 26.2 / Darwin 25.x
  • Host setup: headless, with no built-in display; display output depends on this NanoKVM
  • Connection:
    • Mac HDMI output -> NanoKVM HDMI input
    • NanoKVM single USB-C cable for both power and HID

Symptom

  • The Mac hits a kernel panic with bug_type 210.
  • The immediate panic cause is the userspace watchdog: WindowServer does not check in for a long time, approximately 148 seconds, and is considered stuck by the watchdog.
  • The panic is intermittent. It may only happen once or twice after several days of continuous operation, but when it happens the whole machine reboots, which is highly disruptive for a headless host.
  • WindowServer CPU usage is not a reliable indicator for this issue. The storm happens in the kernel DCP layer; during the storm, WindowServer CPU usage was only 0-5%.

Root cause analysis

Below is the current causal chain, with measured observations separated from analysis/inference.

Measured / directly observed

  • The LT6911UXC is present on I2C bus 4 at 7-bit address 0x2B.
  • The chip ID was confirmed by reading bank 0x81, registers 0x00/0x01, which returned 0x17/0x04 and identifies the chip as LT6911UXC.
  • When directly connected to the NanoKVM, macOS kernel logs repeatedly show an HDCP authentication sequence involving:
AppleDCPDPTXRemoteHDCPAuthSessionProxy ... AuthOpen<7> / CPDesired<1> / HPrimeAvailable<9> / AuthClose<8>
  • The sequence repeats continuously. In one 60-second observation window, AuthClose occurred about 58 times/minute and AuthOpen about 29 times/minute, corresponding to roughly one full authentication loop every about 2 seconds.
  • In another direct-connection observation, the combined AuthOpen+AuthClose rate reached about 88 times/minute.
  • When a powered HDMI 1x2 splitter was inserted between the Mac and the NanoKVM, authentication events dropped to 1 event in a 240-second forward observation window, effectively about zero.
  • Removing that splitter and returning to direct connection reproduced the storm within minutes; reconnecting the splitter made the events drop back to zero again.
  • Suspending the LT6911 on-chip MCU over I2C, by first switching bank with 0xFF=0x80 and then writing 0xEE=0x01, reduced the storm from about 174/minute to about zero.
  • Restoring the MCU with 0xEE=0x00 and restarting the capture service made the storm return.

Analysis / inference

  • The LT6911UXC appears to advertise itself as HDCP-capable, specifically HDCP2.2-capable, over HDMI DDC to the host.
  • However, the LT6911UXC flash appears not to contain valid HDCP keys, so HDCP authentication never completes. This creates an "advertise-but-fail" state, which is the worst middle ground: the host believes the sink supports HDCP and keeps trying, but authentication cannot succeed.
  • macOS, through kernel IOAVFamily / DCP behavior on Apple Silicon, opportunistically starts HDCP authentication for any sink that advertises HDCP support. This does not require DRM-protected content playback and does not require any userspace process to request HDCP.
  • This differs from Windows behavior observed with the same NanoKVM class of device: Windows usually negotiates HDCP only when protected content is played, so the same NanoKVM can be used with a Windows PC for years without triggering this specific issue.
  • After each failed authentication attempt, macOS immediately retries, creating a loop approximately every 1.6-2 seconds:
AuthOpen -> CPDesired<1> -> HPrimeAvailable -> AuthClose
  • The retry interval itself appears consistent with the HDMI HDCP requirement that re-authentication happens within <=2s, so the retry cadence alone is not being reported here as a Mac bug.
  • The high-frequency authentication storm appears to overload or wedge the M4 DCP (Display Co-Processor) firmware path. WindowServer then cannot check in in time, and the userspace watchdog eventually triggers the panic.
  • The MCU suspend experiment strongly suggests that the storm has an active sink-driven component: when the LT6911 on-chip MCU is suspended, the sink no longer drives authentication behavior and the Mac becomes quiet.

Reproduction & Evidence

Measure the storm rate on the Mac

Run this on the Mac:

/usr/bin/log show --last 60s --predicate 'process=="kernel" AND eventMessage CONTAINS "AuthClose"' | grep -c AuthClose

Observed results:

  • Direct Mac -> NanoKVM connection: about 58 AuthClose events/minute.
  • AuthOpen was about 29/minute in the same condition.
  • This corresponds to roughly one full authentication loop every about 2 seconds.
  • Normal behavior without the storm should be about zero.

The macOS kernel log repeatedly shows the following sequence:

AppleDCPDPTXRemoteHDCPAuthSessionProxy ... AuthOpen<7> / CPDesired<1> / HPrimeAvailable<9> / AuthClose<8>

In the storm state, IOAV message sequence numbers increased by more than 100 within 6 seconds.

Causal experiment with a powered HDMI splitter, measured on 2026-06-21

Test setup:

Mac HDMI -> powered HDMI 1x2 splitter INPUT -> one splitter OUTPUT -> NanoKVM HDMI input

Observed result:

  • With the powered splitter inserted, the 240-second forward observation window contained only 1 authentication event, effectively about zero.
  • After removing the splitter and restoring the direct Mac -> NanoKVM connection, the storm reproduced within minutes at about 88 events/minute when counting AuthOpen+AuthClose together.
  • After reconnecting the powered splitter, authentication events dropped back to zero again.

The repeated remove/reinsert test makes the causal relationship clear.

The likely explanation is that the powered splitter terminates HDCP on its input side. To the Mac, it behaves as a normal HDCP sink that can authenticate once successfully. Downstream HDCP is then not requested, so the LT6911 can still capture normally while the Mac's retry loop no longer starts.

LT6911 on-chip MCU suspend experiment

This was a diagnostic-only experiment and is not recommended as a daily workaround, because it interrupts capture.

On the NanoKVM, suspending the LT6911 on-chip MCU via I2C reduced the storm from about 174/minute to about zero:

write 0xFF=0x80
write 0xEE=0x01

Restoring the MCU and restarting the capture service made the storm return:

write 0xEE=0x00

This indicates that the HDCP behavior is controlled by the LT6911 on-chip MCU firmware. NanoKVM userspace software does not appear to participate in the HDCP negotiation.

Why this is a firmware-level issue

  • The LT6911UXC HDCP capability advertisement, including DDC HDCP2Version response behavior and the HDCP RX engine, is driven by the LT6911 on-chip MCU firmware running from SPI flash.
  • NanoKVM userspace software such as libkvm does not contain HDCP-related functions, so there does not appear to be a NanoKVM userspace switch that can disable the HDCP advertisement.
  • The issue appears to be that this LT6911 firmware advertises HDCP2.2 while the flash is not provisioned with valid HDCP keys. This looks like a provisioning/configuration problem in the LT6911 firmware or flash contents rather than something users can fix in NanoKVM application software.
  • Note that the LT6911UXC silicon itself is a compliant HDCP receiver, so no hardware change is required. The cleanest fix is at the firmware level: a firmware variant that simply does not advertise HDCP would make the chip behave like an honest non-HDCP sink, so macOS never starts authentication in the first place.

Current workaround

Insert a powered HDMI 1x2 splitter between the Mac and the NanoKVM:

Mac HDMI -> powered HDMI 1x2 splitter INPUT -> splitter OUTPUT -> NanoKVM HDMI input

This has been measured to eliminate the authentication storm, as described above.

Notes:

  • The splitter must be powered over USB.
  • Passive passthrough adapters do not solve this.
  • This adds extra hardware and another power dependency.
  • The Mac output resolution should stay within the splitter and capture limits; <=1080p is recommended.
  • This is only a workaround; a firmware-level fix would remove the need for extra hardware.

Request to maintainers

Could you please advise whether this LT6911UXC HDCP advertise-but-fail behavior is known for NanoKVM Cube units?

Possible fixes or mitigations that would help:

  • Preferably, provide an LT6911UXC firmware variant for Cube users that does not advertise HDCP (i.e. behaves like a plain non-HDCP sink). This appears to be the lowest-effort root fix and needs no hardware change. Alternatively, a firmware that has HDCP correctly provisioned with valid keys would also work.
  • Document this issue and the recommended workaround in the FAQ or troubleshooting guide, especially for Apple Silicon users.
  • Share whether there is already a planned fix or firmware update for this behavior.

I am happy to provide more detail if useful. I have also performed a read-only LT6911UXC firmware dump and reverse engineering of the I2C control protocol.

Additional context

As of 2026-06-21, I have not found an existing public upstream issue that explains this full causal chain.

Potentially adjacent issues:

Those issues do not appear to document this exact LT6911UXC HDCP advertise-but-fail behavior and its relationship to the Apple Silicon DCP / WindowServer watchdog panic.

中文版

摘要

NanoKVM Cube 采用 LT6911UXC(HDMI → MIPI CSI 采集桥),它似乎向 Apple Silicon Mac 声明支持 HDCP2.2,但 HDCP 认证始终无法完成,导致 macOS 持续重试;在 headless 的 Mac mini M4 上,这最终可能触发 WindowServer 看门狗内核 panic。

环境

  • 采集设备:Sipeed NanoKVM Cube(硬件标识 CUBE_B)
  • NanoKVM SoC:SG2002(RISC-V)
  • NanoKVM 软件版本:v2.3.6
  • NanoKVM 内核:5.10.4
  • 采集芯片:Lontium LT6911UXC(HDMI → MIPI CSI 桥)
  • LT6911UXC 总线/地址:I2C bus 4,7-bit 地址 0x2B
  • LT6911UXC 芯片 ID:读 bank 0x81 寄存器 0x00/0x01 得 0x17/0x04,确认为 LT6911UXC
  • NanoKVM 传感器配置:LONTIUM_LT6911_2M_60FPS_8BIT
  • NanoKVM 传感器驱动:libsns_lt6911.so
  • 被采集主机:Apple Mac mini M4,机型标识 Mac16,10
  • 系统:macOS 26.2 / Darwin 25.x
  • 主机形态:headless,无内置显示器,出画面完全依赖这台 NanoKVM
  • 连接:
    • Mac HDMI 输出 → NanoKVM HDMI 输入
    • NanoKVM 单条 USB-C 同时供电 + HID

现象

  • Mac 出现内核 panic,bug_type 210。
  • 直接原因是用户态看门狗:WindowServer 长时间(约 148 秒)未 check-in,被看门狗判定卡死。
  • 该 panic 偶发——连续运行数天可能仅触发一两次,但一旦触发整机重启,对 headless 主机影响很大。
  • WindowServer 的 CPU 占用不是可靠指标:风暴完全发生在内核 DCP 层,风暴期间 WindowServer CPU 仅 0–5%。

根因分析

以下是目前的因果链,实测观察与分析推断分开列出。

实测 / 直接观察

  • LT6911UXC 位于 I2C bus 4、7-bit 地址 0x2B。
  • 读 bank 0x81 寄存器 0x00/0x01 得 0x17/0x04,确认芯片为 LT6911UXC。
  • 直连 NanoKVM 时,macOS 内核日志反复出现 HDCP 认证序列:
AppleDCPDPTXRemoteHDCPAuthSessionProxy ... AuthOpen<7> / CPDesired<1> / HPrimeAvailable<9> / AuthClose<8>
  • 该序列持续重复。在一个 60 秒观测窗口里,AuthClose 约 58 次/分钟、AuthOpen 约 29 次/分钟,即大约每 2 秒一个完整认证循环。
  • 另一次直连观测中,AuthOpen+AuthClose 合计速率达到约 88 次/分钟。
  • 在 Mac 与 NanoKVM 之间串入一个带电(USB 供电)的 HDMI 1×2 分配器后,240 秒前向观测窗口内认证事件仅 1 次,基本为零。
  • 拆掉分配器恢复直连后,风暴在数分钟内复现;再接回分配器后认证事件又归零。
  • 通过 I2C 挂起 LT6911 片上 MCU(先 bank 切换写 0xFF=0x80,再写 0xEE=0x01),风暴从约 174 次/分钟降到约零。
  • 恢复 MCU(0xEE=0x00)并重启采集服务后,风暴回归。

分析 / 推断

  • LT6911UXC 似乎通过 HDMI DDC 向主机声明自己支持 HDCP(具体为 HDCP2.2)。
  • 但其 flash 中似乎没有有效的 HDCP 密钥,因此 HDCP 认证永远无法完成。这形成"声明但失败"(advertise-but-fail)的最糟中间态:主机认为 sink 支持 HDCP 而不断尝试,但认证始终无法成功。
  • macOS 在 Apple Silicon 上通过内核 IOAVFamily / DCP,会对"任何声明支持 HDCP 的 sink"机会性地主动发起 HDCP 认证。这无需播放任何 DRM 受保护内容,也无需任何用户态进程发起请求。
  • 这与同类 NanoKVM 设备在 Windows 上观察到的行为不同:Windows 通常只在播放受保护内容时才协商 HDCP,所以同款 NanoKVM 接 Windows PC 多年都不会触发此问题。
  • 每次认证失败后 macOS 立即重试,形成大约每 1.6–2 秒一轮的循环:
AuthOpen -> CPDesired<1> -> HPrimeAvailable -> AuthClose
  • 这个重试间隔本身符合 HDMI HDCP 规范"重认证间隔 ≤2s"的要求,因此这里不把重试节奏本身当作 Mac 的 bug。
  • 高频认证风暴似乎拖垮/卡住了 M4 的 DCP(Display Co-Processor)固件路径,导致 WindowServer 无法及时 check-in,最终触发用户态看门狗 panic。
  • MCU 挂起实验强烈表明风暴有 sink 主动驱动的成分:挂起 LT6911 片上 MCU 后,sink 不再驱动认证行为,Mac 随即安静。

复现与证据

在 Mac 上测风暴速率

在 Mac 上运行:

/usr/bin/log show --last 60s --predicate 'process=="kernel" AND eventMessage CONTAINS "AuthClose"' | grep -c AuthClose

观测结果:

  • 直连 Mac → NanoKVM:约 58 次 AuthClose/分钟。
  • 相同条件下 AuthOpen 约 29 次/分钟。
  • 即大约每 2 秒一个完整认证循环。
  • 无风暴的正常状态应约为零。

macOS 内核日志反复出现以下序列:

AppleDCPDPTXRemoteHDCPAuthSessionProxy ... AuthOpen<7> / CPDesired<1> / HPrimeAvailable<9> / AuthClose<8>

风暴状态下,IOAV 消息序号在 6 秒内增长超过 100 条。

带电 HDMI 分配器的因果实验(2026-06-21 实测)

测试链路:

Mac HDMI -> 带电 HDMI 1×2 分配器 INPUT -> 分配器某 OUTPUT -> NanoKVM HDMI 输入

观测结果:

  • 串入带电分配器后,240 秒前向观测窗口内仅 1 次认证事件,基本为零。
  • 拆掉分配器恢复直连后,风暴在数分钟内复现,AuthOpen+AuthClose 合计约 88 次/分钟。
  • 再接回带电分配器后,认证事件又归零。

反复拆/接的对照使因果关系非常明确。

可能的解释:带电分配器在其输入侧自己完成并终结 HDCP——对 Mac 而言它表现为一个能一次认证成功的正常 HDCP sink;下游不再要求 HDCP,于是 LT6911 仍能正常采集,而 Mac 的重试循环不再启动。

LT6911 片上 MCU 挂起实验

这仅是诊断性实验,会中断采集,不建议作为日常方案。

在 NanoKVM 上通过 I2C 挂起 LT6911 片上 MCU,使风暴从约 174 次/分钟降到约零:

write 0xFF=0x80
write 0xEE=0x01

恢复 MCU 并重启采集服务后,风暴回归:

write 0xEE=0x00

这表明 HDCP 行为由 LT6911 片上 MCU 固件掌控,NanoKVM 的用户态软件似乎并不参与 HDCP 协商。

为什么这是固件层问题

  • LT6911UXC 的 HDCP 能力声明(包括对 DDC HDCP2Version 的应答行为与 HDCP RX 引擎)由运行在 SPI flash 上的 LT6911 片上 MCU 固件驱动。
  • NanoKVM 的用户态软件(如 libkvm)中不含任何 HDCP 相关函数,因此似乎不存在能在 NanoKVM 用户态关闭 HDCP 声明的开关。
  • 问题本质似乎是:该 LT6911 固件声明了 HDCP2.2,但 flash 未配置有效 HDCP 密钥。这更像是 LT6911 固件/flash 内容的 provisioning/配置问题,而非用户能在 NanoKVM 应用软件层修复的东西。
  • 需要说明:LT6911UXC 这颗硅片本身就是合规的 HDCP 接收器,因此无需任何硬件改动。最干净的修法在固件层:一个不声明 HDCP 的固件变体会让芯片表现为一个诚实的非 HDCP sink,这样 macOS 从一开始就不会发起认证。

当前规避方案

在 Mac 与 NanoKVM 之间串入一个带电 HDMI 1×2 分配器:

Mac HDMI -> 带电 HDMI 1×2 分配器 INPUT -> 分配器 OUTPUT -> NanoKVM HDMI 输入

已实测可消除认证风暴(见上)。

注意:

  • 分配器必须经 USB 供电。
  • 无源直通转接头无法解决。
  • 这会引入额外硬件和一个额外的供电依赖。
  • Mac 输出分辨率应保持在分配器与采集上限之内,建议 ≤1080p。
  • 这只是规避方案;固件层修复才能免去额外硬件。

对维护者的请求

能否请确认 NanoKVM Cube 是否已知这一 LT6911UXC "声明 HDCP 却认证失败" 的行为?

可能有帮助的修复或缓解:

  • 最好能为 Cube 用户提供一个不声明 HDCP(即表现为普通非 HDCP sink)的 LT6911UXC 固件变体。这似乎是工作量最小的根治办法,且无需任何硬件改动。或者,提供一个正确烧入有效 HDCP 密钥的固件也可以解决。
  • 在 FAQ / 排障指南中说明此问题及推荐的规避方案,尤其面向 Apple Silicon 用户。
  • 告知是否已有针对该行为的修复计划或固件更新。

如有需要我乐意提供更多细节。我还做过 LT6911UXC 的只读固件 dump 和 I2C 控制协议逆向。

补充

截至 2026-06-21,我在上游公开 issue 跟踪器中未找到把这条完整因果链讲清楚的既有 issue。

可能相邻的 issue:

这些 issue 似乎都没有记录这一具体的 LT6911UXC "声明 HDCP 却认证失败" 行为,以及它与 Apple Silicon DCP / WindowServer 看门狗 panic 的关系。

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Fields

    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions