| Asset ID: |
1-72-1009648.1 |
| Update Date: | 2012-07-30 |
| Keywords: | |
Solution Type
Problem Resolution Sure
Solution
1009648.1
:
Sun[TM] Fire 3800/4800/4810/6800/E2900/E4900/E6900/V1280 and Netra[TM] 1280/1290 Server: SepromContainer.writeOut: sun.serengeti.I2cException: verify error
| Related Items |
- Sun Fire 4810 Server
- Sun Fire 3800 Server
- Sun Netra 1290 Server
- Sun Fire E6900 Server
- Sun Fire 6800 Server
- Sun Fire V1280 Server
- Sun Fire E2900 Server
- Sun Fire 4800 Server
- Sun Fire E4900 Server
- Sun Netra 1280 Server
|
| Related Categories |
- PLA-Support>Sun Systems>SPARC>Enterprise>SN-SPARC: Exx00
- .Old GCS Categories>Sun Microsystems>Servers>Entry-Level Servers
- .Old GCS Categories>Sun Microsystems>Servers>Midrange Servers
- .Old GCS Categories>Sun Microsystems>Servers>Midrange V and Netra Servers
|
PreviouslyPublishedAs
213283
Applies to:
Sun Netra 1290 Server - Version Not Applicable and later
Sun Netra 1280 Server - Version Not Applicable and later
Sun Fire V1280 Server - Version Not Applicable and later
Sun Fire 3800 Server - Version Not Applicable and later
Sun Fire E6900 Server - Version Not Applicable and later
All Platforms
Symptoms
SepromContainer.writeOut: verify error message are logged by the system controller.
Typical messages:
Example 1
Apr 1 13:33:37 ospprod2 lw8: [ID 575994 kern.error] /N0/SB0/P2/B1/D1: SepromContainer.writeOut:
sun.serengeti.I2cException: verify error: offset=0200, expected=0x00, observed=0x4b
Example 2
May 17 08:07:16 kgebzdb_sc0 Platform.SC: [ID 921792 local0.error] SepromContainer.writeOut: verify
error: offset=0131 expected=c0 observed=be May 17 08:07:16 kgebzdb_sc0 Platform.SC: [ID 481526 local0.error] PS0: SepromContainer.writeOut:
sun.serengeti.I2cException: verify error: offset=0131 expected=c0 observed=be
Example 3
Jun 01 10:10:14 sf6800-1sc0 Platform.SC: [ID 266093 local0.warning] /N0/SB0/P3/B1/D3:
SepromPowerEvent record repaired: 0/0, 0/0
Jun 01 10:10:17 sf6800-1sc0 Platform.SC: [ID 825826 local0.error] SepromContainer.writeOut:
verify error: offset=0038, expected=0xc0, observed=0x00
Jun 01 10:10:17 sf6800-1sc0 Platform.SC: [ID 741626 local0.error] /N0/SB0/P3/B1/D3:
SepromContainer.writeOut: sun.serengeti.I2cException: verify error: offset=0038, expected=0xc0,
observed=0x00
Jun 01 10:10:19 sf6800-1sc0 Platform.SC: [ID 825826 local0.error] SepromContainer.writeOut:
verify error: offset=0038, expected=0xc0, observed=0x00
Jun 01 10:10:19 sf6800-1sc0 Platform.SC: [ID 741626 local0.error] /N0/SB0/P3/B1/D3:
SepromContainer.writeOut: sun.serengeti.I2cException: verify error: offset=0038, expected=0xc0,
observed=0x00
These messages may appear once, a few times, or at regular (4 hours FRU update cycle) intervals.
Cause
Background Information on the Errors
SEEPROMs hold information such as Part Number, Serial Nunmber, power events, etc for various components in the system. Components like DIMMS, SB, IO, PS etc have SEEPROMs. Part of the SEEPROM is fixed, part is dynamic and sometimes modified by ScApp.
In the above example 1, SCAPP wants to write information into DIMM /N0/SB0/P2/B1/D1 's SEEPROM via the I2c bus. Upon verification of that write, SCAPP discovers a mismatch.
The SepromContainer.writeOut verify error does not affect Solaris[TM] Operating System Domains at all and is essentially harmless because the error is taking place in an area (SEEPROM) that Solaris does not utilize.
Solution
Suggested Action Plan
In most cases, the problem can be ignored because the error is not in a region that will cause a domain outage. The biggest issue with this error is whether or not the messages themselves are excessive or not.
- If the errors have ceased or only a single event (or multiple events only on a single day) were reported but have ceased, the FRU should not be replaced.
- In the situation where the errors persist (multiple days or by an excessive amount) the errors themselves are an annoyance that merits some action. The only way to correct it is to replace the reported FRU. This service can be scheduled for a regular maintanence window - as the error iteself is not critical (just annoying).
In example 3 above, the logical error in the seeprom segments were repaired. The errors were caused by an abrupt power loss, as might happen if the Frame Manager keyswitch were turned off while one or more domain setkeyswitch on operations were underway. A number of seeprom segments were half written when the power was lost. At recent FW levels, in this case 5.19.5, the ScApp methods that write the records will quietly clean these incomplete records up as it discovers them.
In this case, the customer was using the ttya interface on the master SC and was flooded with these messages. We do not suppress the repair messages to the tty, and if a large number of records are damaged, the messages will take some time to scroll by at 9600 BPS.
Additional Information
In cases where several FRUs are reported, then the problem might be the I2C bus itself.
The I2C bus runs from the system controller(s) to all FRU holding SEEPROMs. Example:
SC --> centerplane --> SB --> DIMM
In cases where a section of the I2C bus is bad, other errors like I2C timeouts (I2cComm.busyWait) might be reported. The faulty FRU must then be located by finding where in the tree the problem starts.
In this case contact sun support services to help determine the source of the fault.
Product
Sun Fire V1280 Server
Sun Fire E6900 Server
Sun Fire E4900 Server
Sun Fire E2900 Server
Sun Fire 6800 Server
Sun Fire 4810 Server
Sun Fire 4800 Server
Sun Fire 3800 Server
Sun Netra 1290 Server
Netra 1280 Server
Try to persuade customers not to ask for replacement.
Examples for the the situation described in the "Additional Information" section, can be found here: <Document: 1005071.1> .
SepromContainer.writeOut, verify error, seprom, seeprom, DIMM, PS, I2cException
Previously Published As 85226
Attachments
This solution has no attachment
