一张"魔改矿卡"RX570 显示故障的完整排查记录

本文档完整记录了一块特挑体质矿卡从发现故障、跨三个环境系统排查、到最终定性为硬件级缺陷的全过程。
包含所有实验、原始日志、关键证据、技术机制分析和经验教训。
写给未来再遇到类似卡的人，也写给正在为这块卡头疼的你。

目录

  1. 卡的基本情况与背景
  2. 症状总览（一句话版本）
  3. 三个环境的详细表现
  4. Windows 阶段的排查
  5. PVE 宿主机（Linux）阶段的排查
  6. 虚拟机直通阶段的排查
  7. 关键发现之一：HPD 是死的
  8. 关键发现之二：DDC/EDID 总线是死的
  9. 关键发现之三：编码器只在固件阶段工作
  10. 为什么"固件能亮、驱动不能亮"——机制分析
  11. 一个反直觉但至关重要的结论：Windows 能亮机正是因为驱动没装上
  12. 最终定性：这是晶圆/板级缺陷，不是软件问题
  13. 遗留的、未验证的、物理可修的方案
  14. 这块卡还能干什么
  15. 排查方法论与经验教训
  16. 附录 A：关键原始日志
  17. 附录 B：常用命令速查
  18. 附录 C：时间线
  19. 尾声：后续进展（P400 换卡尝试与 RX 590 GME 回归）

1. 卡的基本情况与背景

1.1 卡片来源

这是一块魔改矿卡（俗称"矿渣改卡"、“无头矿卡”）。原始形态是给挖矿用的，出厂时板上根本没有焊接任何显示输出接口（HDMI/DP/DVI 都是空焊盘），因为矿工不需要看画面。

为了能当正常显卡用，板主（你自己）按照原厂参考设计的 1:1 走线，亲手把 HDMI 座子焊回了 HDMI 焊盘位置。

1.2 硬件身份

项目值
GPU 代号POLARIS10 (Ellesmere)
PCI 设备 ID0x1002:0x67DF
PCI 子系统 ID0x1682:0xC570（XFX 讯景）
修订号REV EF
显存8192MB GDDR5，256bit 位宽
流处理器32 CU（active_cu_number 32，即 2048 个 SP）
驱动识别名Radeon RX 470/480/570/570X/580/580X/590
板上 VBIOS113-57085STB3-W90（XFX RX 570 Black Edition 8GB）
内核 DC 版本Display Core v3.2.3xx，DCE 11.2

1.3 刷 BIOS 历史

板主刷过市面上能找到的各种 BIOS：

  • 多版 RX570 8GB 原厂/魔改 BIOS
  • RX580 各版本 BIOS
  • 甚至 RX590 GME（6FDF）的 BIOS

结论：所有 BIOS 表现完全一致，没有任何一版能改变故障行为。

这一个事实非常关键：它排除了"VBIOS 版本不对"这个最常见的原因，把矛头直接指向晶圆本身。

2. 症状总览（一句话版本）

这块卡只在固件（VBIOS）自检阶段能出画面；任何操作系统驱动一旦接管显示，就永远黑屏。计算功能完全正常。

拆开说：

  • ✅ 固件阶段（POST / BIOS logo / UEFI 启动画面）：能亮，1080p 都能出来。
  • ❌ Windows + AMD 驱动接管：驱动安装/启动失败，code 43，屏幕黑。
  • ❌ Linux + amdgpu 驱动接管：驱动正常加载、GPU 计算正常，但显示无输出，黑屏。
  • ❌ 虚拟机直通：与宿主机完全一致，全程黑屏。
  • ✅ 作为副卡/计算卡：工作完全正常（挖矿、通用计算都行）。

3. 三个环境的详细表现

同一个 GPU，三个完全不同的运行环境，故障模式一模一样。这是"硬件问题"最有力的旁证——环境变量都被排除了。

3.1 Windows 11（物理机，做主卡）

  • 开机：BIOS logo 正常显示（固件路径）✅
  • 进入 Windows 引导：正常（UEFI framebuffer，仍是固件在输出）✅
  • 系统启动后：AMD 驱动开始接管 → 设备管理器出现 code 43（CM_PROB_FAILED_POST_START，设备启动失败）
  • 服务 amdwddmg（AMD 显示驱动服务）状态：STOPPED（错误 1077）
  • 屏幕：黑
  • 拔掉显示器测试：故障不变（排除"显示器/线材"因素）

3.2 PVE 宿主机（Debian/Proxmox 9.2，内核 7.x）

  • 开机：固件阶段亮机 ✅
  • amdgpu 驱动加载：完全正常，日志干净：
    • Display Core v3.2.369 initialized on DCE 11.2
    • SE 4, SH per SE 1, CU per SH 9, active_cu_number 32
    • 8192M of VRAM memory ready
    • 无任何 ERROR
  • 但：Cannot find any crtc or sizes —— 因为没有检测到任何显示器，没有任何模式可用，屏幕黑。
  • 强行喂 EDID + force 之后：内核开始执行编码器初始化 → ATOM 表挂死。

