Fujitsu M10 Product Notes page 145

Table 3-17 Problems resolved in XCP 2070 (continued)
SPARC M10-
RTI No. 1 4 4S
RTIF2- x x x
130802-002
RTIF2- x
130826-001
RTIF2- x
130902-001
RTIF2- x
130903-002
Description
When Oracle Solaris is operating, if you
change the SNMP setting with the
setsnmp(8) command, the following
phenomena may occur.
1. A part of the data such as the XCP
version number is not output as a
result of the prtpicl -v and prtdiag -v
commands.
2. For /var/adm/messages of Oracle
Solaris, the following warning
message is output.
PICL snmpplugin: cannot fetch object
value
If you log in to the XSCF Web from the
master XSCF when the standby XSCF is
in either the maintenance or input power
off state, a dialog starting with "Cannot
communicate with BB#xxx: ..." that
indicates a non-breaking communication
error is output.
If the firmware is updated while a logical
domain is operating in a system
consisting of multiple SPARC M10-4S
units, the master XSCF may not switch to
a standby XSCF, causing the firmware
update to fail.
In a system consisting of multiple SPARC
M10-4S units, it may take longer than
usual from the time a physical partition
(PPAR) is turned on until the Power-On
Self test (POST) starts.
For example, for a 2BB configuration,
POST usually starts after about 10
minutes, but it may take 20 minutes or
longer.
Workaround
There is no effective workaround.
- If 1. occurs:
Perform recovery by using the
following procedure.
1) End the prtdiag command with [Ctrl]
+ [C].
2) Wait for about 30 minutes, and let an
SNMP timeout occur in the XSCF.
3) On the logical domain, execute the
svcadm command to restart the picl
service.
- If 2. occurs:
The system can be operated
continuously because this is a
temporary warning message.
There is no effective workaround.
The message in the dialog indicates a
display defect, so you can operate the
system as is. Ignore the dialog related to
this communication error.
There is no effective workaround.
Recover the system by following the
procedure described below.
1. Log in to either standby XSCF, and
then execute the following command.
XSCF> rebootxscf -s
2. After 10 seconds, log in to the other
standby XSCF, and then execute the
following command.
XSCF> rebootxscf -a
3. Wait for 20 minutes, log in to the
master XSCF, and then execute the
flashupdate(8) command again.
There is no effective workaround.
If this defect occurs, execute the
rebootxscf -a command to reset all the
XSCFs and restore the system.
Chapter 3 Information on Software 131