UNIT 60 / 78 · W09-3
ROCm 故障该回到哪一层
本单元预计 4 核心小时。可以分成多个学习时段，按完整小节推进；停下来时留下输入、命令、结果和下一步。
时间包含阅读、编码与检查，是学习预算而非期限。打开此页只保存阅读位置，不代表通过验收。
先知道自己在观察什么
ROCm 各层：一次请求由谁负责 →
沿API、runtime、用户队列、内核驱动和设备的职责追踪一次请求，不把队列路径误说成完全没有驱动。
ROCm 各层：一次请求由谁负责 →
分别打开ROCr与AMDGPU官方文档，记录它们回答的资源/装载问题和各自版本。
先备不清楚时，沿章节入口补读；不要依赖翻过页数判断进度。
先留下自己的预测或独立尝试
先将allocation、code_object、wrong_value三类失败配到最早可检查处，再运行教学分类。
故障定位入口 →源码下载与编译入口
下载到自己的练习目录。按本节给出的完整命令编译；多文件与driver要求见原任务。需要时查阅文件保存与编译操作 →
35-b.cpp先保存预测，再核对正文标明的预期或诊断。完整构建、多文件与设备实验按原任务命令执行。
通过一个变动看清原因
在自己的分类副本增加‘没有找到支持设备’与‘回读值只错最后一项’两个案例，明确这是诊断建议而非实际SDK错误码。
修改后应观察到什么
前者优先查环境/设备枚举，后者先查尺寸、索引与独立oracle；不能凭分类证明根因。
换一组条件，独立解决
为主项目的未来HIP后端写三段最小故障报告模板，每段要求输入、版本、完整命令、最早错误与复现范围；填入假设案例并清楚标为假设。
用这些条件检查自己的实现
- 目标不兼容与数学结果错误分开；不把缺设备当算法失败。
- 报告不含私密SDK产物或凭据，所有接口结论能回到公开来源。
用证据决定是否进入下一单元
- 普通runtime调用与受保护内核操作各承担什么？
- 为什么每个错误都拖到最后回读会增加定位难度？
本单元的验收依据
三类报告与责任图可审查；模型分类和真实诊断证据保持分开。
留下自己的代码或推演、测试输入、真实输出和仍不确定的问题。未达到要求时，下一次继续本单元。