3.3 虚拟机直通（RX570 直通进 Debian 13 VM）

  • 与宿主机表现逐字一致：
    • amdgpu 3.61.0 正常加载，DC 3.2.301 / DCE 11.2
    • 5 个接口全部 disconnected
    • Cannot find any crtc or sizes
  • 强行 EDID + force 后：状态变 connected，fb0 创建成功，dpms=On
  • 但：显示器全程无信号（背光都不亮）
  • 用 modetest 做原子提交、改 bpc、切 YUV420：触发 GSL: Timeout on reset trigger! 复位风暴，硬件对复位命令无响应

4. Windows 阶段的排查

4.1 设备信息

PCI\VEN_1002&DEV_67DF&SUBSYS_C5701682&REV_EF\4&21D16FD&0&0008
  • VEN_1002 = AMD
  • DEV_67DF = Ellesmere（RX470/480/570/580/590 家族）
  • SUBSYS_C5701682 = XFX RX570
  • REV_EF = 特殊修订号（正常零售 RX570 一般不是 EF）

4.2 驱动试过的版本（全部失败）

驱动版本/日期安装方式结果
ASUS 定制 2017 版22.19.147.0oem18.infcode 43
AMD 23.19.x2023u0390451code 43
AMD 25.8.1（最新）2025-07u0417877code 43

其中 2017 版 ASUS 驱动特别值得注意：它的 INF 里 ati2mtag_Polaris10DS 就是 Discrete Switchable（离散可切换显卡） 段，专门对应 REV_EF 这种修订号，本该完美匹配。依然 code 43。

4.3 关键观察：主卡 vs 副卡

  • 做主卡（开机卡）：code 43，无显示。
  • 做副卡（计算卡，不做显示）：完全正常，可以算，可以挖。
  • 甚至做主卡时拔掉显示器：code 43 依旧。

这说明驱动在"显示初始化"这个环节上必挂，与显示器接没接无关。

4.4 SetupAPI 日志

C:\Windows\INF\setupapi.dev.log 记录了大量驱动安装历史（通过 SysCeo DrvCeo 驱动总裁安装），每种驱动安装都成功，但设备启动全部失败。失败发生在驱动 POST-START 阶段，即 CM_PROB_FAILED_POST_START。

5. PVE 宿主机（Linux）阶段的排查

5.1 环境

  • Proxmox VE 9.2.0，内核 7.0.2-6-pve
  • CPU：Xeon E3-1260L v5（核显对直通测试有一定作用）
  • IOMMU：dmar0 正常开启
  • 显卡位于 0000:01:00.0（+ 音频 0000:01:00.1）

5.2 amdgpu 初始化日志（干净版）

[drm] Display Core v3.2.369 initialized on DCE 11.2
amdgpu 0000:01:00.0: amdgpu: SE 4, SH per SE 1, CU per SH 9, active_cu_number 32
amdgpu 0000:01:00.0: amdgpu: Using BOCO for runtime pm
[drm] Initialized amdgpu 3.64.0 for 0000:01:00.0 on minor 1

注意几件事：

  1. DC（Display Core）初始化完全成功 —— 说明显示引擎的软件栈没问题。
  2. active_cu_number 32 —— 流处理器全开，说明这是一颗完整的 Polaris10 核心。
  3. 没有任何 ERROR —— 驱动层面"健康"。
  4. 但 Cannot find any crtc or sizes 紧随其后 —— 因为没有检测到显示器，找不到任何可用的显示模式。

5.3 5 个接口全部枚举出来

/sys/class/drm/card1-DP-1
/sys/class/drm/card1-DP-2
/sys/class/drm/card1-DP-3
/sys/class/drm/card1-DVI-D-1
/sys/class/drm/card1-HDMI-A-1

但 5 个接口的 status 全部是 disconnected。

这很不寻常：DP-1/2/3 和 DVI-D 是空焊盘没有座子，disconnected 是正常的；但你亲手焊好的 HDMI 座子上插着显示器，也显示 disconnected —— 这是第一个大问题。

5.4 决定性实验：EDID override + force + 热插拔

在 /sys/kernel/debug/dri/1/HDMI-A-1/ 下有三个魔法节点：

  • edid_override：强制注入一份 EDID
  • force：强制认为有显示器接上
  • trigger_hotplug：触发一次热插拔事件

实验步骤：

  1. 生成一份校验正确的 1080p EDID（128 字节，checksum 正确）
  2. 写入 edid_override
  3. echo on > force
  4. echo 1 > trigger_hotplug

结果：

  • 状态变为 connected ✅
  • 出现了一堆模式（1024x768、800x600、848x480、640x480）✅
  • /dev/fb0 被创建，fbcon 接管 ✅
  • 然后 dmesg 爆出致命错误：
