Sun System Handbook - ISO 3.4 June 2011 Internal/Partner Edition | |||
|
|
Solution Type Sun Alert Sure Solution 1314609.1 : SPARC T3 Sun System Firmware version 8.0.4.b Patches (WITHDRAWN) May Cause FRUID Data to be Deleted
In this Document
Applies to:SPARC T3-4 - Version: Not ApplicableNetra T3-1 - Version: Not Applicable and later [Release: N/A and later] Solaris SPARC Operating System - Version: 10 10/09 U8 and later [Release: 10.0 and later] SPARC T3-1 - Version: Not Applicable and later [Release: N/A and later] SPARC T3-1B - Version: Not Applicable and later [Release: N/A and later] Information in this document applies to any platform. ___________________________________ Date of Workaround Release: 18-Apr-2011 Date of Resolved Release: 19-Apr-2011 __________________________________ DescriptionUpgrading the Sun System Firmware to version 8.0.4.b on the SPARC T3 Systems listed below will cause manufacturing data to be lost in the Field Replaceable Unit ID (FRUID) if there is a subsequent replacement of the Service Processor (SP) or other component containing a FRUID. FRUID information is used by the self healing and reporting features of Solaris 10. The patches listed below that deliver Firmware version 8.0.4.b have been WITHDRAWN and are no longer available. Likelihood of OccurrenceThis issue can occur on the following platforms: SPARC Platform
Notes: 1. The trigger for this issue occurs when a SP card running System Firmware 8.0.4.b which contains cached FRUID data is moved into a different system. The system that the SP has been moved to may experience the deletion of its FRUID data when the system boots up, and an audit determines that the old/incorrect cached data in the SP is inconsistent with the FRIUD of the system. 2. The FRUID corruption only occurs when replacing system components with FRUIDs. Disk drives and Fans can be replaced without any issues as they do not contain a FRUID. 3. To determine the Firmware version on one of these systems, the following command can be run: -> show /HOST
/HOST Targets: bootmode console diag domain tpm Properties: autorestart = reset autorunonerror = false bootfailrecovery = poweroff bootrestart = none boottimeout = 0 hypervisor_version = Hypervisor 1.9.0.b 2010/09/15 01:48 macaddress = 00:21:28:a6:7a:fa maxbootfail = 3 obp_version = OpenBoot 4.32.0.b 2010/09/29 19:13 post_version = POST 4.32.0.a 2010/09/24 20:30 send_break_action = (Cannot show property) status = Solaris running sysfw_version = Sun System Firmware 8.0.0.e 2010/09/30 13:33 <<------<<<< Commands: cd set show -> Possible SymptomsThere are no predictable symptoms that would indicate the described issue has occurred. Workaround or ResolutionIf System Firmware version 8.0.4.b has already been installed, this issue can be avoided by re-installing an earlier firmware version prior to 8.0.4.b. This issue is addressed in the following releases: SPARC Platform
Patches<SUNPATCH:145665-03> <SUNPATCH:145666-04> <SUNPATCH:145667-04> <SUNPATCH:145668-03> <SUNPATCH:145669-03> Modification HistoryDate of Workaround Release: 18-Apr-2011 Re-Release as Resolved: 19-Apr-2011 - Updated Contributing Factors and Resolution This regression was caused by the change made for 7006437 and fixed by 7034289 The problem manifests itself in this way: FRUID data is stored in the non-volatile seeproms and is also cached on the service processor under persist/seeprom which is used to speed up access to the FRUID data. ILOM is responsible for keeping the seeproms and the cached files in sync. When the SP boots, ILOM checks the contents of the cached files against the data in the actual seeprom to see if there are any differences in the data or any corrupted data. Here is where the bug comes into play: If ILOM detects differences between the cached files and the data in the seeprom, it attempts to correct the data either in the seeprom or the cached file. One of the routines used to read out the data actually returns bogus data and the result is a corrupted FRU. Why would the cached data be different from that of the actual seeprom? Mainly when either a new SP or SP from another machine or another FRU is changed in the system, exposing the problem. Internal Contributor/Submitter: chuck.forgues@oracle.com Internal Eng Responsible Engineer: george.kechriotis@oracle.com Oracle Knowledge Analyst: david.mariotto@oracle.com Internal Eng Business Unit Group: Systems Group-SVS (SPARC Volume Systems) Internal Escalation ID: None Internal Pending Patches: 145665-03, 145666-04, 145667-04, 145668-03, 145669-03 Note: Specific Product and Platform choices have been added to this Sun Alert to conform with and enable MOS Hot Topics delivery. (for this doc: Solaris SPARC Operating System - GENERIC (All Platforms) If you have any questions regarding these items, please email: sunalertpublication_us@oracle.com Please send technical questions to the following email: sunalertpublication_us@oracle.com and copy the Responsible Engineer/Contributor listed References<SUNBUG:7034289><SUNPATCH:145665-03> <SUNPATCH:145666-04> <SUNPATCH:145667-04> <SUNPATCH:145668-03> <SUNPATCH:145669-03> Attachments This solution has no attachment |
||||||||||||
|