Sun StorEdge 3510 FC Array and Sun StorEdge 3511 SATA Array Release Notes

These release notes provide late-breaking information about the Sun StorEdge 3510 FC array and for the Sun StorEdge 3511 SATA array.

These products both use Fibre Channel ports and technology but have important differences in their drive technology and purpose. Be sure to review How Sun StorEdge 3511 SATA Arrays Differ From Sun StorEdge 3510 FC Arrays.

---

What's New in This Release

This release enhances the initial release of the Sun StorEdge 3511 SATA array:

• TheCommand-Line Interface (CLI) 1.6.2 software fixes bugs, enhances SATA support, and can be used with all Sun StorEdge 3000 family arrays. For a listing of fixed bugs, refer to Fixed Software Bugs. Refer to the Sun StorEdge 3000 Family CLI 1.6 User's Guide for detailed information about commands and options.
• The revised Sun StorEdge 3000 Family Best Practices for the Sun StorEdge 3510 FC array and for the Sun StorEdge 3511 SATA array (816-7325-16) is now posted on the product websites and provides reorganized content and improved configuration information.
• Firmware patch 113724-01 for the Sun StorEdge 3511 SATA array offers new SES firmware version 0412.
• Updated translated manuals are now available on all 3000 Family product web sites. Updated translated software packages are available on the Sun Download Center.

---

How Sun StorEdge 3511 SATA Arrays Differ From Sun StorEdge 3510 FC Arrays

Sun StorEdge 3511 SATA arrays use Serial ATA (SATA) disk technology, and are recommended for cost-sensitive archival, static storage, and backup applications. Primary applications where the Sun StorEdge 3511 SATA array might be used rather than the Sun StorEdge 3510 FC array include:

• Applications requiring streaming or sequentially accessed data or those with cost-sensitive duty cycles such as backup and archival storage are best served by the Serial ATA-disk solution of the Sun StorEdge 3511 SATA array.

The StorEdge 3511 SATA array is designed for applications requiring lower-cost bulk storage (not a trait of FC disk-based solutions), where application or data availability is not a primary concern.

The StorEdge 3511 SATA array should be used only for archival, backup, or static storage; do not use it to store single instances of data. Do not use it as a boot device.

The Sun StorEdge 3511 SATA array can be used in multi-path and multi-host configurations where the array has a backup or archival role.

• Applications demanding transaction-based random access patterns with high duty cycles are best suited to a Fibre Channel disk-based solution such as the Sun StorEdge 3510 FC array. The Sun StorEdge 3510 FC array is designed for business-critical applications and their high-value data. These critical applications require higher availability (not a trait of SATA-disk based solutions).
• Sun StorEdge 3511 SATA expansion units can be connected to Sun StorEdge 3510 FC arrays, either alone or in combination with Sun StorEdge 3510 FC expansion units. Up to five expansion units can be used in this configuration.

Before installing and configuring your array, please review the key differences between the Sun StorEdge 3510 FC array and the Sun StorEdge 3511 SATA array in the following table.

For additional configuration information, refer to the Sun StorEdge 3000 Family Best Practices Manual for your array. For other detailed information on these products, see Release Documentation.

---

Sun StorEdge 3511 SATA Array Limitations

This section describes limitations of the Sun StorEdge 3510 FC and 3511 SATA array as well as limitations in the supporting software.

Hardware Limitations for Sun StorEdge 3511 SATA Arrays

• The Sun StorEdge 3511 SATA array uses Serial ATA drives that provide larger storage capacity than Fibre Channel arrays but slower performance. Heavy I/O can impact performance still further, possibly introducing timeouts.
• With no I/O being processed, rebuilding a 2-TB RAID 5 logical drive can take up to 6.5 hours with the firmware's Rebuild Priority set to Low (the default). This setting uses the controller's minimum resources to rebuild and takes longer than other Rebuild Priority settings.
• Unlike Sun StorEdge 3510 FC products, at the time of this release no Sun StorEdge 3511 SATA JBOD can be directly attached to a host computer. Sun StorEdge 3511 SATA expansion units can be connected to Sun StorEdge 3511 SATA arrays.

Firmware Limitations for Sun StorEdge 3511 SATA Arrays

• For Sun StorEdge 3511 RAID arrays and expansion units, the SATA MUX chip does not support SMART monitoring of SATA drives. Therefore, the following RAID firmware's "Configuration Parameters" menu options are not supported for Sun StorEdge 3511 SATA arrays:
• "Drive-side SCSI Parameters Drive Predictable Failure Mode (SMART) - Detect Only"
• "Drive-side SCSI Parameters Drive Predictable Failure Mode (SMART) - Detect and Clone+Replace"

• Sequential optimization must be used. Do not use random optimization with Sun StorEdge 3511 arrays or expansion units.

Sun StorEdge Configuration Service Limitations for Sun StorEdge 3511 SATA Arrays

In this release, Sun StorEdge Configuration Service cannot be used to download SATA router firmware or SATA MUX firmware.

---

Release Documentation

These release notes supplement the documents shown in the following table.

You can download the documents listed in the preceding table (except EOL items) from either of the following locations:

http://www.sun.com/products-n-solutions/hardware/docs/Network_Storage_Solutions/Workgroup/3510

http://www.sun.com/products-n-solutions/hardware/docs/Network_Storage_Solutions/Workgroup/3511

http://docs.sun.com/db/coll/3510FCarray

http://docs.sun.com/db/coll/3511FCarray

---

Sun StorEdge 3000 Family EOL Items

For obsolete documentation for the Sun StorEdge 3000 Family products, refer to:

http://www.sun.com/products-n-solutions/hardware/docs/Network_Storage_Solutions/EOL_Products/index.html

The item now available in this location is:

Sun StorEdge 3000 Family Rack Installation Guide for 2U Arrays (816-7320) which covers older rackmount kits

---

Service Contact Information

If you need help installing or using this product, call 1-800-USA-4SUN, or go to:

http://www.sun.com/service/contacting

---

System Requirements

The software and hardware identified in the following list have been tested and proven to work with the Sun StorEdge 3510 FC array and Sun StorEdge 3511 SATA array.

• Supported Operating Systems and Management Software
• Other Supported Software
• Supported Platforms and Connection Methods
• Supported FC Switches
• Supported Disk Drives
• Supported Cabinets
• Supported Cables for Sun Systems

Supported Operating Systems and Management Software

The following table lists the operating environments and operating systems supported for hosts connected to Sun StorEdge 3510 FC arrays and Sun StorEdge 3511 SATA arrays.

The following table lists the software components of the Sun StorEdge 3000 Family Professional Storage Manager software for Sun StorEdge 3000 Family SCSI, FC, and SATA arrays. See Downloading Updated Sun StorEdge 3000 Family Software for information about how to obtain this software.

Other Supported Software

The following table lists backup, clustering, diagnostic, and other supported software.

Supported Platforms and Connection Methods

TABLE 6, TABLE 7 and TABLE 8 list the Sun systems that are supported by the Sun StorEdge 3510 FC array and Sun StorEdge 3511 SATA array. The table also shows the connection methods supported for each of the supported Sun systems.