[drm:atom_op_jump [amdgpu]] *ERROR* atombios stuck in loop for more than 20secs aborting
[drm:amdgpu_atom_execute_table_locked [amdgpu]] *ERROR* atombios stuck executing C4FE (len 62...) @ 0xC51A
[drm:amdgpu_atom_execute_table_locked [amdgpu]] *ERROR* atombios stuck executing B3F6 (len 1227...) @ 0xB639
amdgpu 0000:01:00.0: last message was failed ret is 65535
Console: switching to colour frame buffer device 128x48

翻译成人话：

  • 驱动调用 VBIOS 里的 ATOM 表（B3F6，就是编码器/发射器控制表）来打开发射器
  • ATOM 表里的代码在某个环节无限死循环，等了 20 秒还是没返回，被迫中止
  • 也就是：硬件对 ATOM 表的命令没有正确响应

结果：状态显示"已连接、已启用"，实际上编码器根本没把信号发出去，屏幕黑。

6. 虚拟机直通阶段的排查

6.1 环境

  • PVE 宿主机上建了 Debian 13 (trixie) 虚拟机（主机名 MiWiFi-RD03-srv，IP 192.168.31.60）
  • hostpci0: 0000:01:00,pcie=1,x-vga=1 把 RX570 直通进去
  • 装了 LXQt + SDDM 桌面（原本用 QEMU 虚拟显卡跑桌面，后来自行关闭了虚拟显卡）

6.2 初始状态

  • 关闭 QEMU 虚拟显卡、重启后：RX570 成为唯一显卡 card0
  • amdgpu 初始化干净，5 接口全 disconnected
  • Cannot find any crtc or sizes，连 /dev/fb0 都没有
  • SDDM/Xorg 在跑，但没有任何可输出的模式 → 黑屏

6.3 同样的 EDID + force 实验

  • 写入 1080p EDID → force=on → trigger_hotplug
  • 结果与物理机不同但结局相同：
    • 状态 connected，模式出现，fb0 创建 ✅
    • 但这次没有 atombios 挂起（VM 环境的 ATOM 执行路径可能不同）
    • chvt 1 强制 fbcon 提交模式后：enabled=enabled, dpms=On，驱动确信自己在输出
    • 显示器依旧全程黑屏，连背光都不亮

6.4 DRM 状态硬证据

/sys/kernel/debug/dri/0/state 显示：

crtc[60]: crtc-0
	active=1
	mode: "1024x768": 60 65000 1024 1048 1184 1344 768 771 777 806 0x40 0xa

像素时钟 65MHz 在跑，扫描输出在进行，CRTC 真激活。软件层面 100% 认为它在输出。

6.5 modetest 硬撬（原子提交）

  • 用 libdrm 的 modetest 做正规 atomic modeset
  • 换 640x480 → 改 output_bpc → 切 YUV420 → 换回 1024x768
  • 结果：
    • 模式都提交成功（setting mode ... on crtc）
    • 但 dmesg 洪水式报错：
amdgpu 0000:06:10.0: [drm] *ERROR* GSL: Timeout on reset trigger!

连续几十条。驱动尝试做 GPU 复位，但复位控制器对复位命令完全无响应。

6.6 寄存器读取：最后一击

想直接读 DC 的 HPD 寄存器（判断 HPD 引脚电平），通过 amdgpu_regs debugfs 读 MMIO 寄存器：

  • 读寄存器本身把整个 PVE 宿主机搞到失联、需要断电重启

一个健康的显卡，读 MMIO 寄存器不可能把宿主机读挂。只有**总线读卡死（bus hang）**才会这样——硬件对 MMIO 访问不返回，把整机拖死。这再次印证：这颗晶圆对驱动/CPU 的寄存器访问存在系统性不响应。

7. 关键发现之一：HPD 是死的

7.1 什么是 HPD

HPD（Hot Plug Detect）是 HDMI 座子的 第 19 脚。显卡靠它的电平高低判断"有没有插显示器"：

  • HPD 拉高（高电平）→ 显卡认为有显示器 → 打开发射器
  • HPD 拉低/悬空 → 显卡认为没插屏 → 不开显示输出

7.2 观测证据

  • 5 个接口状态全部 disconnected，包括插着显示器的 HDMI
  • 这说明 HDMI 的 HPD 引脚电平没有被拉高
  • 我们的 EDID+force 只是在驱动软件层骗过了"连接状态"，物理上 HPD 引脚还是死的

7.3 为什么 HPD 是死的

矿卡为挖矿设计，PCB 上大概率没有把 HPD 走线引到 HDMI 焊盘的 GPU 检测脚（或无头设计直接不布这条线）。你焊的座子第 19 脚等于悬空或接地。

这意味着：即使发射器硬件是好的，驱动也会因为"检测不到显示器"而拒绝打开发射器。

这是全案最值得补救、但尚未验证的硬件修复点（见第 13 节）。

8. 关键发现之二：DDC/EDID 总线是死的

8.1 什么是 DDC

