Firmware-OS Shared Defect List for Persistent Memory Management
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Existing memory error detection and correction technologies, such as ECC, do not prevent errors from occurring and fail to maintain memory error data across OS reinstalls, leading to inconsistent memory management between system firmware and OS.
Innovation Solution
A Shared Defect List (SDL) is maintained cooperatively by OS and system firmware using standardized data formats, persisting memory error data in non-volatile storage to be accessible across OS reinstalls, with firmware identifying defective memory locations and providing this information to the OS, which manages memory usage accordingly.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Reliability
If memory error data is stored only in volatile memory, then memory management can be performed quickly, but the data is lost after OS reinstalls
Solution Approach 1:
The system performs preliminary action by persisting memory defect data to non-volatile storage during system operation, so that the data is already available when the OS boots after reinstalls. This eliminates the need for re-detection and ensures immediate availability of defect information without requiring time-consuming re-scanning of memory during boot.
Solution Approach 2:
The patent introduces an intermediary mechanism (shared memory defect list structure) that mediates between the firmware and OS. This intermediary stores defect data in a standardized format that both firmware and OS can access, allowing persistent storage in non-volatile memory while maintaining fast access during operation through the shared data structure.
2Reliability
If firmware and OS maintain separate memory defect lists, then each component can manage memory independently, but consistency and coordination between components deteriorates
Solution Approach 1:
The patent merges the memory defect list functionality into a single shared data structure that is accessible by both firmware and OS. This unified approach eliminates data redundancy and ensures consistency between components, as both firmware and OS read from and write to the same defect list stored in non-volatile memory, rather than maintaining separate independent lists.
Solution Approach 2:
The shared memory defect list serves multiple functions: it stores defect data for firmware's memory management, provides defect information to the OS for memory allocation decisions, and persists across reboots. This multi-functional data structure eliminates the need for separate maintenance mechanisms and simplifies the overall system architecture.
Data Source
Figure 1
Figure 2A
Figure 2B
AI summary
Disclosed embodiments include systems and methods for tracking defective memory using a shared memory defect list. Embodiments include firmware that identifies a memory buffer to store a list that includes an entry identifying a portion of memory as defective. The firmware sends an identification of the memory buffer to an operating system. The operating system reads the list from the memory and identifies the portion of defective memory based on the list. The operating system further manages memory locations used based on the identified portion of defective memory and avoids using the portion of defective memory. The firmware persists the contents of the memory to a non-volatile storage prior to shutting down the computer system.