On 10/11/07 16:50, James Carlson wrote: > Gavin Maltby writes: >> 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"). > > OK; thanks. > >> 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. > > So we expect things to peel off into a ".16" version only when those > errors become not-generic, which might not be noticable until there's > a "0x11" family ... right? >
Correct. The intention is to have cpu_ms.AuthenticAMD support new AMD models for as long as it can. Right now there is no code sharing between model-specific modules, not even between cpu_ms.AuthenticAMD.15 and cpu_ms.AuthenticAMD, so spinning off a new cpu_ms.AuthenticAMD.16 involves a fresh start and an initial exercise in identifying and factoring out common functionality. My expectation is that the generic AMD module will be sufficient to handle CPU errors for some time, but we will need detailed model-specific memory-controller driver support. 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/a818a522/attachment.bin>