DDC（Display Data Channel）是 HDMI 的 第 15/16 脚（SCL/SDA），I2C 总线。显卡通过它读取显示器内置的 EDID（显示器能力说明书），拿到分辨率列表。

8.2 观测证据

  • 物理机上：读 EDID 返回 I/O error
  • 虚拟机里：用 i2c-dev 直接探测 HDMI 的 DDC 总线（i2c-4）：
    • 地址 0x50 / 0x4a / 0x37 全部应答（ACK）
    • 但读出来的数据全是 0x00（正常 EDID 开头应该是 00 FF FF FF FF FF FF 00）
    • 校验和 = 0x00

8.3 这个现象说明什么

“全部 ACK + 数据全 0” 是 SDA 线被死死拉在低电平 的典型特征：

  • 正常无设备时应该是 NAK（无应答，SDA 释放为高）
  • 现在连不存在的地址都"应答"，是因为 SDA 被某处拉低，任何位都读成 0
  • 通俗讲：HDMI 的 DDC 数据线像对地短路了一样

8.4 排除干扰

  • DP-1/2/3、DVI-D 的空焊盘接口 DDC 异常不算数（它们根本没座子）
  • 只有你焊的 HDMI 的 DDC 异常才有意义，而它确实是死的

这导致驱动读不到 EDID → 没有原生模式 → 我们只能靠 EDID override 硬喂。

9. 关键发现之三：编码器只在固件阶段工作

这是全案最核心、最凝练的结论。

9.1 三条铁证

  1. 固件阶段能亮：POST / BIOS logo / UEFI 画面都能出，1080p 都能。
  2. 驱动阶段不能亮：
    • Windows：code 43（驱动启动时初始化显示引擎失败）
    • Linux 物理机：ATOM 表（B3F6 编码器控制表）执行死循环 20 秒超时，ret is 65535
    • Linux 虚拟机：ATOM 表不挂死，但发射器静默不输出；modetest 触发 GSL 复位风暴；读寄存器把整机读挂
  3. 计算功能完全正常：作为副卡/计算卡一切正常。

9.2 "固件能亮"和"驱动能亮"是两条完全不同的路

固件路径驱动路径
谁在初始化VBIOS 里的机器码（POST 时自己跑）OS 驱动按 ATOM 表逐条执行
时机冷启动，引擎从没被 reset/掉电显卡已经历 PCI reset、掉电、变频、电源管理
是否依赖 HPD不依赖，强制输出依赖，检测不到显示器就不开发射器
是否依赖 DDC不依赖依赖，没 EDID 没模式
本卡结果✅ 亮❌ 挂死或静默失败

同一个 VBIOS 里的 ATOM 表，固件跑得动，驱动跑不动——因为执行时机和硬件状态完全不同。

9.3 通俗比喻

这颗晶圆的发射器：

只能"冷启动点一次火"，不能"热重启再点一次火"。

  • POST 时：引擎是"出厂冷态"，从没被动过 → 一套初始化直接点亮 ✅
  • 驱动接管时：显卡被 PCI reset 过、被降频过、被电源管理过，发射器需要"重新上电 + PLL 重新锁定 + 重新握手" → 这颗晶圆在"再点火"这一步不响应 ❌

10. 为什么"固件能亮、驱动不能亮"——机制分析

10.1 驱动为什么不信任固件

操作系统的显卡驱动从不信任固件留下的显示状态。它接管时要做两件事：

  1. 重新枚举：自己读一遍所有接口/总线/EDID，重建显示树
  2. 重新初始化：把显示引擎（DC）、编码器、发射器按 ATOM 表重做一遍

这两步里，第 2 步需要"先掉电、再上电、再锁相"完整走一遍。本卡的发射器恰好在"重新上电锁相"这个环节不响应。

10.2 ATOM 表死循环意味着什么

ATOM（AtomBIOS）是 AMD VBIOS 里的一套命令表。B3F6 这类表是"打开发射器/编码器"的控制表，里面是显卡微控制器要执行的命令序列。

atombios stuck in loop 说明：表里的某个命令在等硬件给出一个响应/状态位，而这个硬件永远不给出。等 20 秒无果，驱动放弃。

last message was failed ret is 65535（0xFFFF）是 ATOM 表的"操作失败"返回码。

这是"发射器硬件不响应命令"的最直接物证。

10.3 虚拟机里为什么不挂死

虚拟机的直通卡同样跑 ATOM 表，但 DC（Display Core）在 VM 环境的某些代码路径可能跳过了部分发射器初始化，于是不挂死、但也不输出——安静失败。

结局相同：屏幕黑。

10.4 GSL 复位超时的意义

GSL: Timeout on reset trigger! 意味着连复位控制器都对复位命令没反应。复位是 GPU 最底层的机制，它不响应，说明这颗晶圆对驱动命令的整体响应能力都有问题——不止显示模块。

10.5 读寄存器读挂整机

