SepromContainer.writeOut: sun.serengeti.I2cException: verify error:

Asset ID:	1-72-1009648.1
Update Date:	2010-07-06
Keywords:

Solution Type Problem Resolution Sure

Solution 1009648.1 : SepromContainer.writeOut: sun.serengeti.I2cException: verify error:

Related Items


Sun Fire E6900 Server
 Sun Fire 3800 Server
 Sun Fire 6800 Server
 Sun Netra 1280 Server
 Sun Fire E4900 Server
 Sun Fire 4800 Server
 Sun Fire V1280 Server
 Sun Fire E2900 Server
 Sun Netra 1290 Server
 Sun Fire 4810 Server

Related Categories


GCS>Sun Microsystems>Servers>Midrange V and Netra Servers
 GCS>Sun Microsystems>Servers>Entry-Level Servers
 GCS>Sun Microsystems>Servers>Midrange Servers

PreviouslyPublishedAs
213283

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.

Resolution
Suggested course of action
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.

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.

Relief/Workaround

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

Internal Comments
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