| Document Audience: | INTERNAL |
| Document ID: | A0209-1 |
| Title: | Sun Fire 15K & Sun Fire 12K with Crystal+ cards may experience panics in the pcisch driver. |
| Copyright Notice: | Copyright © 2007 Sun Microsystems, Inc. All Rights Reserved |
| Update Date: | Fri Jun 13 00:00:00 MDT 2003 |
----------------------------------------------------------------------------
- Sun Proprietary/Confidential: Internal Use Only -
----------------------------------------------------------------------------
FIELD CHANGE ORDER
(For Authorized Distribution by Enterprise Services)
FCO #: A0209-1
Status: inactive
Synopsis: Sun Fire 15K & Sun Fire 12K with Crystal+ cards may experience panics in the pcisch driver.Date: Jun/13/2003
SunAlert: No
Top FIN/FCO Report: No
Products Reference: Sun Fire 15K/12K
Product Category: Server / System Component
Product Affected:
Mkt_ID Platform Model Description Serial Number
------ -------- ----- ----------- -------------
- F15K - Sun Fire 15K -
- F12K - Sun Fire 12K -
X-Options Affected
Mkt_ID Platform Model Description Serial Number
------ -------- ----- ----------- -------------
X6727A F15K/F12K - PCI Dual FC Network Adapter+ -
Parts Affected:
Part Number Description Model
----------- ----------- -----
375-3030-xx PCI Dual FC Network Adapter+ -
(SCSI Devices)
Type Vendor Model SerialNumber(Min) SerialNumber(Max) Firmware
---- ------ ------- ----------------- ----------------- --------
N/A
References:
ESC: 537306
FIN: IO852-1
BugID: 4699182
Issue Description:
Sun Fire 15K and Sun Fire 12K systems with PCI Dual FC Network Adapter+
(Crystal+) used in the 66MHz slots may experience pcisch driver panics
due to a parity error on the PCI Bus.
Panics in the pcisch driver cover a wide range of possible failures.
In this case, the control status register (CSR) calls out the detection
of bad parity on the PCI bus:
WARNING: pcisch-19: PCI fault log start:
PCI SERR
PCI error occurred on device #0
dwordmask=0 bytemask=0
pcisch-19: PCI primary error (0):pcisch-19: PCI secondary error (0):pcisch-19:
PBM AFAR 0.00000000:WARNING: pcisch19: PCI config space
CSR=0xc2a0
pcisch-19: PCI fault log end.
panic[cpu128]/thread=2a10001fd20: pcisch-19: PCI bus 3 error(s)!
000002a10001bea0 pcisch:pbm_error_intr+148 (30000b643d8, 2772, 30000b84548, 3,
30000b643d8, 3)
%l0-3: 00000300008b9860 0000000000004000 0000000000000000 0000030000b86584
%l4-7: 00000300009978c8 0000030008d03ea8 0000000000000000 0000030008d03ed0
000002a10001bf50 unix:current_thread+44 (0, ffffffffffffffff, 0, 300335b3528,
0, 1044f340)
%l0-3: 0000000010007450 000002a10001f061 000000000000000e 0000000000000016
%l4-7: 0000000000010000 00000300339922a8 000000000000000b 000002a10001f910
000002a10001f9b0 unix:disp_getwork+40 (1044e398, 0, 1044f340, 10457310, 2, 0)
%l0-3: 000000001010e2d8 0000000010509e00 00000300335bd518 000002a100c37d20
%l4-7: 000002a100cebd20 0000000002736110 0000000000000000 000002a10001f9c0
000002a10001fa60 unix:idle+a4 (0, 0, 80, 1044e398, 3000096d980, 0)
%l0-3: 0000000010043d58 2030205b275d2076 616c20696e646578 000002a10011dd20
%l4-7: 70636220290a2020 202e22202073703a 20222031205b275d 2076616c20696e64
NOTE: The stack itself can be different, depending on each specific case. What
matters is the CSR values (specifically the "detected-parity-error" bit).
Although this type of panic can result from a hardware issue on any adapter,
this FCO is only addressing those with a PCI Dual FC Network Adapter+. In
addition, this FCO is only legitimate for failures in the 66Mhz slots (bottom
slots of an hsPCI assembly).
With every other panic of this nature, a hardware replacement has resolved
the case. However, with one customer, repeated hardware replacements did not
resolve the issue. The customer's issue has since been replicated on multiple
machines in an engineering environment. There are some unique factors that
are needed to create this scenario:
A. To date, this problem has only been seen on 375-3030 (Crystal+)
cards.
B. All the panics have been in either slot 0 or slot 2 of the I/O Boat.
(Slots 0 and 2 is the lower 66 MHz slots)
C. Schizo 2.3 seems to bring the problem out with more regularity.
D. Veritas software (specifically adding mirrors to volumes) seems
to increase the likelihood of failure.
Please review the Steps for Diagnosis in the Special Considersations
section below before implementing any corrective action.Parts Affected:
N/A
Implementation:
---
| | MANDATORY (Fully Pro-Active)
---
---
| | CONTROLLED PRO-ACTIVE (per Sun Geo Plan)
---
---
| X | UPON FAILURE
---
Replacement Time Estimate:
4.0 hours
Special Considerations:
Steps for Diagnosis
===================
1) Isolate the offending PCI bus:
As a reminder, when looking at a starcat I/O boat, the slots
are designated:
|--------------------------|--------------------------|
| Schizo 1, leaf B (33Mhz) | Schizo 0, leaf B (33Mhz) |
|--------------------------|--------------------------|
| Schizo 1, leaf A (66Mhz) | Schizo 0, leaf A (66Mhz) |
|--------------------------|--------------------------|
OR
|--------|--------|
| Slot 3 | Slot 1 |
| OR | OR |
| X.1.1.1| X.1.0.1|
|--------|--------|
| Slot 2 | Slot 0 |
| OR | OR |
| X.1.1.0| X.1.0.0|
|--------|--------|
NOTE: X = hsPCI number (0-17)
To diagnose the pcisch panic from the above stack, follow these steps:
Use the /etc/path_to_inst on the domain or the cfgadm/rcfgadm commands
to isolate the slot. For example, using the two methods with the panic
above (pcisch-19):
# grep pcisch /etc/path_to_inst
"/pci@3d,600000" 7 "pcisch"
"/pci@1c,700000" 0 "pcisch"
"/pci@3c,700000" 4 "pcisch"
--> "/pci@9d,600000" 19 "pcisch"
"/pci@9c,600000" 17 "pcisch"
"/pci@3c,600000" 5 "pcisch"
"/pci@5d,600000" 11 "pcisch"
"/pci@7d,600000" 15 "pcisch"
In this case, instance 19 is "/pci@9d,600000". To
translate that into a slot location, break down the 9d into
binary <10011101>, then add spaces to obtain <100 1110 1>.
That address now breaks down to slot 4 (100), skip the
middle section (1110), pci 1 (or the pci slot on the
left).
The other option is to leverage the conversion the dynamic
reconfiguration interface provides:
# rcfgadm -d a -la | grep pcisch
pcisch0:e00b1slot1 pci-pci/hp connected configured ok
pcisch10:e02b1slot3 unknown connected unconfigured unknown
pcisch11:e02b1slot2 pci-pci/hp connected configured ok
pcisch12:e03b1slot1 pci-pci/hp connected configured ok
pcisch13:e03b1slot0 pci-pci/hp connected configured ok
pcisch14:e03b1slot3 unknown connected unconfigured unknown
pcisch15:e03b1slot2 pci-pci/hp connected configured ok
pcisch16:e04b1slot1 unknown connected unconfigured unknown
pcisch17:e04b1slot0 pci-pci/hp connected configured ok
pcisch18:e04b1slot3 unknown connected unconfigured unknown
--> pcisch19:e04b1slot2 unknown empty unconfigured unknown
pcisch1:e00b1slot0 unknown empty unconfigured unknown
pcisch20:e08b1slot1 unknown empty unconfigured unknown
pcisch21:e08b1slot0 pci-pci/hp connected configured ok
pcisch22:e08b1slot3 unknown empty unconfigured unknown
pcisch23:e08b1slot2 unknown empty unconfigured unknown
pcisch2:e00b1slot3 unknown connected unconfigured unknown
pcisch3:e00b1slot2 pci-pci/hp connected configured ok
pcisch4:e01b1slot1 pci-pci/hp connected configured ok
pcisch5:e01b1slot0 unknown empty unconfigured unknown
pcisch6:e01b1slot3 unknown connected unconfigured unknown
pcisch7:e01b1slot2 pci-pci/hp connected configured ok
pcisch8:e02b1slot1 pci-pci/hp connected configured ok
pcisch9:e02b1slot0 unknown connected unconfigured unknown
In this case, the issue is on expander 4 (ex4), I/0 board
(b1), slot 2.
b) Once the offending FRU has been identified, follow FIN IO852-1
and replace the hsPCI and the cassette called out in the panic.
Once completed, replace ALL x6272A's within the domain with
x6768A (Crystal2A), including x6727A that have not generated
panics.
So, for the example above, we would replace the hsPCI in
slot 4, the cassette in slot 2 (lower left), the x6727A
with a x6768A and all other x6727A's in this domain.
It is expected that some customers may wish to take the
down time and replace all x6727A's in their entire platform
where applicable. This action has been approved under this
FCO.
EXCEPTION: If customer attached A3500FC (540-4026 or 540-4027)
to F12/15K via Crystal+, then x6799A (Amber) must be used in
place of x6768A (Crystal 2A).
c) There are some hardware prerequisites you might have to
contend with:
- The cables used for the x6768A differ from the cables
used for the x6727A. Before performing this FCO,
verify and replace all required cables or use LC ->
SC adapters.
replace 537-1004 2 Meter SC-SC with 537-1035 2 Meter LC-SC
replace 537-1020 5 Meter SC-SC with 537-1033 5 Meter LC-SC
replace 537-1004 15 Meter SC-SC with 537-1034 15 Meter LC-SC
If a custom length SC-SC cable is in use, order 0.4 Meter LC-SC
cable 537-1036 and SC-SC Female to Female coupler 130-4723.
d) There are some software prerequisites you might have to
contend with:
- Slot 1 DR will be available with SMS1.3. The current
target date (always subject to change) for SMS1.3 is
sometime near the end of Janurary 2003. Until then,
the system will have to incur a downtime for
replacement.
- If the boot device is on the to-be-replaced hsPCI, it will be
necessary to have planned the system configuration to
allow a boot-device DR (i.e. multipathing/mirroring,
etc). If you do not have such a capability, the
domain will have to incur a downtime for
replacement.
- Once the x6727A has been replaced with a x6768A, the
controller number for the disk will change unless you
follow the procedure below.
- The customer will need to download the drivers for the x6768A.
Reference the procedure below. NOTE: DO NOT FORGET
TO UPDATE/PATCH THE JUMPSTART IMAGE, IF APPLICABLE.
At the time of authoring this FCO, the driver
required according to:
Sun StorEdge 2G FC PCI Dual Channel Network Adapter
Product Notes (Part Number: Part No.816-5002-11
June 2002, Revision A)
Before installing the Sun StorEdge 2G FC PCI Dual
Channel Network Adapter card, the host must have
both the Solaris 8 update 4 operating environment
release with the recommended patch cluster and the
Sun StorEdge 2G FC PCI Dual Channel Network Adapter
driver.
Check http://www.sun.com/download/ or
http://www.sun.com/storage/ san for updates. There
is one set of packages for the Solaris 8 operating
environment and another for the Solaris 9 operating
environment available under the respective links
for the operating environments. The SUNWsan package
is interchangeable between the releases.
Packages:
SUNWsan
SUNWcfpl
SUNWcfplx
Available at: http://www.sun.com/download/ or
http://www.sun.com/storage/san
Patches (NOTE: patches might be uprev'ed. These
are the minimum requirements):
Solaris 8 Solaris 9
--------- ---------
Sun StorEdge Traffic Manager patch 111412-09 113039-01
fctl/fp/fcp/usoc driver 111095-10 113040-01
fcip driver 111096-04 113041-01
qlc driver 111097-10 113042-02
luxadm/liba5k and libg_fc patch 111413-08 113043-01
cfgadm fp plug-in library patch 111846-04 113044-01
SAN Foundation Kit patch 111847-04 111847-04
Available at: sunsolve.sun.com
- There is a known issue with replacing an crystal with
an encapsulated boot device.
If not donce correctly, device major number will be
incorrectly set forcing panics. Please reference the
procedure below and specifcally the name_to_major
file references.
- Replacement Procedure:
Replace Crystal+ cards with Crystal2A on a F15K/12K
==================================================================
I. Prerequisites
- Crystal2A drivers, patches and packages.
[ refer to Sun StorEdge 2G FC PCI Dual Channel
Network Adapter Product Notes ]
- Solaris 8 2/02 with current recommended patch
cluster and san patches.
- Dedicated Solaris 8 2/02 network boot/jumpstart image with
Crystal2A drivers, packages and patches.
- A good backup of all filesystems.
==================================================================
II. Preparation
1. If you are replacing a controller that contains the
boot device or a Veritas Volume Manager device in
rootdg, you will have to create a boot server image
that contains the Crystal2A drivers. Otherwise you may
skip this step.
To do this, first create a Solaris 8 02/02
JumpStart Boot server. Then, install the Crystal2A
drivers, patches and packages into this image and
copy the /etc/name_to_major file from the domain
onto the boot image. (This will prevent problems
with differing major numbers between the domain and
the boot image).
Example using a Solaris 8 02/02 boot server image located at
/jumpstart/5.8_HW202:
For Packages:
=============
cd [ location of packages ]
pkgadd -R /jumpstart/5.8_HW202/Solaris_8/Tools/Boot -d .
For Patches:
============
cd [ location of patches ]
patchadd -C /jumpstart/5.8_HW202/Solaris_8/Tools/Boot
./[patchid]
For /etc/name_to_major:
=======================
cd /jumpstart/5.8_HW202/Solaris_8/Tools/Boot/etc
cp name_to_major name_to_major.orig
ftp domain
ftp> cd /etc
ftp> get name_to_major
2. Bring the domain down to single user mode
OK> boot -s
3. Install patches and packages on the domain.
Follow normal patchadd and pkgadd procedures.
4. Verify the controller number[s] for the card being replaced
# format
# ls -l /dev/dsk
# ls -l /dev/ses
( You may want to save this output for reference. )
==================================================================
III. Replacing a controller NOT used for the boot device.
(This example uses c1 as the controller to be changed.)
1. If Volume Manager is being used, disable it from starting.
# touch /etc/vx/reconfig.d/state.d/install-db
2. Reboot domain into single user mode
# init 0
OK> boot -s
Volume manager should not be running at this point.
# ps -ef | grep vx (this should show no volume manager
processes)
3. Remove the devices associated with the controller to be
replaced.
# cd /dev/dsk
# rm c1*
# cd /dev/rdsk
# rm c1*
# cd /dev/cfg
# rm c1 [ this entry may or may not exist ]
# cd /a/dev/ses ( if applicable )
# rm ses2 ses3 ( for the ses devices associated with c1 )
4. Shutdown and replace the cards. Make sure auto-boot? is
false.
# init 0
OK> setenv auto-boot? false
Shut off the domain from the SC
setkeyswitch -d [domainid] off
Replace the card, turn on the domain.
setkeyswitch -d [domainid] on
Verify that the new controller is available from OBP.
OK> probe-scsi-all
Do a single user reconfiguration boot
OK> boot -sr
5. Verify that the devices were created as expected:
# format
# ls -l /dev/dsk/c1* /dev/rdsk/c1*
# ls -lL /dev/dsk/c1* /dev/rdsk/c1*
# ls -l /dev/es
If Veritas Volume Manager was NOT used, check that the
devices can be mounted. If all looks good continue to
multiuser.
# mountall
6. If Veritas was disabled previously (Step 1), re-enable it and
reboot.
# rm /etc/vx/reconfig.d/state.d/install-db
# init 6
Verify that veritas started correctly and all volumes are
available.
==================================================================
IV. Replacing a controller that IS used for the boot device.
(This example uses c0 as the controller to be changed.)
1. If the boot disk is encapsulated, you must first
unencapsulate the boot device.
Reboot and verify that the boot disk has been successfully
unencapsulated.
2. If Volume Manager is being used, disable it from starting.
# touch /etc/vx/reconfig.d/state.d/install-db
3. Reboot domain into single user mode
# init 0
OK> boot -s
Volume manager should not be running at this point.
# ps -ef | grep vx (this should show no volume manager
processes)
4. Shutdown and replace the cards. Make sure auto-boot? is
false.
# init 0
OK> setenv auto-boot? false
Shut off the domain from the SC
setkeyswitch -d [domainid] off
Replace the card, turn on the domain.
setkeyswitch -d [domainid] on
Verify that the new controller is availble from OBP.
OK> probe-scsi-all
5. Boot from the Crystal-2A enabled JumpStart Boot server (as
described under preparation. Verify that the
devices are visible.
OK> boot net -s (from Crystal-2a patched jumpstart)
# format
6. Mount the boot device's / partition at /a. Remove the
previous controller's device nodes.
# mount /dev/dsk/ /a
# rm /a/dev/dsk/c0* /a/dev/rdsk/c0*
# rm /a/dev/cfg/c0 (this may or may not exist)
# rm /a/dev/es/ses0 /a/dev/es/ses1
( for the ses devices associated with c0 )
7. Build and verify the new device nodes and reset-all.
# devfsadm -r /a -p /a/etc/path_to_inst
# ls -l /a/dev/dsk/c0* /a/dev/rdsk/c0*
# ls -l /a/dev/dsk/c0* /a/dev/rdsk/c0*
# ls -l /a/dev/es
# umount /a
# halt
OK> reset-all
8. Determine the new boot device path.
The device path WILL change the Crystal2A has a different FW prom.
For example, original boot device:
/pci@3d,600000/pci@1/SUNW,qlc@4/fp@0,0/disk@w220000203733433b,0:a
New boot device:
/pci@3d,600000/SUNW,qlc@1/fp@0,0/disk@w220000203733433b,0:a
OK> show-disks (check for new card's device)
OK> probe-scsi-all (check that disk are visible)
Verify the new path of the boot device and use nvunalias and
nvalias to record it.
OK> nvunalias [old-boot-device-alias]
OK> nvalias [device-alias] [device-path]
OK> setenv boot-device [device-alias]
OK> setenv diag-device [device-alias] (if desired)
9. Boot off the new path into single user mode. Verify that the
devices were created as expected
ok> boot -s
# format
If Veritas Volume Manager was NOT used, check that the
devices can be mounted. If all looks good continue
to multiuser.
# mountall
10. If Veritas was disabled previously (Step 1), re-enable it
and reboot.
# rm /etc/vx/reconfig.d/state.d/install-db
# init 6
Verify that Veritas started correctly and all volumes are
available.Corrective Action:
Important! Troubleshoot pcisch driver panics as outlined above and
in FIN I0852-1 and follow instructions outlined in the
Special Considerations section.
A. Replace all 375-3030-xx (Crystal+) cards with 375-3108-xx
(Crystal-2A) cards in the affected domain.
OR
B. If customer attached A3500FC (540-4026 or 540-4027) to F12/15K
via Crystal+, replace all 375-3030-xx (Crystal+) cards with
375-3019-xx (Amber) cards in the affected domain.
Either action will require new drivers to be installed and LC-SC
or LC-LC Fibre Cables. See Product Note 816-5002 for details:
http://infoserver.central/data/816/816-5002/pdf/816-5002-11.pdfComments:
Billing Type:
Warranty: Sun will provide parts at no charge under Warranty
Service. On-Site Labor Rates are based on how the
system was initially installed.
Contract: Sun will provide parts at no charge. On-Site Labor Rates
are based on the type of service contract.
Non Contract: Sun will provide parts at no charge. Installation by
Sun is available based on the On-Site Labor Rates
defined in the Price List.
--------------------------------------------------------------------------Implementation Footnote:
________________________
i) In case of Mandatory FCOs, Sun Services will attempt to contact
all known customers to recommend the part upgrade.
ii) For controlled proactive swap FCOs, Sun Services mission critical
support teams will initiate proactive swap efforts for their respective
accounts, as required.
iii) For Replace upon Failure FCOs, Sun Services partners will implement
the necessary corrective actions as and when they are required.
--------------------------------------------------------------------------
All released FINs and FCOs can be accessed using your favorite network
browser as follows:
SunWeb Access:
______________
* Access the top level URL of http://sdpsweb.Central/FIN_FCO/
* From there, select the appropriate link to query or browse the FIN and
FCO Homepage collections.
SunSolve Online Access:
_______________________
* Access the SunSolve Online URL at http://sunsolve.Central/
* From there, select the appropriate link to browse the FIN or FCO index.
Internet Access:
_______________
* Access the top level URL of https://spe.sun.com
--------------------------------------------------------------------------
General:
________
Send questions or comments to [email protected]
---------------------------------------------------------------------------