RAS Solutions for Arm64 Servers
summary
Firmware implements early-initialization checks, generates preserved crash dumps and SEL records, and uses GPIO interrupt for catastrophic errors to get immediate platform notification; PCIe AER is handled by firmware walking the root complex and endpoints, with error injection validated over thousands of reboots and 24‑hour memory tests; memory scrubbing is controllable via an ACPI RAS table exposed to the OS, and crash/diagnostic data is mirrored to both BMC and flash so postmortem analysis survives a platform power cycle.
AI-written summary · about
chapters (24)
- 0:00Introduction to RAS on Arm64
- 1:13What is RAS and why it matters
- 3:48Defining RAS requirements
- 8:31Customer needs for RAS solutions
- 10:39Targeted RAS solutions overview
- 14:01Boot time error handling
- 15:49Runtime error handling strategies
- 17:16Memory scrubbing techniques
- 19:04PCIe error handling in Linux
- 23:44PCIe error handling methods
- 27:29Board-level sensor management
- 29:35Hardware error interrupt handling
- 31:49Crash dump analysis needs
- 33:39Early boot error handling
- 35:06SOC and BMC communication
- 36:31Configuration management for RAS
- 39:02Memory error injection methods
- 41:02RAS feature development status
- 42:40Current RAS framework capabilities
- 44:30User space error handling
- 45:16Industry collaboration on RAS
- 47:05Future challenges in RAS
- 48:10Complexities in multi-socket systems
- 51:44Q&A on error handling mechanisms
related talks
24mReliability, Availability, and Serviceability (RAS) on ARM64 status
42mServer platforms: experiment with your expensive hardware too!
39m“Early Boot and Late Attach” of Remote Processor...
03mIntroduction
34mRISC-V ACPI and UEFI Updates
19mLinux on RISC V Fedora and Firmware Status Update
20mDebugging RISC-V Kernel Crashes: KDUMP, vmcore, and Crash Utility Enhancements
24mAdding RAS Support for CXL Port Devices - Terry Bowman