From cindi@sac.sfbay.sun.com Wed Oct 10 20:49:49 2007 Received: from sunmail4.Singapore.Sun.COM (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l9B3nmUF005389 for ; Wed, 10 Oct 2007 20:49:48 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail4.Singapore.Sun.COM (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id l9B3kSsU015208; Thu, 11 Oct 2007 11:46:31 +0800 (SGT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JPQ00H19AHF1H00@brm-avmta-1.central.sun.com>; Wed, 10 Oct 2007 21:46:28 -0600 (MDT) Received: from dm-sfbay-02.sfbay.sun.com ([129.146.11.31]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JPQ007FWAHENJC0@brm-avmta-1.central.sun.com>; Wed, 10 Oct 2007 21:46:26 -0600 (MDT) Received: from sac.sfbay.sun.com (new-sac.SFBay.Sun.COM [129.146.175.65]) by dm-sfbay-02.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id l9B3kQq4021653; Wed, 10 Oct 2007 20:46:26 -0700 (PDT) Received: from sac.sfbay.sun.com (localhost [127.0.0.1]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l9B3ncR1005384; Wed, 10 Oct 2007 20:49:38 -0700 (PDT) Received: (from cindi@localhost) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8/Submit) id l9B3ncGN005380; Wed, 10 Oct 2007 20:49:38 -0700 (PDT) Date: Wed, 10 Oct 2007 20:49:38 -0700 (PDT) From: Cynthia McGuire Subject: Generic x86 Machine Check Architecture FMA [PSARC/2007/591 Self Review] To: PSARC-ext@Sun.COM Cc: fma-core@Sun.COM Message-id: <200710110349.l9B3ncGN005380@sac.sfbay.sun.com> Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 Status: RO Content-Length: 6960 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. Cindi This information is Copyright 2007 Sun Microsystems 1. Introduction 1.1. Project/Component Working Name: Generic x86 Machine Check Architecture FMA 1.2. Name of Document Author/Supplier: Author: Gavin Maltby 1.3 Date of This Document: 10 October, 2007 4. Technical Description 4.1. Project Summary 4.1.1 Project Description: CPU, and in some cases memory, error report telemetry falls under the Machine Check Architecture which all recent AMD and Intel x86 chip offerings conform to. Existing FMA support for x86 chips is limited to AMD family 0xf alone - Opteron/Athlon64/Turion64 revisions B to F that have shipped in Sun x64 systems to date. In expanding this support to include the upcoming AMD family 0x10 and new Sun Intel-based x64 products we have implemented a generic machine check architecture FMA implementation that supports all chips that support the MCA, and have layered the existing AMD support and additional model-specific support on top of that. This case presents the new FMA events that are defined for the new generic MCA implementation, and modifies the definitions of existing AMD events. The associated FMA portfolio referenced below has already been approved at FMA portfolio review. 4.1.2 Details: The existing implementation for AMD family 0xf delivered a "cpu module" cpu.AuthenticAMD.15 which contains all the smarts for error handling, error classification, error logging etc. The telemetry arising from this module is consumed by the eversholt diagnosis engine, applying a set of AMD-specific rules. For any other chip type (i.e., not AMD family 0xf) a dumb cpu.generic module provided token support for machine check traps, and raises no telemetry for diagnosis. In the new implementation most of the existing AMD code is refactored into an improved and fully FMA-aware cpu.generic. Model-specific aspects such as the more-detailed error classification possible with AMD chips (i.e., classification beyond what is considered "architectural" in the generic MCA) is performed in a relatively lightweight "model-specific cpu module" that is layered on top of cpu.generic. The following model-specific modules will be delivered: Module Description ----------------------- --------------------------------------- cpu_ms.AuthenticAMD.15 AMD family 0xf model-specific support cpu_ms.AuthenticAMD "Generic AMD" model-specific support cpu_ms.GenuineIntel "Generic Intel" model-specific support The following support combinations are possible: a) cpu.generic absent Ereport classes: None Fault classes: The system will have zero MCA capability and no FMA event will be raised for cpu or memory. b) cpu.generic with no model-specific module Ereport classes: ereport.cpu.generic-x86.* Fault classes: fault.cpu.generic-x86.* This applies on chips that are not from AMD or Intel. It also applies if no AMD or Intel model-specific support initializes, which could occur on an error or on disabling and would also occur for new chip families from AMD and Intel that not even the "generic AMD" and "generic Intel" model-specific modules are able to claim support for. Telemetry will be raised entirely by cpu.generic in the ereport.cpu.generic-x86.* ereport class, with no model-specific augmentation. It will be diagnosed by a corresponding set of eversholt rules to produce faults in the class fault.cpu.generic-x86.*. c) cpu.generic with cpu_ms.AuthenticAMD.15 Ereport classes: ereport.cpu.amd.* Fault classes: fault.cpu.amd.*, fault.memory.* This applies to AMD family 0xf systems, i.e. it is the combination that replaces cpu.AuthenticAMD.15 that is the only current Solaris MCA support for x86 systems To maintain compatibility, this combination will produce ereports in the precisely the same classes as before - ereport.cpu.amd.*, and the existing AMD eversholt rules will diagnose these to fault.cpu.amd.* and fault.memory.amd.*. This is achieved by cpu.generic allowing model-specific support to classify the error and provide the ereport class to use. The ereport payload *is* changed since most of it is now generated by cpu.generic with only a limited degree of augmentation from the model-specific support; this change is limited to the renaming of a number of ereport payload members, and the addition of a number of new members. The few AMD diagnosis rules that access payload members are changed to use the new names. In the events defintions, existing AMD ereports are retained as payload version 0 while the revised (renamed, extended) payload is introduced as payload version 1. d) cpu.generic with cpu_ms.AuthenticAMD Ereport classes: ereport.cpu.generic-x86.* Fault classes: fault.cpu.generic-x86.*, fault.memory.generic-x86.* This will apply on AMD systems where no more-specific model-specific support exists or initializes; this will include AMD family 0x10 systems. Most telemetry is provided entirely by cpu.generic. Since these AMD systems include an on-chip memory-controller which falls under the MCA umbrella we can also recognise and diagnose memory errors, and this is done in the model-specific module. e) cpu.generic with cpu_ms.GenuineIntel Ereport classes: ereport.cpu.intel.* Fault classes: fault.cpu.intel.*, This case presents the FMA events for a) - d). A separate case will present the events for e) along with additional Intel memory-controller-hub events. The accompanying erecheck.html details all changes to the SMI Events Registry. The associated FMA portfolio is here: http://wikihome.sfbay.sun.com/fma-portfolio/Wiki.jsp?page=2007.025.x86MCA The portfolio includes full philosophy and diagnosis documents. 4.5. Interfaces: The "cpu module interface" was introduced by the AMD FMA work. It is a project-private interface. The current work substantially revises this interface and, in particular, prepares it to work in the presence of a hypervisor such as Solaris xVM (changing it from a "cpu_t interface" to a "chip/core/strand interface". The interface remains project-private. 4.9. I18N/L10N Impact: A new FMA dictionary and .po/.mo "GMCA" are delivered. 5. Reference Documents: PSARC/2006/564 FMA for Athlon 64 and Opteron Rev F/G Processors PSARC/2006/020 FMA for Athlon 64 and Opteron Processors 6. Resources and Schedule 6.4. Steering Committee requested information 6.4.1. Consolidation C-team Name: ON 6.5. ARC review type: Automatic 6.6. ARC Exposure: open From carlsonj@phorcys.east.sun.com Thu Oct 11 04:46:55 2007 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l9BBkt81013488 for ; Thu, 11 Oct 2007 04:46:55 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l9BBgZus054480; Thu, 11 Oct 2007 05:42:35 -0600 (MDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JPQ00401WKQP400@brm-avmta-1.central.sun.com>; Thu, 11 Oct 2007 05:43:38 -0600 (MDT) Received: from phorcys.east.sun.com ([129.148.174.143]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JPQ0018PWKPH540@brm-avmta-1.central.sun.com>; Thu, 11 Oct 2007 05:43:37 -0600 (MDT) Received: from phorcys.east.sun.com (localhost [127.0.0.1]) by phorcys.east.sun.com (8.14.1+Sun/8.14.1) with ESMTP id l9BBhKxJ014431; Thu, 11 Oct 2007 07:43:20 -0400 (EDT) Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.14.1+Sun/8.14.1/Submit) id l9BBhKVt014428; Thu, 11 Oct 2007 07:43:20 -0400 (EDT) Date: Thu, 11 Oct 2007 07:43:20 -0400 From: James Carlson Subject: Re: Generic x86 Machine Check Architecture FMA [PSARC/2007/591 Self Review] In-reply-to: <200710110349.l9B3ncGN005380@sac.sfbay.sun.com> To: Cynthia McGuire Cc: PSARC-ext@Sun.Com, fma-core@Sun.Com Message-id: <18190.3160.396997.855190@gargle.gargle.HOWL> MIME-version: 1.0 X-Mailer: VM 7.01 under Emacs 21.3.1 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <200710110349.l9B3ncGN005380@sac.sfbay.sun.com> Status: RO Content-Length: 1073 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? Is the 0x10 family MCA a subset of the 0xf family? Or are there future projects in this area? -- James Carlson, Solaris Networking Sun Microsystems / 35 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 From Gavin.Maltby@sun.com Thu Oct 11 08:47:16 2007 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l9BFlFPJ018932 for ; Thu, 11 Oct 2007 08:47:15 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail2sca.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l9BFhwsC020459; Thu, 11 Oct 2007 08:43:59 -0700 (PDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JPR008077PA3V00@nwk-avmta-2.sfbay.sun.com>; Thu, 11 Oct 2007 08:43:58 -0700 (PDT) Received: from gmp-eb-mail-1.sun.com ([192.18.6.21]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JPR0018R7P9CU90@nwk-avmta-2.sfbay.sun.com>; Thu, 11 Oct 2007 08:43:57 -0700 (PDT) Received: from fe-emea-09.sun.com (gmp-eb-lb-2-fe1.eu.sun.com [192.18.6.10]) by gmp-eb-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id l9BFhuqN024884; Thu, 11 Oct 2007 15:43:56 +0000 (GMT) Received: from conversion-daemon.fe-emea-09.sun.com by fe-emea-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JPR00E017IJ6M00@fe-emea-09.sun.com> (original mail from Gavin.Maltby@Sun.COM); Thu, 11 Oct 2007 16:43:56 +0100 (BST) Received: from [129.156.173.103] by fe-emea-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JPR00EQJ7P0UI80@fe-emea-09.sun.com>; Thu, 11 Oct 2007 16:43:48 +0100 (BST) Date: Thu, 11 Oct 2007 16:43:48 +0100 From: Gavin Maltby Subject: Re: Generic x86 Machine Check Architecture FMA [PSARC/2007/591 Self Review] In-reply-to: <18190.3160.396997.855190@gargle.gargle.HOWL> Sender: Gavin.Maltby@sun.com To: James Carlson Cc: Cynthia McGuire , PSARC-ext@sun.com, fma-core@sun.com Message-id: <470E44B4.5070808@sun.com> MIME-version: 1.0 Content-type: multipart/signed; boundary=------------ms060407070207090501040300; micalg=sha1; protocol="application/x-pkcs7-signature" X-PMX-Version: 5.2.0.264296 References: <200710110349.l9B3ncGN005380@sac.sfbay.sun.com> <18190.3160.396997.855190@gargle.gargle.HOWL> User-Agent: Thunderbird 2.0.0.4 (X11/20070827) Status: RO Content-Length: 6429 --------------ms060407070207090501040300 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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 --------------ms060407070207090501040300 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJDzCC AuIwggJLoAMCAQICEHLr6d93IQyOwAp+eWFR0hwwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UE BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA3MDIwODEyMTU1NFoX DTA4MDIwODEyMTU1NFowRjEfMB0GA1UEAxMWVGhhd3RlIEZyZWVtYWlsIE1lbWJlcjEjMCEG CSqGSIb3DQEJARYUZ2F2aW4ubWFsdGJ5QHN1bi5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IB DwAwggEKAoIBAQCkE5nmHpPm3K1aBkuItAibRDGls3v9CVgahxercFIwMinnvY4cxp5dL6A0 KZQY0W8bRtGAPmjzzFGLKmw+ItSRY+aebkQv+g/njUjipqHlshHQHlQ+FrQI5h8DAXjWKmGu gwrM/d6KmFaK96Sn40DqlN7+0z2j7uRrYOASJyxbn9hPK58CjVwjvcKono+7sM6idVMUmxLo X4lbD1gjmcc2Mn8fIKzAWHU32i56ec1N3CIPJGDQkBL/Mttb7xzeC2sr+vQ+euy9nYZf18eq x/VBcmCa/nWoTSsFuO/1i5bgMYo/71LmgwF9juTrCwRATBCiPNFGcIb6awrSMsCKV021AgMB AAGjMTAvMB8GA1UdEQQYMBaBFGdhdmluLm1hbHRieUBzdW4uY29tMAwGA1UdEwEB/wQCMAAw DQYJKoZIhvcNAQEFBQADgYEAiUAQHJHe9eF2KEp5tUhyx27Wewu99DVcDu/VZXvWZtr82Dxj ad99TCBEcfXdPNFdH0MZh1Chyd8FShn2PtnvlnYE/6wOsce3mzdLjoGH2cQUkc8+s94h0Tlh c8ABU9xrQvDvkn91P5fOyA4yGmMYzuSL2MJxemCMs1Ho86UoGoMwggLiMIICS6ADAgECAhBy 6+nfdyEMjsAKfnlhUdIcMA0GCSqGSIb3DQEBBQUAMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQK ExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29u YWwgRnJlZW1haWwgSXNzdWluZyBDQTAeFw0wNzAyMDgxMjE1NTRaFw0wODAyMDgxMjE1NTRa MEYxHzAdBgNVBAMTFlRoYXd0ZSBGcmVlbWFpbCBNZW1iZXIxIzAhBgkqhkiG9w0BCQEWFGdh dmluLm1hbHRieUBzdW4uY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEApBOZ 5h6T5tytWgZLiLQIm0QxpbN7/QlYGocXq3BSMDIp572OHMaeXS+gNCmUGNFvG0bRgD5o88xR iypsPiLUkWPmnm5EL/oP541I4qah5bIR0B5UPha0COYfAwF41iphroMKzP3eiphWivekp+NA 6pTe/tM9o+7ka2DgEicsW5/YTyufAo1cI73CqJ6Pu7DOonVTFJsS6F+JWw9YI5nHNjJ/HyCs wFh1N9ouennNTdwiDyRg0JAS/zLbW+8c3gtrK/r0PnrsvZ2GX9fHqsf1QXJgmv51qE0rBbjv 9YuW4DGKP+9S5oMBfY7k6wsEQEwQojzRRnCG+msK0jLAildNtQIDAQABozEwLzAfBgNVHREE GDAWgRRnYXZpbi5tYWx0YnlAc3VuLmNvbTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBQUA A4GBAIlAEByR3vXhdihKebVIcsdu1nsLvfQ1XA7v1WV71mba/Ng8Y2nffUwgRHH13TzRXR9D GYdQocnfBUoZ9j7Z75Z2BP+sDrHHt5s3S46Bh9nEFJHPPrPeIdE5YXPAAVPca0Lw75J/dT+X zsgOMhpjGM7ki9jCcXpgjLNR6POlKBqDMIIDPzCCAqigAwIBAgIBDTANBgkqhkiG9w0BAQUF ADCB0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2Fw ZSBUb3duMRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNh dGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMB4X DTAzMDcxNzAwMDAwMFoXDTEzMDcxNjIzNTk1OVowYjELMAkGA1UEBhMCWkExJTAjBgNVBAoT HFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25h bCBGcmVlbWFpbCBJc3N1aW5nIENBMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDEpjxV c1X7TrnKmVoeaMB1BHCd3+n/ox7svc31W/Iadr1/DDph8r9RzgHU5VAKMNcCY1osiRVwjt3J 8CuFWqo/cVbLrzwLB+fxH5E2JCoTzyvV84J3PQO+K/67GD4Hv0CAAmTXp6a7n2XRxSpUhQ9I BH+nttE8YQRAHmQZcmC3+wIDAQABo4GUMIGRMBIGA1UdEwEB/wQIMAYBAf8CAQAwQwYDVR0f BDwwOjA4oDagNIYyaHR0cDovL2NybC50aGF3dGUuY29tL1RoYXd0ZVBlcnNvbmFsRnJlZW1h aWxDQS5jcmwwCwYDVR0PBAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRl TGFiZWwyLTEzODANBgkqhkiG9w0BAQUFAAOBgQBIjNFQg+oLLswNo2asZw9/r6y+whehQ5aU nX9MIbj4Nh+qLZ82L8D0HFAgk3A8/a3hYWLD2ToZfoSxmRsAxRoLgnSeJVCUYsfbJ3FXJY3d qZw5jowgT2Vfldr394fWxghOrvbqNOUQGls1TXfjViF4gtwhGTXeJLHTHUb/XV9lTzGCA2Qw ggNgAgEBMHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQ dHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENB AhBy6+nfdyEMjsAKfnlhUdIcMAkGBSsOAwIaBQCgggHDMBgGCSqGSIb3DQEJAzELBgkqhkiG 9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTA3MTAxMTE1NDM0OFowIwYJKoZIhvcNAQkEMRYEFJ8S fnptksBAXnGGDrhR/EPivw6RMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZI hvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGFBgkr BgEEAYI3EAQxeDB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGlu ZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWlu ZyBDQQIQcuvp33chDI7ACn55YVHSHDCBhwYLKoZIhvcNAQkQAgsxeKB2MGIxCzAJBgNVBAYT AlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNU aGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQcuvp33chDI7ACn55YVHSHDAN BgkqhkiG9w0BAQEFAASCAQCV6QFtqGaQfRPe2wfwnf4djCLZ9RSLrEG6E4tFxyiDdO1qC7Gl p8z00s/ZpAtYMDpb+UoPaOHEJsIN004cqVr0/3sZo9aqaAVKnosPI7RNQJXs2YyxtsDDwJQw B/7BQ366Uywk/ocDvO5DwM9Wx3EcwhkJvX/X9v4ANWoS2FthhQw2oOkf6n6lghxB7gSnfCK0 ITCrUYP6DvmIhIpR83ybRzIpmAJYSmE3J9P6bVfLZVny3vSwnFxa27EH7pH3O/afxjqu2m3c EpwwsHmr/wd6W/nb9dI+ZMtBigx2jKiPuk7D5O2eT1UEO+QgLumSH8LmYySyZaYamVTB7qYh P9v3AAAAAAAA --------------ms060407070207090501040300-- From carlsonj@phorcys.east.sun.com Thu Oct 11 08:54:35 2007 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l9BFsY4X019429 for ; Thu, 11 Oct 2007 08:54:35 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail5.uk.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l9BFoeKv026969; Thu, 11 Oct 2007 16:51:17 +0100 (BST) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JPR0081J81FII00@nwk-avmta-2.sfbay.sun.com>; Thu, 11 Oct 2007 08:51:15 -0700 (PDT) Received: from phorcys.east.sun.com ([129.148.174.143]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JPR001PC81ECV90@nwk-avmta-2.sfbay.sun.com>; Thu, 11 Oct 2007 08:51:14 -0700 (PDT) Received: from phorcys.east.sun.com (localhost [127.0.0.1]) by phorcys.east.sun.com (8.14.1+Sun/8.14.1) with ESMTP id l9BFoumq021096; Thu, 11 Oct 2007 11:50:56 -0400 (EDT) Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.14.1+Sun/8.14.1/Submit) id l9BFotFa021093; Thu, 11 Oct 2007 11:50:55 -0400 (EDT) Date: Thu, 11 Oct 2007 11:50:55 -0400 From: James Carlson Subject: Re: Generic x86 Machine Check Architecture FMA [PSARC/2007/591 Self Review] In-reply-to: <470E44B4.5070808@sun.com> To: Gavin Maltby Cc: PSARC-ext@sun.com, Cynthia McGuire , fma-core@sun.com Message-id: <18190.18015.946736.763264@gargle.gargle.HOWL> MIME-version: 1.0 X-Mailer: VM 7.01 under Emacs 21.3.1 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <200710110349.l9B3ncGN005380@sac.sfbay.sun.com> <18190.3160.396997.855190@gargle.gargle.HOWL> <470E44B4.5070808@sun.com> Status: RO Content-Length: 1246 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? -- James Carlson, Solaris Networking Sun Microsystems / 35 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 From Gavin.Maltby@Sun.COM Thu Oct 11 15:04:37 2007 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l9BM4alg003680 for ; Thu, 11 Oct 2007 15:04:36 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l9BM0FCx003975; Thu, 11 Oct 2007 16:00:15 -0600 (MDT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JPR00B09P67J400@nwk-avmta-1.sfbay.Sun.COM>; Thu, 11 Oct 2007 15:01:19 -0700 (PDT) Received: from gmp-eb-mail-2.sun.com ([192.18.6.24]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JPR00GTIP666N70@nwk-avmta-1.sfbay.Sun.COM>; Thu, 11 Oct 2007 15:01:19 -0700 (PDT) Received: from fe-emea-10.sun.com (gmp-eb-lb-2-fe2.eu.sun.com [192.18.6.11]) by gmp-eb-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id l9BM1H4t003371; Thu, 11 Oct 2007 22:01:17 +0000 (GMT) Received: from conversion-daemon.fe-emea-10.sun.com by fe-emea-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JPR00I01P1R4O00@fe-emea-10.sun.com> (original mail from Gavin.Maltby@Sun.COM); Thu, 11 Oct 2007 23:01:17 +0100 (BST) Received: from [129.150.121.126] by fe-emea-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JPR00GN6P65D5A0@fe-emea-10.sun.com>; Thu, 11 Oct 2007 23:01:17 +0100 (BST) Date: Thu, 11 Oct 2007 22:58:06 +0100 From: Gavin Maltby Subject: Re: Generic x86 Machine Check Architecture FMA [PSARC/2007/591 Self Review] In-reply-to: <18190.18015.946736.763264@gargle.gargle.HOWL> Sender: Gavin.Maltby@Sun.COM To: James Carlson Cc: PSARC-ext@Sun.COM, Cynthia McGuire , fma-core@Sun.COM Message-id: <470E9C6E.1040605@sun.com> MIME-version: 1.0 Content-type: multipart/signed; boundary=------------ms090805010702060501030309; micalg=sha1; protocol="application/x-pkcs7-signature" X-PMX-Version: 5.2.0.264296 References: <200710110349.l9B3ncGN005380@sac.sfbay.sun.com> <18190.3160.396997.855190@gargle.gargle.HOWL> <470E44B4.5070808@sun.com> <18190.18015.946736.763264@gargle.gargle.HOWL> User-Agent: Thunderbird 2.0.0.4 (X11/20070827) Status: RO Content-Length: 6476 --------------ms090805010702060501030309 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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 --------------ms090805010702060501030309 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJDzCC AuIwggJLoAMCAQICEHLr6d93IQyOwAp+eWFR0hwwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UE BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA3MDIwODEyMTU1NFoX DTA4MDIwODEyMTU1NFowRjEfMB0GA1UEAxMWVGhhd3RlIEZyZWVtYWlsIE1lbWJlcjEjMCEG CSqGSIb3DQEJARYUZ2F2aW4ubWFsdGJ5QHN1bi5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IB DwAwggEKAoIBAQCkE5nmHpPm3K1aBkuItAibRDGls3v9CVgahxercFIwMinnvY4cxp5dL6A0 KZQY0W8bRtGAPmjzzFGLKmw+ItSRY+aebkQv+g/njUjipqHlshHQHlQ+FrQI5h8DAXjWKmGu gwrM/d6KmFaK96Sn40DqlN7+0z2j7uRrYOASJyxbn9hPK58CjVwjvcKono+7sM6idVMUmxLo X4lbD1gjmcc2Mn8fIKzAWHU32i56ec1N3CIPJGDQkBL/Mttb7xzeC2sr+vQ+euy9nYZf18eq x/VBcmCa/nWoTSsFuO/1i5bgMYo/71LmgwF9juTrCwRATBCiPNFGcIb6awrSMsCKV021AgMB AAGjMTAvMB8GA1UdEQQYMBaBFGdhdmluLm1hbHRieUBzdW4uY29tMAwGA1UdEwEB/wQCMAAw DQYJKoZIhvcNAQEFBQADgYEAiUAQHJHe9eF2KEp5tUhyx27Wewu99DVcDu/VZXvWZtr82Dxj ad99TCBEcfXdPNFdH0MZh1Chyd8FShn2PtnvlnYE/6wOsce3mzdLjoGH2cQUkc8+s94h0Tlh c8ABU9xrQvDvkn91P5fOyA4yGmMYzuSL2MJxemCMs1Ho86UoGoMwggLiMIICS6ADAgECAhBy 6+nfdyEMjsAKfnlhUdIcMA0GCSqGSIb3DQEBBQUAMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQK ExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29u YWwgRnJlZW1haWwgSXNzdWluZyBDQTAeFw0wNzAyMDgxMjE1NTRaFw0wODAyMDgxMjE1NTRa MEYxHzAdBgNVBAMTFlRoYXd0ZSBGcmVlbWFpbCBNZW1iZXIxIzAhBgkqhkiG9w0BCQEWFGdh dmluLm1hbHRieUBzdW4uY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEApBOZ 5h6T5tytWgZLiLQIm0QxpbN7/QlYGocXq3BSMDIp572OHMaeXS+gNCmUGNFvG0bRgD5o88xR iypsPiLUkWPmnm5EL/oP541I4qah5bIR0B5UPha0COYfAwF41iphroMKzP3eiphWivekp+NA 6pTe/tM9o+7ka2DgEicsW5/YTyufAo1cI73CqJ6Pu7DOonVTFJsS6F+JWw9YI5nHNjJ/HyCs wFh1N9ouennNTdwiDyRg0JAS/zLbW+8c3gtrK/r0PnrsvZ2GX9fHqsf1QXJgmv51qE0rBbjv 9YuW4DGKP+9S5oMBfY7k6wsEQEwQojzRRnCG+msK0jLAildNtQIDAQABozEwLzAfBgNVHREE GDAWgRRnYXZpbi5tYWx0YnlAc3VuLmNvbTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBQUA A4GBAIlAEByR3vXhdihKebVIcsdu1nsLvfQ1XA7v1WV71mba/Ng8Y2nffUwgRHH13TzRXR9D GYdQocnfBUoZ9j7Z75Z2BP+sDrHHt5s3S46Bh9nEFJHPPrPeIdE5YXPAAVPca0Lw75J/dT+X zsgOMhpjGM7ki9jCcXpgjLNR6POlKBqDMIIDPzCCAqigAwIBAgIBDTANBgkqhkiG9w0BAQUF ADCB0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2Fw ZSBUb3duMRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNh dGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMB4X DTAzMDcxNzAwMDAwMFoXDTEzMDcxNjIzNTk1OVowYjELMAkGA1UEBhMCWkExJTAjBgNVBAoT HFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25h bCBGcmVlbWFpbCBJc3N1aW5nIENBMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDEpjxV c1X7TrnKmVoeaMB1BHCd3+n/ox7svc31W/Iadr1/DDph8r9RzgHU5VAKMNcCY1osiRVwjt3J 8CuFWqo/cVbLrzwLB+fxH5E2JCoTzyvV84J3PQO+K/67GD4Hv0CAAmTXp6a7n2XRxSpUhQ9I BH+nttE8YQRAHmQZcmC3+wIDAQABo4GUMIGRMBIGA1UdEwEB/wQIMAYBAf8CAQAwQwYDVR0f BDwwOjA4oDagNIYyaHR0cDovL2NybC50aGF3dGUuY29tL1RoYXd0ZVBlcnNvbmFsRnJlZW1h aWxDQS5jcmwwCwYDVR0PBAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRl TGFiZWwyLTEzODANBgkqhkiG9w0BAQUFAAOBgQBIjNFQg+oLLswNo2asZw9/r6y+whehQ5aU nX9MIbj4Nh+qLZ82L8D0HFAgk3A8/a3hYWLD2ToZfoSxmRsAxRoLgnSeJVCUYsfbJ3FXJY3d qZw5jowgT2Vfldr394fWxghOrvbqNOUQGls1TXfjViF4gtwhGTXeJLHTHUb/XV9lTzGCA2Qw ggNgAgEBMHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQ dHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENB AhBy6+nfdyEMjsAKfnlhUdIcMAkGBSsOAwIaBQCgggHDMBgGCSqGSIb3DQEJAzELBgkqhkiG 9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTA3MTAxMTIxNTgwNlowIwYJKoZIhvcNAQkEMRYEFIUj 7Zorz1+ftC51yi0q0PmSZ+znMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZI hvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGFBgkr BgEEAYI3EAQxeDB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGlu ZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWlu ZyBDQQIQcuvp33chDI7ACn55YVHSHDCBhwYLKoZIhvcNAQkQAgsxeKB2MGIxCzAJBgNVBAYT AlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNU aGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQcuvp33chDI7ACn55YVHSHDAN BgkqhkiG9w0BAQEFAASCAQBlyMOWr4dc9ckiMV7ck3hfg8P0tJbBHolAN/yCVbBnIl34PR5J kW7S2nI1Qn2kJUEvBwDUDVYo5SeY2sFX8duQPwyepqeRIQaYqNRhg0EyIvwZ+LHOdlblu4XF oJgRGrsSF1drzmCW18FYWVQUfn2ebS86HOes9016jAgtrRGqaIWohDoiWlN5wdjH5p/IV6SH 6owGCI6rSfi8EwYYIeDrZ7QUFOAwGYEiGAWEudOZnBEX0WWR1Eva7+A8fq/AqhQpGplxzAoP nCdwiWXHEAItPoM+TKTHU5u+qD13La7XepMYJKYKyGzsZXQo1c594OxifXSCueckXQcRCzi2 5JQbAAAAAAAA --------------ms090805010702060501030309-- From carlsonj@phorcys.east.sun.com Fri Oct 12 05:36:36 2007 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l9CCaapB017136 for ; Fri, 12 Oct 2007 05:36:36 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail2sca.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l9CCXHkG021266; Fri, 12 Oct 2007 05:33:17 -0700 (PDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JPS00G1LTJHBR00@brm-avmta-1.central.sun.com>; Fri, 12 Oct 2007 06:33:17 -0600 (MDT) Received: from phorcys.east.sun.com ([129.148.174.143]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JPS006ECTJGV770@brm-avmta-1.central.sun.com>; Fri, 12 Oct 2007 06:33:16 -0600 (MDT) Received: from phorcys.east.sun.com (localhost [127.0.0.1]) by phorcys.east.sun.com (8.14.1+Sun/8.14.1) with ESMTP id l9CCWuFo009686; Fri, 12 Oct 2007 08:32:56 -0400 (EDT) Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.14.1+Sun/8.14.1/Submit) id l9CCWu8u009683; Fri, 12 Oct 2007 08:32:56 -0400 (EDT) Date: Fri, 12 Oct 2007 08:32:56 -0400 From: James Carlson Subject: Re: Generic x86 Machine Check Architecture FMA [PSARC/2007/591 Self Review] In-reply-to: <470E9C6E.1040605@sun.com> To: Gavin Maltby Cc: PSARC-ext@sun.com, Cynthia McGuire , fma-core@sun.com Message-id: <18191.27000.746009.693722@gargle.gargle.HOWL> MIME-version: 1.0 X-Mailer: VM 7.01 under Emacs 21.3.1 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <200710110349.l9B3ncGN005380@sac.sfbay.sun.com> <18190.3160.396997.855190@gargle.gargle.HOWL> <470E44B4.5070808@sun.com> <18190.18015.946736.763264@gargle.gargle.HOWL> <470E9C6E.1040605@sun.com> Status: RO Content-Length: 993 Gavin Maltby writes: > 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. OK; thanks. That's what I wanted. (In case you're curious, I was checking to see what we might need to tell future project teams if someone else were to do the work.) -- James Carlson, Solaris Networking Sun Microsystems / 35 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677