一、前言服务器RASReliability可靠性、Availability可用性、Serviceability可维护性并不是某一个独立软件模块能够实现的能力而是CPU、内存、PCIe设备、BIOS、BMC、OS等软硬件协同的结果。一个硬件错误从产生到最终被感知需要经历硬件检测、固件采集、错误上报、系统处理、带外记录、故障定位等多个环节。做好RAS开发除了理解具体的错误处理机制还要建立端到端故障处理思维。从软件角度来看服务器RAS通常由BIOS、BMC、Linux内核及驱动这三个部件承载BIOS负责底层硬件初始化及错误能力配置BMC负责带外监控、故障记录和运维管理Linux内核及驱动负责运行阶段的错误处理、隔离与恢复。二、硬件能力是前提1.硬件能力是 RAS 的基础前提只有硬件原生具备对应的检测机制上层软件才能基于该能力实现错误处理。举例CPU MCAMachine Check Architecture处理器通过 Machine Check Bank 等机制记录 CPU Core、Cache、内存层次及片间互连相关硬件错误并可通过 Machine Check Exception 等机制通知OSLinux等OS在内核 RAS 框架基础上完成错误解析、日志记录以及后续恢复处理内存ECC内存子系统需要具备 ECC 检错、纠错能力内存控制器才能检测并记录 CECorrected Error、UE/UCEUncorrected Error等事件随后由BIOS和 OS RAS 框架进行处理。PCIe AERAdvanced Error ReportingPCIe Root Port、Switch Port、Endpoint 需要支持 PCIe错误检测和上报能力平台才能完成 Correctable、Uncorrectable Non-Fatal、Uncorrectable Fatal 等错误的记录、上报与恢复。热插拔、冗余电源、RAID能力上限同样取决于硬件架构。故障隔离/降级运行硬件提供错误检测、隔离或冗余机制后BIOS、BMC、OS才能决策恢复策略和降级策略。2.CPU、芯片组、PCIe 设备的硬件 RAS 能力细节可查阅 Intel、AMD 等芯片厂商官方文档比如Intel的Software Developer Manualhttps://www.intel.com/content/www/us/en/developer/articles/technical/intel-sdm.htmlAMD的System Programming Manualhttps://8dcc.github.io/external/amd-manual.pdf三、BIOS层硬件RAS能力配置与错误交接CPU、内存等硬件的RAS能力是否开启、如何配置、如何暴露给OS很大程度上由BIOS决定。1BIOS要正确配置硬件RAS能力服务器启动过程中BIOS需要完成CPU、内存、PCIe等设备初始化同时配置大量RAS相关参数例如ECC开关、各类错误上报机制、设备热插拔、CPU Core 隔离等。如果 BIOS 配置不当操作系统将无法使用硬件 RAS 能力。下图是Taishan服务器的BIOS RAS配置图读者可以参考2BIOS与OS之间的关键接口ACPI硬件错误上报高度依赖 ACPI APEIACPI Platform Error Interface相关数据表及接口。典型运行期处理链路为CPU、内存控制器或芯片组检测到硬件错误后平台硬件/固件生成符合CPERCommon Platform Error Record格式的错误记录BIOS 通过HESTHardware Error Source Table描述系统内所有错误源其中 GHESGeneric Hardware Error Source 定义通用硬件错误源的状态区域及 NMI、SCI 等通知机制Linux APEI/GHES 驱动收到通知后读取并解析 CPER 错误记录再交由相应 RAS 子系统进行日志记录、故障恢复或隔离处理。ERSTError Record Serialization Table主要定义平台错误记录的持久化访问机制供操作系统读取、写入、清除平台侧持久化错误记录BERTBoot Error Record Table向OS描述 Boot Error Region使 OS 在启动后能够获取平台在启动阶段或 OS 尚不具备正常错误接收能力时保存的错误信息。若 HEST/GHES 内的错误状态地址、错误源类型或通知方式配置异常即便即便内存控制器已经检测到 ECC 可纠正错误也会因为 GHES 通知链路未正确建立造成 Linux 收不到硬件错误形成静默失效。若 ERST 配置异常则平台持久化错误记录无法正常读取、写入或清除。若 BERT 指向的 Boot Error Region 或内部 CPER 数据结构不符合规范即使 Linux 识别到启动错误记录也无法正确解析 Section Type、Error Severity、FRU 信息以及具体硬件位置影响 Memory、Processor、Cache、PCIe 等故障源定位。3启动阶段故障处理服务器上电、POST 和 BIOS初始化阶段也会发生硬件故障例如 DIMM 初始化或 Memory Training 失败、CPU 初始化失败、PCIe Link Training 失败、PCIe 设备枚举异常等。此时 Linux 尚未启动GHES 等运行期错误通知机制还未就绪无法依靠Linux 实时接收和记录这些故障。例如BIOS 在 Memory Training 阶段发现某条DIMM 无法正常完成训练。此时怎么办呢BIOS可以根据内存控制器返回的错误状态以及 CPU、Channel、DIMM Slot的拓扑信息将故障定位到具体 FRU如 CPU0 / Channel 2 / DIMM A2。然后BIOS 可以将能够使用标准 CPER Section 表达的错误组织为 CPER 错误记录并写入 Boot Error Region通过 ACPI BERT 将该区域提供给后续启动的 OS对于平台特有的初始化失败信息也可采用厂商扩展的错误记录格式。同时BIOS还可以通过 IPMI/KCS、Mailbox、共享内存或厂商私有接口将启动阶段故障信息传递给 BMC。BMC 生成 SEL 或其他平台事件记录并通过 Redfish、SNMP 等带外管理接口上报运维管理系统。如果OS能正常启动Linux ACPI/APEI 驱动会解析 BERT读取 BIOS 在 OS 启动之前存入 Boot Error Region 的 CPER 记录从而获知启动阶段发生的 Memory、Processor、PCIe 等硬件错误。如果故障严重到OS无法启动例如CPU初始化失败导致系统无法完成POST或者 Memory Training 失败导致没有可用系统内存则依靠BMC带外能力保存并上报故障。4BIOS RAS开发参考资料BIOS RAS 开发涉及处理器架构、UEFI、ACPI、PCIe 以及平台定制逻辑需要结合多份规范与文档。初学者优先阅读 UEFI Forum 发布的 ACPI Specification重点掌握 APEI 体系下的 HEST、GHES、BERT、ERST、EINJ 等错误处理机制结合 UEFI Specification 学习 CPER 标准错误记录格式通过 UEFI PI Specification 理解 PEI、DXE 等 BIOS 初始化阶段与平台初始化机制。硬件层面参考 Intel SDM、AMD Processor Programming Reference/Architecture Manual以及对应处理器 / 平台的 Datasheet、寄存器手册、BIOS Writers Guide、RAS Feature Guide。PCIe 相关错误参考 PCI Express Base Specification 中 AER、DPC、Link 相关章节。代码实现层面可阅读 TianoCore EDK II 开源 UEFI 项目中 ACPI Table、DXE、SMM、PCIe 模块的参考实现。在实际服务器项目中还需要结合 OEM/ODM 内部规范如 BIOS Design Specification、RAS Design Specification、BIOS-BMC Interface Specification 做故障定位。