On Wed, May 08, 2013 at 09:55:28PM +0000, Luck, Tony wrote:
> > Because if yes, you won't need any of the HEST header parsing here. So
> > what's up?
>
> I think[1] HEST can tell you which banks report using APEI (as well as/instead of) CMCI.
>
> So a full solution should take into account lots of possibilities:
Great, more fun! :-)
> 1) Some banks may not support CMCI at all (bit 30 in MCi_CTL2 register
> ignores attempts to enable). For these banks Linux should poll.
That's the detection method, try setting bit 30 to see if it sticks?
> 2) BIOS may support generation of APEI records for certain classes of
> errors. HEST will say which banks are affected, and if we prefer APEI,
> we should disable CMCI for these banks (and not poll them).
Ok, so it looks like code should iterate over those and remove them from
the mce_banks list we pass on to machine_check_poll.
> 3) Some banks may support CMCI, but don't have BIOS support to
> generate APEI records. We should continue to enable CMCI for these.
How do you get that out of the HEST? The inability to generate APEI
records.
> We should also take advantage of more information provided in the APEI
> record. We only look at mem_err->physical_addr for memory errors - but
> there are a ton of other potentially interesting things in there.
Ok.
> [1] But I may be misreading ACPI spec - unfortunately it just has
> descriptions of *what* bits do, but no rationale as to *why* anyone
> would want to use them, or tradeoffs between different operating
> modes. Willing to be re-educated if this is all horribly wrong.
Me too. If you haven't noticed, I'm avoiding the APEI spec as much as
possible. :-)
--
Regards/Gruss,
Boris.
Sent from a fat crate under my desk. Formatting is fine.
--
--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
