Sun StorEdge 3310/3320/3510/3511: Running sccli command may result in SCSI timeouts

Asset ID:	1-72-1010521.1
Update Date:	2018-04-24
Keywords:

Solution Type Problem Resolution Sure

Solution 1010521.1 : Sun StorEdge 3310/3320/3510/3511: Running sccli command may result in SCSI timeouts

Applies to:

Sun Storage 3310 Array - Version Not Applicable and later
Sun Storage 3510 FC Array - Version Not Applicable and later
Sun Storage 3511 SATA Array - Version Not Applicable and later
Sun Storage 3320 SCSI Array - Version Not Applicable and later
All Platforms

Symptoms

This phenomenon appears on systems connected with Sun Storage A1000, A3000 and A3500 arrays, as well as Sun Storage 3000 arrays (3310, 3320, 3510, 3511).

Managing Sun Storage 3000 arrays requires the sccli utility. Click here to download the sccli utility using <Patch 10310598>.

SCSI timeouts have been reported by the LUNs of Sun Storage A1000, A3000 and A3500 arrays in the following circumstances:

SCCLI is invoked on the host to manage the Sun Storage 3000 arrays.
Sun Storage A1000, A3000 and A3500 arrays are connected on the same host.
One of the following is true:

/usr/bin/osa/bin/parityck is being run for the LUNs or is being run from the GUI of Raid Manager software (rm6), which manages Sun Storage A1000, A3000 and A3500 arrays.
/usr/bin/osa/bin/parityck is being run at the same time from both hosts to the same LUNs, where the configuration includes multi-host connections.
There is a heavy I/O load on the LUNs. Note: This problem happens only if you invoke sccli without any options.

The following are examples of error messages generated when invoking SCCLI on a system where parityck is running for LUN 0:

Example 1: These messages are generated if the Sun Storage A1000, A3000 and A3500 array is connected on a SBUS system with ISP1000U host bus adapter, which uses isp HBA driver.

Apr 7 14:22:31 unix: WARNING: /sbus@1f,0/QLGC,isp@0,10000/sd@5,0 (sd5):
Apr 7 14:22:31 SCSI transport failed: reason 'timeout': retrying command
Apr 7 14:22:33 unix: WARNING: /sbus@1f,0/QLGC,isp@0,10000/sd@5,0 (sd5):
Apr 7 14:22:33 Error for Command: verify Error Level: Retryable
Apr 7 14:22:33 unix: Requested Block: 0 Error Block: 0
Apr 7 14:22:33 unix: Vendor: Symbios Serial Number: < M@k
Apr 7 14:22:33 unix: Sense Key: Unit Attention
Apr 7 14:22:33 unix: ASC: 0x29 (power on, reset, or bus reset occurred), ASCQ: 0x0, FRU: 0x0

Example 2: These messages are generated if the Sun Storage A1000, A3000 and A3500 array is connected on a PCI-based system with glm host bus adapter.

Mar 14 01:41:39 scsi: [ID 365881 kern.notice] /pci@8,700000/scsi@2 (glm2):
Mar 14 01:41:39 Cmd (0x16fda10) dump for Target 5 Lun 0:
Mar 14 01:41:39 scsi: [ID 365881 kern.notice] /pci@8,700000/scsi@2 (glm2):
Mar 14 01:41:39 cdb=[ 0x2f 0x8 0x1 0x35 0x7d 0x95 0x0 0x7f 0xff 0x0 ]
Mar 14 01:41:39 scsi: [ID 365881 kern.notice] /pci@8,700000/scsi@2 (glm2):
Mar 14 01:41:39 pkt_flags=0x4000 pkt_statistics=0x61 pkt_state=0x7
Mar 14 01:41:39 scsi: [ID 365881 kern.notice] /pci@8,700000/scsi@2 (glm2):
Mar 14 01:41:39 pkt_scbp=0x0 cmd_flags=0xe1
Mar 14 01:41:39 scsi: [ID 107833 kern.warning] WARNING: /pci@8,700000/scsi@2 (glm2):
Mar 14 01:41:39 Disconnected tagged cmd(s) (1) timeout for Target 5.0
Mar 14 01:41:39 genunix: [ID 408822 kern.info] NOTICE: glm2: fault detected in device; service still available
Mar 14 01:41:39 genunix: [ID 611667 kern.info] NOTICE: glm2: Disconnected tagged cmd(s) (1) timeout for Target 5.0
Mar 14 01:41:39 glm: [ID 401478 kern.warning] WARNING: ID[SUNWpd.glm.cmd_timeout.6018]
Mar 14 01:41:39 scsi: [ID 107833 kern.warning] WARNING: /pci@8,700000/scsi@2/sd@5,0 (sd35):
Mar 14 01:41:39 SCSI transport failed: reason 'reset': retrying command
Mar 14 01:41:39 scsi: [ID 107833 kern.warning] WARNING: /pci@8,700000/scsi@2/sd@5,0 (sd35):
Mar 14 01:41:39 SCSI transport failed: reason 'timeout': retrying command

Cause

The root cause of the problem seems to be either

When sccli is invoked without arguments, it scans all the devices in the device tree, causing the SCSI timeouts (above).

The settings Monitor_ParityTime and Monitor_ParityDay in the rmparams file on both hosts are set to the same values. Do not run multiple instances of parityck to the same storage at the same time.

Solution

The above mentioned problem does not occur if one of the following is true:

sccli is invoked out of band by specifying the IP address of the Sun Storage 3000 array.
sccli is invoked with the device path for the Sun Storage 3000 array device. For example, # sccli /dev/rdsk/c1t0d0s2

In recent versions of sccli, now delivered as part of the SUNWsscs package, the probability of this problem happening is reduced, so the user should upgrade to the most recent version to minimize the chances of being affected by this problem.

#pkginfo -l SUNWsscs
PKGINST: SUNWsscs
NAME: Sun StorEdge(tm) Configuration Service
CATEGORY: application
ARCH: sparc
VERSION: 2.4.0,REV=2007.07.04.18.18
BASEDIR: /opt
VENDOR: Sun Microsystems, Inc.
DESC: Sun StorEdge(tm) Configuration Service
PSTAMP: 2007/07/04 at 18:18
INSTDATE: Nov 11 2009 08:24
HOTLINE: Please contact your local service provider
STATUS: completely installed
FILES: 352 installed pathnames
8 shared pathnames
23 directories
21 executables
24994 blocks used (approx)

Previously Published As
75533

Attachments

This solution has no attachment