Solaris SPARC Operating System - Version 10 10/09 U8 to 10 10/09 U8 [Release 10.0]
Information in this document applies to any platform.
Date of Resolved Release: 16-Sep-2011
_______________________________________
Description
SPARC T3-1/Netra T3-1 systems may experience "hot removal of /SYS/PDB" errors and shut down.
Occurrence
This issue can occur on the following platforms:
SPARC Platform
- SPARC T3-1 without System Firmware version 8.1.0.e (as delivered in patch 147315-03)
- Netra T3-1 without System Firmware version 8.1.0.e (as delivered in patch 147319-03)
Note: This issue only occurs on the SPARC T3-1 and Netra T3-1 systems.
Symptoms
If the described issue occurs, errors similar to the following will be seen in the event logs:
Chassis Action major
Hot insertion of /SYS/PDB
Chassis Action minor
Inventory has been updated starting at node '/SYS'
Fault Fault critical
Fault detected at time = The suspect component:
/SYS has fault.component.missing with probability=100. Refer to
http://www.sun.com/msg/SPT-8000-J4 for details.
System Log minor
Host: Powered Off
Chassis Action major
Hot removal of /SYS/PDB
Workaround
There is no workaround for this issue.
This issue is addressed on the following platforms:
SPARC Platform
- SPARC T3-1 with System Firmware version 8.1.0.e (as delivered in patch 147315-03) or later
- Netra T3-1 with System Firmware version 8.1.0.e (as delivered in patch 147319-03) or later
Patches
<SUNPATCH:147315-03>
<SUNPATCH:147319-03>
History
16-Sep-2011: Resolved Release
20-Feb-2013: Maintenance check for relevance/currency, no change in content.
Internal Section: Comments:
The host was being powered off, causing a FRUID write of the power-off event:
May 25 11:32:14 bur415-23-sp dynafrud: dynafru_update_power_records:105:Wrote power records to /SYS/PDB
Causing the PDB to go absent:
2011-05-25/11:32:14 ereport.component.absent@/sys/pdb /SYS/PDB/PRSNT
During a FRUID write, the SEEPROM is unavailable for several ms. ILOM has protection against this:
1. The get_i2c_present() routine has protection against this by retrying 3 times in a row.
2. The poller, getting a state-change reading, will retry to see that the state-change still exists.
These effects multiply each other, so there are a total of 6 reads done. However, they are
done without any delay in between, so it's possible that they could execute quite quickly.
So it's possible, though unlikely, that the FRUID writes (there are quite a few required) keep
the FRUID unavailable at just the exact timing that all six retries fail to access the SEEPROM.
Please send technical questions to the following email:
sunalertpublication_us_grp@oracle.com
and copy the Responsible Engineer/Contributor listed
Internal Contributor/Submitter: chuck.forgues@oracle.com
Internal Eng Responsible Engineer: cornelia.jarst@oracle.com, dencho.kojucharov@oracle.com
Internal Services Knowledge Engineer: jeff.folla@oracle.com
Internal Eng Business Unit Group: Systems Group-SVS (SPARC Volume Systems, Horizontal Systems,(includes T2000/Ontario)
Internal Escalation ID: 3-3922460401
Internal Pending Patches: None
Internal Resolution Patches: 147315-03, 147319-03
PTS Reviewer (approved by): Chuck Forgues
References
Attachments
This solution has no attachment