Support for Solaris 2.6 is now available. Use the following HBAs and the native Qlogic drivers. You must download and use the Qlogic Solaris SPARC driver package 4.13.01 or later. See the following Qlogic website for more details:

http://www.qlogic.com/support/oem_detail_all.asp?oemid=124

TABLE 10 lists information and connection methods supported for the Windows, Linux, Novell NetWare, HP-UX and IBM AIX operating systems.

Supported FC Switches

The following table lists the FC switches that are supported by the Sun StorEdge 3510 FC array and Sun StorEdge 3511 SATA array.

Supported Disk Drives

The following tables lists the disk drives that are supported by the Sun StorEdge 3510 FC array and Sun StorEdge 3511 SATA array.

Supported Cabinets

The following table shows the supported cabinets with their associated rackmount kits and other required kits. See the Sun StorEdge 3000 Family Rack Installation Guide for 2U Arrays for installation instructions.

Supported Cables for Sun Systems

The following table lists the supported Fibre Channel cables for connecting to the host adapters that are supported for Sun systems. You can order cables using the marketing part numbers in this table.

---

Bootability

Booting from the Sun StorEdge 3510 FC array is supported and requires no special procedures, as long as the appropriate Solaris patches and SAN Foundation Suite software components are installed, as described in TABLE 3.

Do not use the Sun StorEdge 3510 FC and 3511 SATA array as a boot device. Use the Sun StorEdge 3510 FC array instead.

---

Software Support for Sun StorEdge 3510 FC JBODs

Sun StorEdge Configuration Service software supports Sun StorEdge 3510 FC JBOD arrays (arrays without controllers which are directly attached to servers). However, since Sun StorEdge 3510 FC JBOD arrays do not have a RAID controller to manage the disks, this software support is necessarily limited. Monitoring functionality that does not require a RAID controller works properly.

The Sun StorEdge CLI supports Sun StorEdge 3510 FC JBOD arrays. However, since Sun StorEdge 3510 FC JBOD arrays do not have a RAID controller to manage the disks, this CLI support is limited to the following sccli commands:

• about
• download pld-firmware
• download ses-firmware
• exit
• help
• quit
• select
• show frus
• show ses-devices
• version

To obtain information on each command, refer to the Sun StorEdge 3000 Family CLI User's Guide.

---

Installing Required Solaris Patches

Make sure the Solaris Recommended Patch Cluster is installed on a Solaris host before connecting the host to the array.

1. Log in to the host that you want to connect to the array.

2. Go to:

http://www.sun.com/sunsolve

3. Under SunSolve Patch Contents, click Patch Portal.

4. Under Downloads, click Recommended Patch Clusters.

5. Find either Solaris 8 or Solaris 9 in the OS column of the Recommended Solaris Patch Clusters list, click Readme and then click Go.

6. Print or save the Readme file from the browser window.

7. Click the browser's Back icon to return to the previous page.

8. Select the format you want in the row that begins Solaris 8 or Solaris 9 in the Recommended Solaris Patch Clusters list, click either Download HTTP or Download FTP, and then click Go.

9. In the File Download dialog box, click Save.

10. In the Save As dialog box, type a destination directory for the patch cluster, and then click OK.

11. Follow the procedure in the INSTALLATION INSTRUCTIONS section in the Readme file to install the patches.

---

Installing Firmware Patches

Firmware patches for the Sun StorEdge 3510 FC array and Sun StorEdge 3511 SATA array are available to upgrade firmware for the array controller, PLD firmware, and firmware for the SCSI Enclosure Services (SES) processor. For the Sun StorEdge 3511 SATA array, the patch also includes firmware for the SATA Router and the SATA MUX module.

Follow the first three steps in To Download and Install the Firmware Patch to read specific information about fixed bugs and other changes incorporated in this firmware patch, as well as other detailed information and installation instructions.

To determine your current controller firmware version, use one of the following methods:

• Using the RAID Controller serial or telnet interface, select the "view system Information" firmware menu option. The current firmware version is displayed as "Firmware Version."
• In the Sun StorEdge Configuration Service program, highlight any component of the desired array, click on the View menu and the View Controller command, and then check the "FW Rev" checkbox.
• Using the CLI, enter the show inquiry command.

To determine your current SES and PLD firmware versions, use the CLI and enter the show ses command. The SES version of each controller is displayed in the Rev column. The PLD version is displayed in the PLD column.

1. Go to

http://sunsolve.Sun.com

2. Click on Patch Portal.

3. Use Patch Finder to locate the appropriate patch ID by entering the patch ID into the search field and clicking the Find Patch button.

4. Select the link for the format that you want, either HTTP or FTP next to Download Patch, or HTTPS or FTP next to Download Signed Patch.

5. In the dialog box that is displayed, indicate the destination directory for the patch and proceed to download the file to that location.

6. Follow the instructions in the Readme file to install the patch.

Caution - Do not use a version of CLI earlier than version 1.5 to install this patch.

1. Using the bourne shell, korn shell (ksh) or the bash shell, type the following command to identify the two SES device filenames in the chassis.

# for d in /dev/es/*; do sccli --list $d; done | grep 3510F > jbods.txt

This command runs the command sccli -list /dev/es/<d> for each device filename found in /dev/es, and save the lines that match the FC JBOD Array to the file jbods.txt. This command may take a few moments to complete and may display some harmless error messages referring to non-existent devices that may safely be ignored. When it completes, jbods.txt should contain two lines for each directly-attached JBOD chassis. For example, if jbods.txt contains:

/dev/es/ses3 SUN StorEdge 3510F D SN#000187

/dev/es/ses9 SUN StorEdge 3510F D SN#000187

it indicates that /dev/es/ses3 and /dev/es/ses9 are two separate SES devices within the JBOD expansion chassis with serial number 000187.

2. Verify that two device filenames are listed for each chassis serial number, identifying two SES devices in that chassis.

3. Invoke the CLI with the name of an SES device identified in Step 1. Using the example given in Step 1:

# sccli /dev/es/ses3

4. Type the following command to verify the Product and Revision of the array:

sccli> show inquiry

If the device is a JBOD chassis, "Product: StorEdge 3510F D" and "Device Type: Enclosure" are displayed.

5. Type the following command to verify the SES firmware version:

sccli> show ses

The output of this command displays the SES version under Rev, and displays the PLD version under PLD.

6. Verify that the SES code version identified in the Rev column indicates 1030 or earlier. If the SES code version is 1040, proceed to Step 13.

7. If the SSCS agent is running on your workstation:

• Issue the following shell command as root on the system where the SUNWscss package is installed to stop the SSCS agent:

# /etc/init.d/ssagent stop

• If the SSCS agent is running on a Microsoft Windows system connected to the array, issue the following command to stop the SSCS Agent service:

Start Run services.msc

8. If StorEdge Diagnostic Automated Diagnostic Environment or any other application which monitors the status of the enclosure is running, follow the procedure described in the documentation for that application to stop the agent software.