正常显卡的 MMIO 寄存器访问是纳秒级的、不会阻塞。本卡读 HPD 寄存器时总线卡死、整机失联——这是硬件层面"命令无人应答、总线悬挂"的最极端表现。

11. 一个反直觉但至关重要的结论

Windows 能"稳定亮机"，恰恰是因为 AMD 驱动没装上。

这句话是整个谜题的解：

11.1 你看到的"Windows 能亮"真相

  • BIOS → Windows 引导 → 进入桌面前：画面一直是亮的
  • 这不是 Windows 的功劳，是固件（VBIOS）留下的帧缓冲还在输出
  • 固件在 POST 时点亮发射器后，只要没人去动它，它就持续输出
  • Windows 在"驱动未加载"阶段，显示一直停留在固件帧缓冲上（Microsoft Basic Display 直接拿来用，不重新初始化发射器）→ 所以亮

11.2 什么时候变黑

  • AMD 驱动一旦安装并接管 → 驱动要重新初始化发射器 → 本卡发射器不响应 → code 43 → 黑
  • 所以"亮"= 驱动还没接管 / 固件还在撑；“黑” = 驱动接管了

11.3 为什么 Linux 反而一直黑

  • Linux 的 amdgpu 驱动成功加载了（不像 Windows 那样 code 43 失败）
  • 驱动成功接管 → 重新初始化发射器 → 失败 → 黑
  • 所以 Linux 环境下你看不到"Windows 那种亮机桌面"——因为 Linux 驱动太"尽责"了，它一上来就接管

11.4 一句总结

谁重新初始化发射器，谁就黑；固件从不重新初始化，所以固件永远亮。

这不是矛盾，而是完全自洽的：故障只发生在"驱动接管后重新初始化发射器"这一条路径上。

12. 最终定性：这是晶圆/板级缺陷，不是软件问题

12.1 证据链闭合表

假设证据结论
驱动版本问题？2017~2025 全试过，全失败❌ 排除
VBIOS 版本问题？RX570/580/590 全刷过，一致❌ 排除
显示器/线材问题？拔屏测试、固件能亮❌ 排除
Windows 特定问题？Linux 同样故障❌ 排除
物理机/虚拟机环境差异？三个环境全试，一致❌ 排除
HPD/DDC 硬件问题？探测确认两者都是死的✅ 成立
发射器对 ATOM 命令不响应？挂死/静默失败/GSL 超时/读寄存器挂机✅ 成立

12.2 一句话结论

这块卡的显示发射器（编码器/TMDS 输出）只能在固件冷启动时点亮一次；任何操作系统驱动对其做重新初始化，它都不响应。同时 HPD 与 DDC 总线在硬件层面是死的。综合判断为晶圆级/板级显示引擎缺陷——这是一颗被筛选下来、显示功能不完整的矿卡体质芯片，软件无法修复。

12.3 为什么矿卡会有这种芯片

  • 晶圆制造中，同一批芯片的显示模块会有良率差异
  • 矿卡厂商/矿工收购了显示模块有缺陷、但计算模块完好的芯片（性价比极高）
  • 这类卡在矿场里只需要算力，不需要显示
  • 于是"显示坏的 Polaris"大量流入二手市场，价格极低

你的卡很可能就是其中之一。注意：不是所有无头矿卡都这样，有很多魔改矿卡补焊接口后是能正常显示的；你这块属于显示模块缺陷的那一批。

13. 遗留的、未验证的、物理可修的方案

这是唯一一个还没试过、且确实可能翻盘的方向。

13.1 方案：把 HDMI 第 19 脚（HPD）强行拉高

原理：

  • 驱动打开发射器的前置条件是"检测到显示器"，而检测靠 HPD 引脚电平
  • 你的 HPD 引脚物理上是死的（悬空/接地），驱动永远检测不到
  • 如果让 HPD 硬件电平变成高，驱动可能真的去打开发射器，而发射器可能其实没坏

操作（懂电烙铁的话 5 分钟）：

  1. 找 HDMI 座子的 pin 18（+5V） 和 pin 19（HPD）
  2. 用一颗 1kΩ ~ 10kΩ 的电阻把 18 脚和 19 脚连起来（强制 HPD=高电平）
  3. 如果板上有 HPD 焊盘通往 GPU 的检测脚，也可以直接飞线给高电平
  4. 重启再测：如果驱动原生就报 connected、EDID 能直接读出来、画面出来了 → 全案推翻，真相就是 HPD 没接

13.2 方案：复查 DDC（pin 15/16）

  • 现在 DDC 的表现是"SDA 被拉死低电平"
  • 确认 SCL（15 脚）、SDA（16 脚）是否焊对、有没有对地短路
  • 修好 DDC 后，驱动能原生读到 EDID，就不需要 EDID override 了

