Hi, James Carlson wrote: > Cynthia McGuire writes: >> I am sponsoring this case on behalf of Gavin Maltby. This case seeks patch >> binding, with the generic MCA FMA support it delivers targeting a Solaris >> update release. The case straightforwardly extends PSARC/2006/020 and >> PSARC/2006/564 and adds FMA fault and ereport events suitable for generation >> and consumption on all x86 platforms. > [...] >> cpu_ms.AuthenticAMD.15 AMD family 0xf model-specific support >> cpu_ms.AuthenticAMD "Generic AMD" model-specific support > [...] >> d) cpu.generic with cpu_ms.AuthenticAMD > [...] >> This will apply on AMD systems where no more-specific >> model-specific support exists or initializes; this >> will include AMD family 0x10 systems. > > Why is no cpu_ms.AuthenticAMD.16 needed?
AMD family 0x10 will use cpu.generic + cpu_ms.AuthenticAMD to begin with. This actually gives equivalent levels of cpu fault diagnosis to the all-singing-and-dancing family 0xf model-specific support; all that is absent is the fine-grained error classification (eg instead of "correctable level 1 I-cache error" which the generic MCA would give us we could offer "correctable level 1 I-cache erroring during a load from L2"). In time we may deliver cpu_ms.AuthenticAMD.16, or extend cpu_ms.AuthenticAMD to be more widely generic. The latter is our preferred approach. The more pressing need for family 0x10 is to deliver a memory-controller driver akin to what mc-amd does for family 0xf - full topology discovery and physical address to resource resolution - we'll be resourcing that first. Cheers Gavin -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3249 bytes Desc: S/MIME Cryptographic Signature URL: <http://mail.opensolaris.org/pipermail/opensolaris-arc/attachments/20071011/1ceef1d5/attachment.bin>
