2010-05-18 14:35:13 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-05-18 14:35:21 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-01-13 09:32:20 +10:30
|
|
|
|
2010-05-18 14:35:21 +08:00
|
|
|
|
2011-07-16 18:14:21 -04:00
|
|
|
|
2012-01-13 09:32:20 +10:30
|
|
|
|
2011-07-16 18:14:21 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-05-18 14:35:13 +08:00
|
|
|
|
2011-01-07 00:55:09 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-05-18 14:35:13 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-05-18 14:35:21 +08:00
|
|
|
|
|
|
|
|
|
ACPI, APEI, Add ERST record ID cache
APEI ERST firmware interface and implementation has no multiple users
in mind. For example, if there is four records in storage with ID: 1,
2, 3 and 4, if two ERST readers enumerate the records via
GET_NEXT_RECORD_ID as follow,
reader 1 reader 2
1
2
3
4
-1
-1
where -1 signals there is no more record ID.
Reader 1 has no chance to check record 2 and 4, while reader 2 has no
chance to check record 1 and 3. And any other GET_NEXT_RECORD_ID will
return -1, that is, other readers will has no chance to check any
record even they are not cleared by anyone.
This makes raw GET_NEXT_RECORD_ID not suitable for used by multiple
users.
To solve the issue, an in-memory ERST record ID cache is designed and
implemented. When enumerating record ID, the ID returned by
GET_NEXT_RECORD_ID is added into cache in addition to be returned to
caller. So other readers can check the cache to get all record ID
available.
Signed-off-by: Huang Ying <ying.huang@intel.com>
Reviewed-by: Andi Kleen <ak@linux.intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
2011-02-21 13:54:41 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-05-18 14:35:21 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-07-22 11:20:11 +02:00
|
|
|
|
|
|
|
|
|
2014-07-22 11:20:13 +02:00
|
|
|
|
2014-07-22 11:20:11 +02:00
|
|
|
|
2010-05-18 14:35:21 +08:00
|
|
|
|
2010-05-18 14:35:13 +08:00
|
|
|
|