9. Invoke the CLI with the name of an SES device identified in Step 1. Using the example given in Step 1:

# sccli /dev/es/ses3

10. Type the following command to download the SES firmware:

sccli> Download ses-firmware fc2u_sun_1040a.s3r

The CLI upgrades the SES firmware. It is not necessary to reset the JBOD enclosure.

11. Type the following command to verify that the SES device has been upgraded:

sccli> show ses

12. Ensure that the SES firmware version indicated in the Rev column has changed to 1040.

13. Verify that the PLD code version identified in the PLD column indicates A000 or earlier. If the PLD code version is 1000, proceed to Step 20.

Caution - If you use a version of the CLI that precedes version 1.5, or if array power is lost during this procedure, the enclosure can be rendered unusable.

14. Ensure that all host I/O activity has been stopped. The JBOD will be unable to process host I/O activity for up to 10 minutes.

15. Type the following command to download the PLD firmware:

sccli> download pld-firmware pld1r10.s3r

The CLI indicates that it is sending the PLD firmware data, and programming the flash memory. All the LEDs on the array light while flash is programmed, and the CLI will pause for three to five minutes.

Caution - Do not power cycle the array at this point. Note the time and wait at least five minutes for the PLD flash programming operation to complete.

16. Wait at least five minutes after seeing the message "Please wait 3 to 5 minutes until PLD flashing completes." Then turn power to the array off, wait 10 seconds and then turn power back on.

17. Invoke the CLI with the name of an SES device identified in Step 1. Using the example given in Step 1:

# sccli /dev/es/ses3

18. Type the following command to verify that the SES device has been upgraded:

sccli> show ses

19. Verify that the PLD column says 1000, indicating that the PLD firmware has been upgraded.

20. If the JBOD array contains:

a. Only one I/O Module FRU, the JBOD array can be returned to service.

b. Two I/O Module FRUs and two cables, repeat Step 9 through Step 19 for the second ses device identified in Step 1. Using the example identified in Step 1, you would connect with the JBOD by typing the command:

# sccli /dev/es/ses9

c. Two I/O Module FRUs and only one cable, move the cable from one I/O Module to the other and repeat Step 9 through Step 19.

---

Downloading Updated Sun StorEdge 3000 Family Software

The most recent version of Sun StorEdge 3000 Family software is available at the Sun Download Center.

1. Go to:

http://www.sun.com/software/download/

2. Under System Administration > Storage Management, click the Sun StorEdge 3000 Family Storage Products - Related Software link, and press the Download button.

You are taken to a Sun Download Center page.

3. If not previously registered, register.

a. Click the Register Now link at the bottom of the left column.

b. On the registration page, enter applicable data in the required fields and click Register.

4. Log in.

a. Type your Username and Password in the left column, and click Login.

b. On the Terms of Use page, read the license agreement, click Yes next to Accept, and click the Continue button.

5. On the software download page, click the link for your array and operating system.

6. In the dialog box that is displayed, specify a destination directory and save the file.

7. Follow the software installation instructions in the Sun StorEdge 3000 Family Software Installation Guide.

---

Installing Sun StorEdge SAN Foundation Software

Before a Sun host running the Solaris 8 operating system or Solaris 9 operating system on SPARC platforms can communicate with the Sun StorEdge 3510 FC array or Sun StorEdge 3511 SATA array through any of the host adapters that are supported for Sun servers, you must install Sun StorEdge SAN Foundation software.

The Sun StorEdge SAN Foundation software is required in these operating environments because it provides drivers for the supported host adapters. (See Supported Platforms and Connection Methods for listings of the applicable host adapters.)

See the following procedure for instructions on downloading the SAN Foundation software without charge.

1. Log in as superuser on the Sun server to be connected to the array.

2. Go to:

http://www.sun.com/storage/san

3. At the bottom of the page, below "Get the Software," select the "Sun StorEdge SAN 4.4 release Software/Firmware Upgrades and Documentation" link.

4. If not previously registered, register.

a. Click the Register Now link at the bottom of the left column.

b. On the registration page, enter appropriate data in the required fields and click Register.

5. Log in.

a. Type your Username and Password in the left column, and click Login.

b. Click Continue on the Sun Download Center Welcome page to see the Terms of Use page.

c. On the Terms of Use page, read the license agreement, click Accept and then click the Continue button.

6. On the Download page, download the Solaris 8 SFS Base Packages or Solaris 9 SFS Base Packages, depending on which version of the Solaris Operating Environment you are running.

7. You can also download the SFS Base Packages Readme file for software download instructions.

8. Once you uncompress and untar the SFS Base Packages archive, follow the instructions in the Sun StorEdge SAN Foundation Software Installation Guide to manually install the packages.

---

Downloading the VERITAS Volume Manager ASL for the Sun StorEdge 3510 FC Array

This section explains what you need to do to enable VERITAS Volume Manager 3.5 and 4.0 software to work with the Sun StorEdge 3510 FC array on Sun hosts. VERITAS has provided an Array Support Library (ASL) that must be installed on the same host system as the Volume Manager 3.5 or 4.0 software to enable the software to recognize the Sun StorEdge 3510 FC array. Follow the procedure to download the ASL and the accompanying installation guide for the Sun StorEdge 3510 FC array from Sun's Download Center.

1. Log in as superuser on the Sun server to be connected to the array.

2. Go to the All Products listing at Sun's Download Center.

http://www.sun.com/software/download/allproducts.html

3. Under the V heading, click on VERITAS Volume Manager Array Support Library (ASL).

4. Choose the link that is appropriate for your platform.

5. Click Download to go to the Sun Download Center.

The page identifies the product you selected to download as VERITAS Volume Manager Array Support Libraries (ASL) for your platform and language.

6. If not previously registered, register.

a. Click the Register Now link at the bottom of the left column.

b. On the registration page, enter the required fields and click Register.

7. Log in.

a. Type your Username and Password in the left column, and click Login.

b. On the Terms of Use page, read the license agreement, click Yes next to Accept, and click the Continue button.

8. Download the compressed ZIP file that contains the ASL package for the 3510 FC array.

9. Use the unzip command to expand the zip file.

---

Enabling VERITAS DMP for the Sun StorEdge 3511 SATA Array

Since the Sun StorEdge 3510 FC and 3511 SATA array is a new product, VERITAS has not yet provided an Array Software Library (ASL) for it. To enable VERITAS Dynamic Multi-Pathing (DMP) support on VERITAS Volume Manager, perform the following steps.

1. Configure at least two SCSI channels as host channels and add additional SCSI host IDs if needed.

2. Connect host cables to the I/O host ports in step 1.

3. Map each LUN to two host channels to provide dual-pathed LUNs.

4. Add the correct SCSI string to vxddladm so VxVM can manage the LUNs as a multi-pathed JBOD.

# vxddladm addjbod vid=SUN pid="StorEdge 3511"

# vxddladm listjbod

VID      PID           Opcode  Page Code  Page Offset SNO length

================================================================

