BIOS has certain execution phases, namely checkpoints, defined and reported throughout it's execution life
These checkpoints are both written out onto on a specific port (80,81), and reported at the bottom of POST screen if possible, via LCD display or SP (sp get port80 vX0z) progress is also available through sundiag - current-port80 on the Galaxy SP
Ipmitool is a utility for interfacing with devices that support the Intelligent Platform Management Interface specification. IPMI is an open standard for machine health, inventory, and remote power control.
Ipmitool can communicate with IPMI-enabled devices through either a kernel driver such as OpenIPMI or over the RMCP (Remote Management Control Protocol) LAN protocol defined in the IPMI specification.
IPMIv2 adds support for encrypted LAN communications and remote Serial-over-LAN functionality.
Ipmitool is found in /usr/sfw/bin on Solaris operating systems.
Ipmitool has to be installed as an option on Linux and Windows.
IPMI v2.0 Architecture Baseboard System Bus Bridge Controller ICMB Aux. IPMB Remote Mgmt. Card SMBus/PCI Mgmt. Bus Baseboard Mgmt. Controller (BMC) I 2 C/SMBus SDR, SEL, FRU NV Store Mgmt Netwk Ctrlr LAN PCI RS-232 MODEM / Serial IPMB (I 2 C) Chassis FRU SEEPROM System Interface SENSORs & control circuitry I 2 C / SMBus sensors & control circuitry Satellite Mgmt. Controller In Band Out of Band “ side-band” IPMI Messages
An alternative to this is to use the provided shell interface to issue repeated commands that will all use the same automatically generated cache. The shell interface is not available with all platforms and sometimes it is more advantageous to use the cache method (SDR), but if you are going to be analyzing the SEL chances are you will want to issue multiple commands and the shell interface makes this much easier with command history and editing.
300 | Pre-Init Time-stamp | Power Supply ps0.vinok | State Asserted
NOTE: In order to improve readability and avoid repeating useless command line arguments all further examples will assume that the shell interface is being used and that an appropriate session is already established either over LAN interface or using KCS interface and an OS kernel driver.
Note the updates in firmware to include the term (PAIR) to aid misconception in FRU part.
The BIOS is responsible for DIMM ECC handling. When a CE/UE error occurs, the chipset will generate a SMI, the BIOS will detect it and send a SEL event to the BMC. The IPMI spec. defines the format of SEL for DIMM ECC events. In addition, since the UE may cause the system hang or reset, the BIOS checks the UE status bit during early post stage and fires a SEL event to BMC as appropriate.
Make sure the system is running the latest firmware. Earlier firmware reported as follows:
An important foundation for sensors and events and FRUs is the concept of entities. In IPMI every sensor is assigned an entity ID and instance, which at its most basic level is a classification system that helps define what device type and number a sensor monitors. These are closely related to the concept of a Field Replaceable Unit in that a particular entity ID and instance can be used to describe a FRU.
An entity ID is mapped to a physical device through a table defined in the IPMI specification. For our purposes the following entities are used on the Sun Fire X4000 platform:
Their primary usefulness is for grouping and querying sensors, and in fact they come in very handy with ipmitool to do specific sensor queries.
Entities can also be used for entity lookups whereby you can associate a sensor with other sensors by finding all other sensors with the same entity ID and instance as the one you are looking up. This allows you to associate a sensor (and event).
Threshold (or analog) sensors are used for inputs like temperature, voltages, and fan speeds. These are connected to a sensor chip and read by the service processor using I2C. They can have both upper and lower thresholds set and multiple different events can be configured around each of them.
There can be zero or more of the following thresholds configured as upper or lower bounds for each threshold sensor:
* Non-Critical * Critical * Non-Recoverable
These are commonly represented in short form with ipmitool, here is how the short names map to the longer names
Each threshold can also have both a direction and a status flag attached to it. The use of a "+" or "-" is used to indicate whether that particular threshold applies to a reading that is going high or going low, respectively. The status flag indicates whether the event is generated is an assertion or a deassertion event. Each of these can be configured independently by setting various bits in the sensor data record.
While threshold sensors represent analog readings, discrete sensors can be considered to represent digital readings. There are different types of discrete sensors as well:
Generic Discrete: these sensors can have various flags from a generic pre-defined table. None of these sensors are used on this platform.
Digital Discrete: similar to the above but are for sensors that only represent one of two possible states. Think of a GPIO pin where the state is either 1 or 0. There are many sensors of this type used on this platform, everything from presence detection sensors to LED state sensors.
Sensor-Specific Discrete: similar to the first type these sensor types have any number of flags defined depending on the sensor type. This makes it possible to represent a large number of sensors, each with different states. There is only one of these types of sensor on this platform and it belongs to the Chassis Intrusion sensor.
The PFE version of MPS_REPORTS gathers a wide range of diagnostic information from Windows and limited information for server applications installed such as SQL or Exchange.
The user running the utility must have administrative privileges on the system.
During runtime there are uncompressed text files that could possibly consume 100 MB or more or more of disk space, depending on the size of the event logs. Most of the space is freed when the reporting tool finishes, leaving behind only the tools folder and the .cab file, which can be deleted if no longer needed.
The Microsoft Product Support Reporting Tool facilitates the gathering of critical system and logging information used in troubleshooting support issues. The reporting tool DOES NOT make any registry changes or modifications to the operating system.
Files created are zipped CAB files cabextract can
be used on Solaris to extract.
Microsoft Product Support Reporting Tool
Cabextract website for Solaris and other packages.
The tools gather 90% of the debug data frequently requested by the Sun Technical Support Center - including data for more common critical situations including memory, start/stop, installation, hang, and crash issues. By collecting this data before you initiate a Service Request, you can substantially reduce the time needed to analyze and resolve the problem.
Sun Java System Calendar Server
Sun Java System Directory Editor
Sun Java System Directory Proxy Server
Sun Java System Directory Server
Sun Java System Messaging Server
Sun Java System Portal Server
Sun Java System Web Proxy Server 3.6 Service Pack 9
Sun Java System Web Server
External GDD sun website
Sun Gathering Debug Data (GDD) (WZT-0253) - Web based
Detailed system information and logs are collected and organized in a manner that helps reduce service request resolution times. Private system information can be disclosed when using this tool. If this is a concern, please prune private data from the log files. Several startup options are available to exclude more sensitive information. Refer to the man page to see these options.
Output format is better the SIGA scripts, however needs to be installed from the SUSE web site.