13.3 可行性评估（诚实版）

  • 成功率不好说。因为即便 HPD/DDC 修好，还有一层"发射器对 ATOM 表不响应"的证据（ATOM 挂死、GSL 复位超时、读寄存器挂机）在等着
  • 但如果 HPD 是那把钥匙，一切都说得通：ATOM 表死循环可能正是在等 HPD 状态，GSL 复位风暴可能是发射器未真正使能导致的连锁，读寄存器挂机也可能与卡进入异常状态有关
  • 这个实验成本极低（一根电阻），收益可能是全案翻盘，值得一试

14. 这块卡还能干什么

就算显示修不好，这块卡不是废卡：

14.1 计算/挖矿

  • 32CU 全开、8GB GDDR5、256bit —— 性能完整的 Polaris
  • 作为副卡/计算卡在 Windows 里实测完全正常
  • 适合：挖矿（ETH 时代、后续算法）、OpenCL 计算、Blender/达芬奇等支持 AMD 的渲染/转码（配合 CPU 或别的卡）

14.2 亮机卡（特殊用法）

  • 它至少能亮 POST，可以临时给无核显的机器看开机画面
  • 但进系统后就黑了，所以不能当日常输出卡

14.3 不建议

  • 不建议当主显示卡日常使用
  • 不建议再花大精力刷 BIOS（已证无解）
  • 不建议给重要机器做显示

14.4 替代方案（真想用桌面）

  • 花 20~30 元收一张亮机卡（GT710 / GT610 / R5 240 之类）解决显示
  • 或买一张正常的 RX570/580 拆机卡（100~200 元）
  • 这张卡留着当计算卡用，物尽其用

15. 排查方法论与经验教训

15.1 方法论

  1. 环境隔离：同一张卡，Windows / Linux 物理机 / 虚拟机直通，三个环境交叉验证 → 排除软件环境因素
  2. 层层递进：
    • 先看设备状态（code 43 / driver loaded）
    • 再看驱动日志（amdwddmg 停止 / dmesg ERROR）
    • 再看硬件接口（connector status / EDID / DDC / HPD）
    • 最后暴力触发（EDID override + force + modetest）
  3. 善用内核调试接口：
    • /sys/kernel/debug/dri/X/*/edid_override、force、trigger_hotplug
    • /sys/kernel/debug/dri/X/state（DRM 原子状态）
    • /sys/kernel/debug/dri/X/amdgpu_dm_dtn_log（DC 硬件状态）
    • /sys/kernel/debug/dri/X/amdgpu_regs（MMIO 寄存器）
  4. 关键数据要量化：ATOM 表挂死、GSL 复位超时、SDA 全 0 —— 都是可复现的硬证据

15.2 教训

  1. “能亮机"不等于"能显示”：固件亮机≠驱动显示，这是两套完全不同的路径。以后遇到"能进 BIOS 但进系统黑屏"的卡，先想到这个。
  2. Windows 的 code 43 有时是"驱动试图接管但硬件不配合"，不一定驱动有问题。
  3. 矿卡的水很深：无头矿卡补焊接口，可能踩中"显示模块有缺陷"的体质卡。买矿卡当显示卡用，最好买本来就带接口的卡。
  4. 读 MMIO 寄存器要谨慎：对疑似硬件故障的卡，用 debugfs 读寄存器可能把整机拖挂（总线悬挂）。操作前做好重启准备。
  5. HPD/DDC 是排查显示故障的第一顺位：很多"驱动认不到屏"的案子，根源就是 HPD 或 DDC 的物理问题。
  6. 别在硬件故障上无限投入：证据链闭合后及时止损。时间也是成本。

16. 附录 A：关键原始日志

A.1 Linux amdgpu 初始化（正常）

[drm] vm size is 64 GB, 2 levels, block size is 10-bit, fragment size is 9-bit
amdgpu 0000:01:00.0: amdgpu: VRAM: 8192M 0x000000F400000000 - 0x000000F5FFFFFFFF (8192M used)
amdgpu 0000:01:00.0: amdgpu: GART: 256M 0x000000FF00000000 - 0x000000FF0FFFFFFF
[drm] Detected VRAM RAM=8192M, BAR=256M
[drm] RAM width 256bits GDDR5
[drm] amdgpu: 8192M of VRAM memory ready
[drm] PCIE GART of 256M enabled
amdgpu: hwmgr_sw_init smu backed is polaris10_smu
[drm] Display Core v3.2.369 initialized on DCE 11.2
amdgpu 0000:01:00.0: amdgpu: SE 4, SH per SE 1, CU per SH 9, active_cu_number 32
amdgpu 0000:01:00.0: amdgpu: Using BOCO for runtime pm
[drm] Initialized amdgpu 3.64.0 for 0000:01:00.0 on minor 1
amdgpu 0000:01:00.0: [drm] Cannot find any crtc or sizes

A.2 ATOM 表挂死（物理机，强制 modeset 后）

[drm:atom_op_jump [amdgpu]] *ERROR* atombios stuck in loop for more than 20secs aborting
[drm:amdgpu_atom_execute_table_locked [amdgpu]] *ERROR* atombios stuck executing C4FE (len 62...) @ 0xC51A
[drm:amdgpu_atom_execute_table_locked [amdgpu]] *ERROR* atombios stuck executing B3F6 (len 1227...) @ 0xB639
amdgpu 0000:01:00.0: last message was failed ret is 65535
Console: switching to colour frame buffer device 128x48

A.3 GSL 复位超时（虚拟机，modetest 后）

amdgpu 0000:06:10.0: [drm] *ERROR* GSL: Timeout on reset trigger!
amdgpu 0000:06:10.0: [drm] *ERROR* GSL: Timeout on reset trigger!
...（连续几十条）

A.4 DRM 原子状态（虚拟机，强制点亮后）

crtc[60]: crtc-0
	active=1
	self_refresh_active=0
	mode_changed=0
	active_changed=0
	connectors_changed=0
	connector_mask=8
	encoder_mask=8
	mode: "1024x768": 60 65000 1024 1048 1184 1344 768 771 777 806 0x40 0xa

A.5 DDC 总线探测（虚拟机，HDMI 的 i2c-4）

bus 4: len16=00000000000000000000000000000000   <- HDMI-A-1, 全 0
bus 5: len16=00000000000000000000000000000000   <- DVI-D-1, 全 0（空焊，无意义）
bus 6: errno=121 Remote I/O error                <- DP AUX，正常
bus 7: errno=121 Remote I/O error
bus 8: errno=121 Remote I/O error

地址探测：
addr 0x50 -> ack, byte 00
addr 0x4a -> ack, byte 00
addr 0x37 -> ack, byte 00

A.6 Windows 设备/日志关键点

PCI\VEN_1002&DEV_67DF&SUBSYS_C5701682&REV_EF\4&21D16FD&0&0008
状态：CM_PROB_FAILED_POST_START (code 43)
服务：amdwddmg - STOPPED (error 1077)
INF 段：ati2mtag_Polaris10DS (Discrete Switchable, REV_EF→RX570)

17. 附录 B：常用命令速查

查看显卡与驱动

lspci -nnk | grep -A3 -iE "VGA|Display"
lsmod | grep amdgpu
cat /sys/class/drm/card*/.../status
ls /sys/class/drm/