SEAGATE  ALL PIDs       18  	   -1          36         12

SUN      StorEdge 3511  18      -1          36         12

5. Reboot the hosts. System reboot is required to implement these changes.

---

Known Issues

These known issues are arranged in numeric order and according to the platforms they affect. Some bugs affect both Sun StorEdge 3511 and Sun StorEdge 3510 arrays. Others affect only one of those platforms.

Known Issues Affecting Both Arrays

The following bugs affect the Sun StorEdge 3510 FC array and the Sun StorEdge 3511 SATA array.

• Bug 4702532: Write cache not automatically disabled when battery is offline. Write cache is not automatically disabled when battery is offline due to battery failure or a disconnected battery. The current design allows the user to enable or disable the write-back cache capabilities of the RAID controller. The cache in the Sun StorEdge 3510 and 3511 RAID arrays is mirrored between the primary and secondary controllers; however, to ensure data integrity, you may choose to disable the Write Back cache option and switch to the Write Through cache option.
• Bug 4714227: The character interface sometimes fails to respond correctly. While running heavy I/O to several LUNs on different logical drives and scrolling through a menu that is long, such as a long, multiple LUN mapping menu, occasionally the menu will "escape" back one or two menus. This problem only occurs under heavy I/O and occasionally when accessing the unit using telnet over long distances.
• Bug 4743721: SSCS: no method for identifying disk drives. The Sun StorEdge Configuration Service program currently cannot identify a disk drive by flashing disk drive LEDs on the array.
  Workaround: Use the firmware application's "Identify scsi drive" command, which offers three modes for flashing the drive LEDs.
• Bug 4822129: Inconsistent error message between reporting methods and documentation. Event messages sometimes differ between firmware logs, Sun StorEdge Configuration Service, CLI, and SNMP traps.
• Bug 4872004: Time not consistent between primary and secondary controllers during failure. Time stamps in event messages from a secondary controller might not be consistent with time stamps included in the same event messages from a primary controller. While the time stamp in primary controller event messages are correct, secondary controller event message time stamps might be off by 12 hours, and the year might be incorrect.
• Bug 487679: sccli commands don't work for standalone JBOD. sccli 1.5 was enhanced to support standalone JBODs by adding code to support the SHOW FRUs, SHOW SAF-TE, SHOW SES, DOWNLOAD PLD-FIRMWARE, DOWNLOAD SAF-TE-FIRMWARE, and DOWNLOAD SES-FIRMWARE commands. These commands are not yet supported for a standalone JBOD: display of both SES I/O Controllers using the SHOW FRU and SHOW SES commands, SHOW FRU also does not yet display voltage, temperature, fan and power supply status, as well as FRU status.
• Bug 4883836: sccli: no method for identifying disk drives. There is currently no way to identify a disk drive by turning on its LED via sccli.
• Bug 4967520: Firmware doesn't track drive failure and the drive can scan back ok. The 3510 controller can automatically scan a drive back into the system after a drive failure. The controller will update the status of all Logical Drive (LD) members that a drive has failed but will not update the failed disk. This allows a failed disk to be scanned back into the system in the case of a spurious error with a USED state. This potentially bad disk drive can then be added to the spares pool if the Automatic Assign Global Spares feature is enabled and the disk drive passes the controller validation criteria. To minimize the impact of this issue, the "automatic assignment of global spare" feature can be disabled so the device will not be used as a spare but remain in the USED state. Documentation is being enhanced to provide this information.
• Bug 4976393: SSCS monitoring sw not backward-compatible with previous versions. When using a central host with Sun StorEdge Configuration Service to monitor a number of systems with arrays attached, the SSCS software is not backward-compatible with previous versions. The upgraded software cannot discover any previously monitored systems until you upgrade the agent package on the attached hosts.
• Bug 4993105: Read/Write Failures on SE3510/SE3511 during 24 hour RSCN fault injection test. Occasionally when cables are pulled and replaced, the host may lose all paths to the Sun StorEdge 3510 or 3511 array. At this point, a read/write error occurs, and all I/O is stopped to the LUNs.
• Bug 5016154: SCCLI: OOB connection failed with "network connection setup failed". While trying to communicate to diag67 (3310 SCSI) 00b via StorADE, I could not gain access to the unit. In-band works fine. The problem with StorADE is that the sccli can not communicate with the Sun StorEdge array. This applies to other Sun StorEdge 3000 arrays as well.
• Bug 5022022: DRAM parity errors/SDRAM ECC errors can cause data corruption. SDRAM error appeared in the syslog and kept on flooding the /var/adm/messages. However the event log showed DRAM parity errors. These messages are inconsistent. It was noticed that after the message in the /var/adm/messages, vxfs file system gave an error and the filesystem got corrupted.The workaround is to replace the controller for the first instance of SDRAM error on the syslog and make sure to run parity regeneration to ensure data integrity.
• Bug 5026182: Firmware upgrade/downgrade displays incorrect timestamp via sccli show events. The RAID controller generates a time stamp via firmware that can drift over time.
  Workaround: Reset the time manually.
• Bug 5029233: SE3510/SE3511 presenting unpermissioned LUNs to host. The LUN filtering function does not work properly when the "name" attribute is set and the WWN mask is 0xffffffffffffffff. The firmware uses the "name" field as the "WWN mask" to compare the HBA WWN with the filtered WWN and can get a incorrect result for some WWNs.
• Bug 5034422: SE3510/3511 ethernet interface very slow / hangs when running at 100MB half duplex. RAID array's Ethernet connection is very slow if it is connected to a DLINK DFE 9080x running at 100MB half-duplex. The device is not a switch but a dual-speed hub that was EOL'd in 1999. Auto-negotiation was not ratified until 1997, probably before the hub was designed.

The controller firmware did not incorporate a robust link recovery algorithm resulting in intermittent operation in certain configurations.

Because auto-negotiation operates at 10BASE-T frequencies, the negotiation phase will often succeed on cable that will not support a 100BASE-TX link. 100BASE-TX half duplex must handle collisions, contentions and arbitration which are not factors with full duplex. Marginal cable can cause a link to either operate with a high rate of errors, or not at all. Cable length for half-duplex is limited to 330 feet; full-duplex is rated to 6600 feet.
Workaround: Use a switch port capable of full-duplex operation for the most reliable operation. Switch ports should be configured for auto-negotiation. You can check the error statistics and negotiated protocol from the user interface under communication parameters. There may also be signal integrity concerns.

• Bug 5039653: Both controllers sometimes get hung with sccli show lun-maps with more than 16 filter entries. When sccli 1.5 is used with more than 16 filter entries configured for a LUN mapped on a particular port channel and multiple LUNs exist on the same channel, the yellow maintenance LED is lit on one or both controllers.
  Workaround: Do not use sccli show configuration or show lun-maps if you have more than 16 filter entries.
• Bug 5039690: Show lun-maps is limited to 256 lines. For complex LUN filtering configurations, more than 256 items can occur in mapping configuration. sccli show lun-maps is unable to provide more than 256 entries.
  Workaround: Use the RAID firmware menus to see the whole LUN configuration.