查看 dmesg

dmesg | grep -iE "amdgpu|drm|atombios|GSL" | tail -50

EDID / 强制点亮

D=/sys/kernel/debug/dri/0
cat /tmp/1080p.bin > $D/HDMI-A-1/edid_override
echo on > $D/HDMI-A-1/force
echo 1 > $D/HDMI-A-1/trigger_hotplug
chvt 1   # 让 fbcon 真正提交模式

DDC 总线探测（需 i2c-dev 与 python3）

modprobe i2c-dev
python3 - <<'PY'
import fcntl, os
I2C_SLAVE=0x0703
fd=os.open("/dev/i2c-4",os.O_RDWR)   # HDMI 的 DDC 总线
fcntl.ioctl(fd, I2C_SLAVE, 0x50)
os.write(fd, bytes([0,0]))
print(os.read(fd,128).hex())
PY

modetest（需安装 libdrm-tests）

apt-get install -y libdrm-tests
modetest -M amdgpu -c          # 列连接器/模式
modetest -M amdgpu -s 93:640x480   # 对 connector 93 提交模式

查看 DRM 原子状态

cat /sys/kernel/debug/dri/0/state
cat /sys/kernel/debug/dri/0/amdgpu_dm_dtn_log

⚠️ 警告：amdgpu_regs 寄存器读取对疑似硬件故障的卡可能卡死整机，慎用。

18. 附录 C：时间线

阶段环境关键动作结果
1Windows 主卡全系列驱动code 43
2Windows 主卡拔屏测试依旧 code 43
3Windows 副卡计算测试✅ 正常
4PVE 物理机amdgpu 绑定驱动正常、无模式
5PVE 物理机5 接口枚举全部 disconnected
6PVE 物理机EDID+forceATOM 表挂死 ret 65535
7VM 直通关闭虚拟显卡RX570 成唯一主卡
8VM 直通EDID+force+chvt软件全绿、屏全黑
9VM 直通i2c 探测 DDCSDA 全 0 被拉死
10VM 直通modetest 原子提交GSL 复位风暴
11PVE 物理机读 HPD 寄存器整机总线悬挂、需要断电
12全环境交叉验证发射器仅在固件阶段工作

结语

这块卡陪我们走过了 Windows、PVE 宿主机、虚拟机三个世界，把所有能做的软件实验都做完了。它告诉了我们一个有点悲伤但完全自洽的事实：

它的显示发射器只活过一次——在固件冷启动的那一刻。之后无论谁想再点亮它，它都不再回应。

但这不是失败。这是一次非常彻底的排查：环境隔离、硬件探测、内核调试接口、原子提交、寄存器级访问，每一层都留下了可复现的证据，最终把结论钉死在硬件层。你对这块卡的理解，可能比大部分矿商都深。

如果你愿意，最后还有一根电阻的悬念（HPD 拉高）没有揭晓——那也是唯一可能让故事反转的地方。祝好运。

尾声：后续进展（P400 换卡尝试与 RX 590 GME 回归）

本部分为原文档发布后的补充记录（2026-09-10）。

一、尝试换用 NVIDIA P400 —— 失败

在确认 RX570 显示缺陷后，尝试把插槽里的卡换成一张 NVIDIA Quadro P400（半高卡），期望换一块正常卡解决显示问题。

结果：P400 在 PCI 总线上完全不可见。

  • lspci -nn：全总线仅 13 个设备，没有任何 NVIDIA/显示设备条目（连"未驱动设备"都不存在）
  • 重新扫描 PCI 总线（echo 1 > /sys/bus/pci/rescan）：依旧无
  • dmesg：无任何 NVIDIA/PCIe 枚举报错，也没有设备出现
  • 同时该主板 CPU（Xeon E3-1260L v5）无核显 → 整机彻底无头

排查结论（物理层）：

  1. 绝大多数情况是没插到位 / 没锁扣——半高卡容易被压不到底
  2. 其次换一个 PCIe 插槽再验证
  3. 用另一台机器验证卡本身好坏（P400 是纯插槽供电、无外接供电，不存在接线漏插的问题）

二、RX 590 GME（6FDF）回归并体检

随后把一张 RX 590 GME（1002:6fdf Polaris 20 XL，2048SP，AMD 公版子系统 1002:0b31，rev e7）插回槽位。

  • PCI 识别正常：01:00.0 VGA ... Polaris 20 XL [Radeon RX 580 2048SP] [1002:6fdf]
  • 驱动绑定正常：amdgpu
  • OpenCL 计算体检正常（Mesa/Clover，radeonsi）：
项目结果
设备识别AMD Radeon RX 590 GME，32 CU，1380MHz，8GB
FP32 单精度~2.66 TFLOPS
FP64 双精度~0.34 TFLOPS
INT24~4.2 TOPS
INT8~4.9 TOPS
显存带宽~10 GB/s
计算错误无

结论：这张 590 是健康卡 —— amdgpu 驱动、显存、流处理器全部正常工作，可以作为正常显卡/计算卡出售或使用。

备注：Mesa OpenCL 测出的 FP32 与带宽比标称偏低（纸面 2048SP≈5 TFLOPS、256GB/s），因为 radeonsi 的 OpenCL 路径没有吃满硬件；换 ROCm OpenCL 可测出更接近标称的值。

三、这次"换卡"补充了哪些认识

  1. 显卡能不能被系统识别，第一步永远是 PCI 枚举——lspci 里没有，就一定是物理层问题（没插好/槽坏/卡坏），别先怀疑驱动。
  2. 一张"体检通过"的矿卡（计算正常、无报错）才是可以放心出售的状态；正好和 RX570 形成对照：计算健康 ≠ 显示健康。
  3. P400 未识别与 RX570 显示缺陷是两个独立事件：前者是物理插入问题（大概率可修），后者是晶圆显示模块缺陷（软件无解）。
  4. 诊断工具沉淀：clinfo / clpeak / mesa-opencl-icd 一套装完，以后任何 AMD 卡插上就能 5 分钟体检。

记录完成。

Logo
openEuler 社区

openEuler 是由开放原子开源基金会孵化的全场景开源操作系统项目，面向数字基础设施四大核心场景（服务器、云计算、边缘计算、嵌入式），全面支持 ARM、x86、RISC-V、loongArch、PowerPC、SW-64 等多样性计算架构

更多推荐

2026最新版百度网盘配合IDM与PanDownload提速方案详解

四、操作系统的临时资源分配不均 原因：电脑在运行某些大型三维游戏或者专业图像处理软件时，操作系统的核心调度资源被严重倾斜，分给下载进程的CPU和内存资源变得非常有限。五、文件分享链接的初始热度影响 原因：某些刚刚上传或者冷门的资源，由于同时在线下载的人数较少，服务器端没有建立起有效的分布式加速缓存，导致单点提取的速度受到牵制。一、源文件过大导致的片段碎片化 原因：分享的文件体积过于庞大，被服务器分

avatar openEuler 社区

AI Agent 执行引擎选型指南：PowerShell / Bash 和 Python，边界与最佳实践

很多人总喜欢争论“哪个工具更好”，但工程上从来没有更好，只有更合适。Shell 是它的“手脚”，用来直接触碰操作系统，轻量、原生、可靠；Python 是它的“大脑扩展”，用来处理复杂问题、调用海量生态。只靠 Shell，Agent 做不了复杂事；全靠 Python，Agent 会变得臃肿、脆弱、环境依赖严重。理解各自的边界，在合适的层级用合适的工具，多引擎协同，才是生产级 Agent 的正确路线。

avatar openEuler 社区
cover

Linux系统篇（一）指令篇·一：初识Linux及其基本指令

avatar openEuler 社区