• Bug 5051108: password security issue with minnow firmware/sccli. When a password is required to perform certain operations over the network on StorEdge 3000 Family RAID controller products, sccli transmits the password in clear text. This may represent a security issue for sites where a hostile third party can capture network traffic between the host on which sccli is running and the storage device. As a workaround, the customer can configure their network so that snooping is not possible (this is the default behavior in most switched ethernet topologies).
• Bug 5063863: Power-cycling Ex500 hosts with 1Gb HBA connected to 3510 array will lose access. A Ex500 host using a supported 1-Gb HBA (PN# 375-3048) connected to a 3510 is working fine until the host is power-cycled (via the key switch). When the hosts is powered back on and booted the 3510 link status LED is not lit and the partitions/LUNs that the 3510 has mapped out are not seen in format.
  Workaround: Change the data rate from Auto to 1GHz on the 3510 FC channel connected to the host.
• Bug 5069970: SE3510FC: Addition of JBOD expansion unit to existing RAID unit not documented. The current documentation set for the SE 3510 FC array doesn't include a specific procedure on how to install a JBOD expansion unit to an existing, configured RAID array, although it does say they can be "dynamically added." A documented procedure, including the need to at least quiesce host i/o to the array before connecting the expansion unit to the RAID unit, is requested as there has been confusion in the field over the meaning of being able to "dynamically add" expansion units to existing RAID units (literally cabling new expansion units to running, production RAID units).
• Bug 5082717: sccli 1.6.1 - 'show battery' becomes INTERACTIVE when run for first time. Running the sccli (v1.6.1) on an SE3511 for the first time. Run the command 'show battery', and it asks a question: sccli> show battery The date 2004/ 8/ 4 will be stored as the In-Service Date of Upper Battery. Are you sure that this date is correct? y. After the user answers the question, the command shows you the battery information. No "show" command should be interactive.
• Bug 5105001: sccli show disk no longer displays the drive firmware revision. 3.27T firmware for 3511 changed the drive data information structure, and made the disk model string 32 bytes long. The SCSI spec says it should be 24 bytes. sccli always assumes a drive data structure will have a 24-byte-long model string instead of the model offset and length provided in the same SATA structure. Therefore the revision is not in ASCII, and the sccli display route doesn't display the revision number.
• Under heavy load, the SSCS console might become unresponsive. If the Sun StorEdge Configuration Service (SSCS) console does not reconnect after the load decreases, perform a rescan. This situation can also prevent event messages from being emailed by SSCS Console and Diagnostic Reporter software, as well as updating of the SSCS console. The workaround is to assign a primary host LUN for SSCS to communicate with exclusively. No data or I/O should be used on this path. In order for this workaround to be effective, you must map only the LUN that SSCS will use and configure SSCS before mapping the data drives.
• When configuring the Web Server for use with ESM the Configure Web Server feature may fail. When configuring the Web Server for use with Enterprise Storage Manager, the Configure Web Server feature under Custom Configuration Options may fail. To configure the Web Server manually, log in as superuser on the host on which the Sun StorEdge Configuration Service agent is running and issue the command:

# /usr/sbin/sscfghtml.sh -i ipaddress -p password

where ipaddress is the host name or IP address of the array, and password is the password assigned to the array. Allow 20-30 seconds for this command to complete, and then verify that it worked by using any web browser to visit:

http://ipaddress/esm.html

The Web browser displays a message "This page launches the Sun StorEdge(tm) Configuration Service Console applet" and, if the SUNWnsmat package is installed, the SSCS GUI will be launched.

Caution - Do not select the "Restore Factory Defaults" option in the SSCS Change Controller Parameters window. This command overwrites new or changed IDs, removes all mappings, and loses communication to the devices due to the loss of mappings.

Known Issues Affecting Sun StorEdge 3511 Arrays

• Bug 5016154: sccli: OOB connection failed with "network connection setup failed." This appears to be a firmware problem in which the "primary agent" task in the RAID firmware (Sun StorEdge 3310 or Sun StorEdge 3511) refuses to accept a connection from sccli on its network interface. When this happens, sccli may ask for a password when trying to connect to the array out of band.
• Bug 5034695: sccli: show inter-controller-link is not functioning properly. In released SATA SES code, SATA SES has a different PBC than the 3510 array. All ICL operations are a PBC-related action, and will not be supported until SATA SES code starts to support that.
• Bug 5036411: Luns created and mapped don't appear on the host without forcelip. Logical drive 0 was created and partitioned; three partitions were mapped to the host using host filter. The LUNs are not seen by the host until a forcelip is issued on the paths.
• Bug 5037166: sccli <device> show config -xml "outputs wrong total numbers of SES. show config --xml is using the SES target numbers returned by the RAID controller firmware. However, the RAID controller firmware only reports the SES on one drive loop and does not report the SES on its redundant loop.
• Bug 5045629: running "show disks in a logical-drive" returned value of LD Index is always 0. The sccli command "show disks in a logical-drive" displays information about the disk drives in the specified logical drive. However, the returned value of the LD Index is always 0. The logical drive index is maintained by sccli rather than by the RAID firmware. The sccli utility should echo this information to the CLI command line, but did not.
• Bug 5049271: unmap command fails to unmap LD partitions with filter mapped entries. sccli checks the filter map before unmapping the logical drive. If the mapping has a filter map, sccli does not allow unmapping it.
• Bug 5050720: Sscli & SSCS with multiple lun filters create ID-partitions of 00000000-00 and {}. show conf missed a LUN map filter entry and displayed two new entries with ID-Partition numbers of 00000000-00. The RAID firmware allows multi-partition mapping on the same mapping point due to a bug in the firmware's external interface. In some cases, it is possible to create this mapping using the management software. Once multi-mapping has been created, show map displays incorrect information.
• Bug 5054686: Host filter mapping failed with the error "Map Host LUN Failed." 13 luns were successfully mapped on the secondary controller. When attempting to map the 14th lun, the mapping failed with "Map Host Lun Failed!". If "map host lun" is used without host filtering, the mapping succeeds. If the 13th lun is removed and the 13th lun is mapped using host filtering it succeeds. The 14th lun is mapped successfully using host filtering. But lun 15 mapping fails using host filtering.
• Bug 5059398: Data Corruption during IO, with LD rebuild and multiple fault condition. Under very heavy I/O conditions from Diskomizer concurrent with a disk rebuild option and a script that performs automated RAID controller fail-over/fail-back or multiple boot cycles, a timing race condition within the RAID Controller firmware can occur after an extended period and can result in a RAID stripe not being properly locked. The results in the data for the stripe not being written to the disk, or in some cases, the data is incorrectly overwritten and the stripe can be corrupted. This has only been seen so far in a heavily loaded, double-fault condition of some kind, such as induced controller failure in multiple cycles while rebuilding a drive, or server reboot cycles while rebuilding a drive with multiple hosts. This is not a Sun StorEdge array bug but a kernel bug, but may affect Sun StorEdge 3511 SATA array customers.
• Bug 5091272: Cannot perform parity check on LD assigned to secondary via the CLI. CLI doesn't allow two parity check operations at the same time. If a logical drive parity check operation is already underway, an incorrect error message is displayed.
• Bug 5094897: LD rebuild only gets to 99%. With an SE 3511 RAID array and six-drive LD assigned to a secondary controller, a disk drive was removed and replaced with a new one. The rebuild stalled at 99% for at least two days. There was heavy I/O during some of the time. The array was reset and the rebuild started at 0% again. Without I/O, the rebuild completed in around 12 hours.
• Bug 5096149: Tip session displays garbage characters when failed sec. control is de-asserted. Using a tip session to manage a 3511 array, a secondary controller failed and was allowed to remain in the degraded state for approximately twenty minutes. The "failed" secondary controller was de-asserted through the same tip session and garbage characters starting appearing on the Tip Display window.
  Workaround: <ctrl> L usually cleans up the screen. If this fails, close the tip session and start another tip session.
• Bug 5102832: sccli show events does not show MPxIO path degrade information for 3511. When oob monitoring the 3511, the monitoring host may be different from the host that 3511 hooked (through a switch). When MPxIO path is degrading, there is no way to catch such information from /var/adm/messages.

Known Issues Affecting Sun StorEdge 3510 Arrays

• Bug 4819218: Differences between firmware and sccli events. The firmware application menu event log timestamp and the sccli event log timestamp appear as different times. This is because the firmware application menu gets its timestamp information from the time that is set on the RAID controller, and the sccli utility gets its timestamp information from the server that it is running on. Additionally, the sccli utility currently reports events from the primary controller only.
  Workaround: Manually set the clock on the controller to match the server to which it is connected.
• Bug 4825806: BBU warnings should not be as severe. The array has a battery circuit board that monitors and charges the battery during normal operation. Since the battery is not charging while the array is powered off, some of the charge of the battery will dissipate. When the array is powered on, the battery circuit board will detect the power dissipation of the battery and will display the following message: "|[0125] WARNING: Controller BBU Not Fully Charged" and begin to recharge the battery. Once the battery is fully charged, the following message will be displayed: "|[01A5] NOTICE: Controller BBU Fully Charged!"
• Bug 4881785: Cluster panics with Logical Volume on Secondary Controller. In a Sun cluster environment, when the logical volumes are assigned to the secondary controller, the cluster will panic during node failover. The documentation has been modified to warn against using logical volumes (a legacy feature) in a Sun Cluster environment.
• Bug 4888608: Solaris SES driver receives incorrect response from RAID array in attach. The issue concerns the SES emulation response with LUN masking. If the array is configured for LUN masking and LUN 0 is not mapped to a logical drive, the array will return a zero length response to an SES configuration mode page request. This causes the Sun driver not to attach the device.
• Bug 4896313: Cache data isn't flushed correctly in case of primary battery failure. If the battery is unplugged or dead, write cache is not disabled. This means that if power is lost, data in the cache could be lost.
• Bug 4900452: Network connectivity through default gateway is unreliable. The out-of-band connection of the RAID array may not communicate with a host through the configured default gateway until communication is established with a network device that is on the same subnet as the array.
• Bug 4901347: Disk information from sccli and firmware don't match. Information returned by the RAID array through sccli is not as complete as information returned when monitoring the array through the firmware. When you monitor drive parameters through sccli, the SCSI Motor Spin-Up, SCSI Reset at Power-Up, and Disk Access Delay Time parameters are not displayed, though they are through the firmware.
• Bug 4901393: SCCLI error messages are too vague. Error messages may be unclear as they are displayed by the sccli, and are not defined in the sccli manual.
• Bug 4906783: Firmware is not integrated with the FRU-ID's. The RAID Controller serial number is displayed in the error messages instead of the FRU-ID serial number.
• Bug 4911841: Unable to send SNMP traps using 'agent.ini' file, as documented. SNMP traps from the RAID array are unable to be sent using the 'agent.ini' file, as documented in the User's Manual.
  Workaround: Use SSCS to send the SNMP traps.
• Bug 4921484: RAID array did not shut down during extended overtemp conditions. The unit must shut down if the temperature exceeds the given limit. Currently the unit does not shut down. However, the unit is fully NEBS certified, and will handle the required temperatures required by NEBS certification.
• Bug 4924834: Physical disk drive are displayed with inconsistent size throughout the product. The same disk drive size is displayed as 34476M by the sccli, 34476MB by the XML output, 33.92GB by the sccli show config command, and 34732MB by the tip/telnet output.
• Bug 4931174: Invalid Transmission Word stops incrementing when it reaches 65535. The Invalid Transmission Word counter, which increments on detecting receive errors, stops counting when it reaches 65535. This counter is reset to zero when there is a power cycle or reset.
• Bug 4942959: Storade - device port status is not monitored by 3510 firmware or sccli sw. The host should detect that a cable is removed. Adding this functionality to the RAID Controller Firmware would require a very significant amount of effort.
• Bug 4944252: After a disk failure, the drive is no longer displayed by sccli. After a disk drive fails, the drive is no longer displayed by sccli.
• Bug 4946986: SSCS reports incomplete information about a critical error. A critical error message displayed by SSCS was decoded using the error_msg_configService.pdf provided by Dot Hill. When the error message was decoded, the last byte was not defined the table G-28 in this document. The documentation will be updated to clarify SSCS error codes.
• Bug 4950237: sccli - show disks should show both disk channels, not just one. The sccli show disks command shows only one channel. It does not show that disks are connected to two channels.
• Bug 4950297: Parity checks run from the GUI always enable auto-correction of parity. When you run a parity check from Sun StorEdge Configuration Service, auto-correction of parity is always enabled.
  Workaround: Run the parity check manually from the serial port or a telnet session.
• Bug 4955390: scgdevs cluster command causes array to reset. After a firmware upgrade, array resets may occur when certain cluster commands, such as scrubber or scgdevs, store keys in the persistent reservation area.
  Workaround: When the array resets, hit the 'skip' option to avoid writing into the persistent reservation area.
• Bug 4959806: sccli: can't gain access to LG# from the firmware. Logical drives created out of order, such as 0, 6 and 7, will be displayed by the sccli utility as LD0, LD1, and LD2. This is also true for logical volumes displayed through the sccli utility.
• Bug 4960959: Controller replacement sometimes fails under heavy I/O load. In certain cases, when a controller is pulled and then replaced, it sometimes fails to become primary/secondary under heavy load. The LEDs on both controllers are solid green and the LUNs assigned to the secondary controller cannot be accessed from a host.
  Workaround: Reseating the secondary controller fixes the problem in most instances.
• Bug 4964418: LD initialization sends FW event but LD deletion does not send event. The RAID array does not save an event to the event log when a logical drive is deleted.
• Bug 4964422: LD initialization event is inconsistent between telnet and SCCLI. The event message displayed by a telnet session with the RAID array is not the same as the event message that is displayed through sccli for the same event.
• Bug 4966606: When a disk is pulled out from 3510/3511 array, sccli: disk status should be missing. When a disk is pulled out of the array, the disk status is displayed through sccli is "Bad drive" instead of "Drive missing."
• Bug 4975148: SES fw upgrade via cli connects inter-controller-links that were disconnected. This makes devices unavailable to the host if the original configuration is point to point with more than 1 ID per channel (inter-controller links disconnected). When support for FC Port Bypass Control was added to SES firmware, the Inter-Controller Links were changed from permanent to temporary settings, meaning they are not restored across power cycles or firmware upgrades. The ICL settings are already saved in NV memory so that both boards have access to the settings. To change the ICL bits back to permanent, these bits will not be cleared on a firmware upgrade, and will be restored on a reboot.
• Bug 4976393: SSCS monitoring sw not backward-compatible with previous versions. When using a central host with Sun StorEdge Configuration Service to monitor a number of systems with arrays attached, the SSCS software is not backward-compatible with previous versions. The upgraded software cannot discover any previously monitored systems until you upgrade the agent package on the attached hosts.
• Bug 4980144: Dual-ported disk can be scanned twice. If a disk drive is assigned to two channels, that drive can be scanned two times, once time for each channel. If this happens, it is possible to assign the same disk drive to a logical drive twice.
  Workaround: Scan from only one channel any disk drives that are assigned to two channels.
• Bug 4990550: disk drive firmware download failed, but script reset controller and says succeed. When downloading disk drive firmware using sccli, if the download fails, sccli reports that the download was successful and resets the controller.
• Bug 4991110: sccli show channels indicates speed has changed from 2G to ASYNC. In some cases, after a firmware download, the host channel link speed is displayed incorrectly. This condition persists until the next controller reset or the next LIP on a given channel.
• Bug 4992074: failed drive disappears. If too many bad blocks are encountered on a hard drive during logical drive initialization, the initialization will fail. As a result, the failed drive will not show up on the "view and edit scsi drives" menu. It will still be displayed in the loop maps menu option in the sccli utility. After resisting the controller, the bad drive will be displayed in the "view and edit scsi drives" menu.
• Bug 4995551: Serial numbers in event log are inconsistent or missing. No serial numbers are displayed from the firmware for controller initialization events. Controllers are identified as p (primary) or s (secondary), but a controller's primary and secondary roles are not fixed, and may change over time. Similarly, in the sccli, all controller events display the serial number of the primary controller, even if the event was generated by the secondary controller.
• Bug 4996006: 3510/3511 JBOD: "SES/PLD firmware mismatch" error should be captured by sccli & SSCS. If an SES/PLD firmware mismatch is encountered on a Fibre Channel JBOD, this condition is indicated by a flashing Event LED and an audible alarm. Neither of these indications are reported by sccli or Sun StorEdge Configuration Service.
• Bug 4999304: syntax problems with sccli help and man pages. The CLI online help uses the shorter form of the command, such as "show led-status" and "show led" are the same command, and "show safte-status" and "show safte" are the same command. These shortcut commands are not listed consistently throughout the SCCLI online help utility. The SCCLI utility needs to be more consistent with the user guide.
• Bug 5006323: Download nvram command results in error and fails to restore a reset config. Straight upload/download works, but if you reset NVRAM in between, it fails on the IP address. The workaround is to either use the tip via serial port connection, or an in-band CLI so the network interface parameters can be reset.
• Bug 5007650: Controller offlines disk drive with an "Unexpected Sense Received" event. Event logs were discovered where the drives on a system were wrongly failed by the controller firmware. Documentation is needed that describes all the sense codes returned by the drives and how the controller firmware responds to the drive sense codes.
• Bug 5008088: sccli show removed disk capacity as 2TB or 0MB, the status should be missing. The RAID firmware external interface still returns stale data even though the drive is removed; size is reported as 0 or max (2TB).
• Bug 5014422: sccli show frus returns inconsistent result intermittently. Running sccli version 1.5 and FC 3510 firmware 3.27R in-band for 14 hours (3200 iterations), the command did not return FRU information in seven cases. This appears to have been a problem with the in-band connection, resulting in no FRUs shown but no "FRU missing" message. sccli access to the 3510 array through an in-band connection sometimes retrieves bad pass-through command status when scanning SES targets, resulting in 0 SES targets found. Since all FRUs are reported by SES targets, if 0 SES targets are found, then no FRU is reported.
• Bug 5016303: sccli should show removed FRUs with status "missing." When we remove a FRU from an array, the sccli show fru command does not show that FRU anymore. Instead it should keep showing the FRU information with status "missing." However, since there is no unique default configuration; there can be multiple number of drives, controller, etc., and the array is displaying information as designed.
• Bug 5018110: gui chops hostname. SSCS stored the first 7 chars of the host name which SSCS agent is assigned to manage the storage unit. Because the controller firmware only enable 8 bytes (64-bit WWN) for each item, so only the first seven characters and the trailing zero are stored.
• Bug 5020212: ssconsole allows two managing servers assigned for same array. ssconsole accepts "controller assignment" for 2 servers simultaneously after merging installations into one GUI environment. SSCS stored the first 7 chars of the host name which SSCS agent is assigned to manage the storage unit. When "berlab060" is assigned to manage the RAID unit, "berlab0" is stored in the RAID unit. However, when "berlab061" is assigned again, the SSCS agent compares the first 7 chars and treats it the same as "berlab060", so there is no warning message for this server.
  Workaround: Reassign controllers after merging. This will allow only one of the visible servers to act as a controlling instance for GUI operations.
• Bug 5021983: "SDRAM ECC error" is wrongly translated as "DRAM parity error". The firmware changed but the translation did not. Should always be "SDRAM ECC error" because there is no DRAM Parity.
• Bug 5022022: DRAM parity errors/SDRAM ECC errors can cause data corruption. SDRAM error appeared in the syslog and kept on flooding the /var/adm/messages. However the event log showed DRAM parity errors. These messages are inconsistent. It was noticed that after the message in the /var/adm/messages, vxfs file system gave an error and the file system got corrupted.The workaround is to replace the controller for the first instance of SDRAM error on the syslog and make sure to run parity regeneration to ensure data integrity.
• Bug 5026029: Firmware upgrade/downgrade shown as controller failure detected from sccli. Once the firmware is downloaded onto both controllers, they reset automatically one by one, and upon initialization are loaded with the new firmware. The RAID controller displays an informational message to the user concerning the controller going down, but sccli generates a "redundant controller failure detected" event.
• Bug 5032470: When bad drive parity encountered 3.27Q, event is not fully logged. When a drive parity inconsistency error is encountered, the event only has the event number and is not fully logged in the event log on the array.
• Bug 5034422: SE3510/SE3511 ethernet interface very slow/hangs when running at 100MB half duplex. SE3510 FC array ethernet connection is very slow, if it is connected to a DLINK DFE 9080x running at 100MB half duplex. The test script, using sccli commands, hangs after 2 or 3 days.
• Bug 5036074: README File for Patch 113723-07 download wait time is too short. README file tells user to wait 2-4 minutes for download completion of firmware, while the FRU install document indicates a wait time of 10 minutes or more.
  Workaround: Wait four minutes until the download time has completed and the firmware prompt returns. When power-cycling the controller or replacing the FRU, wait an additional 10 minutes before proceeding.
• Bug 5036125: "sccli <device> show config -xml" outputs wrong total numbers of SES devices. show config --xml is using the SES target numbers returned by the RAID firmware; however the RAID controller firmware only reports the SES on one drive loop, and does not report the SES on its redundant loop. Code will be added to scan all SES targets to get the total SES target.
• Bug 5038581: FI: Fan failure recovery displays different error code for telnet and sccli. The event descriptions are similar but the event codes are not the same. The telnet session event code was [3FA2] versus sccli event code[3Fdf]. These are not error codes and will not be present in the next firmware and software release.
• Bug 5038863: Command timeout on 3510 FC array due to no XF_RDY for ~ 90 seconds. Intermittent time outs occur for SCSI commands pertaining to communication with the array. The SCSI command used for configuration and monitoring do not complete causing /var/adm error messages to be output. Commands are completed normally on a retry. The trace of this issue showed no response from the 3510 to a Send Diag command. This occurred intermittently when a server was rebooted in this SAN configuration and is a side affect of a firmware change in the 3.27R release. It has been determined this occurs in loop only, public and private, with fabric mode used as a valid workaround. The firmware did not always handle interrupts properly during login/logout and/or loop initialization, resulting in command time outs.
  Workaround: This is currently believed to only affect 3510 arrays in loop mode. Changing the array to fabric point-to-point mode avoids the problem (refer to the SE3510 documentation for configuration limitations in fabric point-to-point mode). This workaround only applies to configurations with fewer than 64 LUNs.
• Bug 5051991: sccli diags does not support interactive password option. This bug prevents StorADE from supporting the diagnostic function when user sets password on the 3510 device. As interactive password is not supported when running sccli, diag option will open a security hole. The "show shutdown" and other diag commands do not invoke the passwordcheck() routine to prompt for a password interactively if one is not provided by an interactive user. This will be fixed in the next release. However, this bug should not affect StorADE because StorADE should be using the password command to specify the password prior to specifying other commands, rather than waiting for sccli to prompt for the password. The evaluation you have for this bug is incorrect. The "show shutdown" command does not permit the password redirection. There is no workaround for this bug without exposing the password in the process table.
• Bug 5072698: Getting "NVRAM CRC Error! MVRAM must be reinitialized" on SE3510 while resetting. The error "NVRAM CRC Error! NVRAM must be reinitialized" appears when the SE3510 is power cycled and the array booted. All the LUN mappings were gone and everything had to be remapped and only then the host could see the LUNs.
• Bug 5085064 : Bad Block reallocation success or failure is not indicated on reads. When bad block errors occurs, the event log records the bad block error with no indication of a reallocation success or failure.
• Bug 5089837: Show port-WWNs does not show all WWNs. The system configuration is:

	PID	SID
FC0	40	41
FC1	NA	NA
FC4	NA	NA
FC5	45	46

When the sccli command show port-wwns is run, it does not show both WWNs for FC5. Similarly, if FC4 is configured, the sccli command will not show its WWNs.

• Bug 5091272: cannot perform parity check on LD assigned to secondary via the cli. The CLI currently performs the parity check operation only on RAID 1, 3 or 5 logical drives on the primary controller.
• Bug 5091492: unmap partition partition does not work as documented. Two of the command options do not work. The command unmap partition <partition-id> [<channel>] does not work. The syntax for unmapping a partition with a wwn-name works, but only when it applies to a partition without a filter map.
• Bug 5093552: Host Chl PID marked NA shows different output of the Speed (CurSynClk). When the chl Host PID is not assigned to any scsi ID as marked NA, the CurSynClk output shows a blank space in `view and edit scsi channels' table and the "speed" output shows "ASYNC" in `sccli show channel' table. These outputs should be the same.
• Bug 5095223: Recovery behavior of LD needs to be a manual process. The Sun StorEdge 3000 Family Installation, Operation, and Service Manual - Sun StorEdge 3510 FC Array states in Section "8.5 Recovering from Fatal Drive Failure" that you can recover from a Status: FATAL FAIL (two or more failed drives) by simply resetting the controller or powering off the array. This is invalid behavior and needs a manual process of recovery rather than an automatic one.
• Bug 5097113: sccli show luns/maps commands displays wrong id information. With SE 3510 RAID running 3.27T firmware, some output from the sccli>show luns command showed incorrect mapping and jumbled numeric IDs. On Solaris, data returned from the RAID controller needed to be converted from little endian to big endian numeric formats for Node Name and filter maps. For this particular issue, cli did not convert to big endian for enough filter maps.
• Bug 5104240: Statement in the document is quite incorrect. The phrase "the connective hosts must be inactive" can mean all I/O from the connected hosts must be stopped. Other documentation states that "with proper hardware and software configuration in dual-controller mode, a failed controller can be replaced while the existing controller is actively serving I/O". The difference must be reconciled.
• Bug 5105460: Diagnostic reporter stays in a discovering state. The diagnostic reporter is installed with the necessary host/agent information and the configuration saved. When the SSCS is probed using port 1270, the GUI only returns the status of discovering; it never turns to online.

---

Fixed Software Bugs

The following table contains the bugs that are fixed in Sun StorEdge CLI 1.6.2.

^{1 (TableFootnote) This manual includes instructions for the universal rack kit. To obtain the rack kit guide for older rackmount kits, refer to Sun StorEdge 3000 Family EOL Items.}

^{2 (TableFootnote) Note the limitations in Sun StorEdge Configuration Service Limitations for Sun StorEdge 3511 SATA Arrays}

^{3 (TableFootnote) See the following note about setting the data rate for this adapter to 1 GHz. This note is applicable to the Sun Enterprise 3500 server, Sun Enterprise 4500 server, Sun Enterprise 5500 server, Sun Enterprise 6500 server, and Sun Enterprise 10000 server.}

^{4 (TableFootnote) Support of this HBA is provided for Red Hat AS 2.1 and 3.0, using Qlogic's native driver.}

^{5 (TableFootnote) Support of this HBA is provided for Red Hat AS 2.1 and 3.0, using Qlogic's native driver.}

^{6 (TableFootnote) Support of this HBA is provided for Solaris x86 9 Update 6, using Emulex's native driver available on www.emulex.com.}

^{7 (TableFootnote) For the Sun StorEdge 3511 SATA array, only channels 0 and 1 are capable of supporting 1-Gb connection methods.}

^{8 (TableFootnote) For the Sun StorEdge 3511 SATA array, only channels 0 and 1 are capable of supporting 1-Gb connection methods.}

Sun StorEdge 3510 FC Array and Sun StorEdge 3511 SATA Array Release Notes

817-6597-11

Copyright © 2004, Sun Microsystems, Inc. All rights reserved.