Sun Storage 3310 Array
 

GCS>Sun Microsystems>Sun Alert>Criteria Category>Data Loss
 
GCS>Sun Microsystems>Sun Alert>Release Phase>Resolved
 

When attempting a hot-swap operation on a Sun StorEdge 3310 Controller with firmware 3.66, the automated firmware cross-load function may not complete properly. The settings may not get transferred correctly, and the new controller would be unusable. Access to data on logical disks assigned would be adversely affected, and may result in data corruption.

This issue can occur on the following platform: 

• Sun StorEdge 3310 controller with firmware 3.66

Note: This issue is only seen where a SCSI RAID controller FRU with 3.66 firmware is inserted in a dual RAID controller 3310 as a replacement in a hot-swap operation.

Replacement of a dual controller for the SE 3310 in this situation could have one of the following results:

(1) the new controller would not cross-load:

    Primary controller serial number: 4710
   Redundancy mode: Active-Active
   Redundancy status: Scanning
   Secondary controller serial number: 0

2) the new controller would not cross-load, but may work:

    Primary controller serial number: 4710
   Redundancy mode: Active-Active
    Redundancy status: Enabled
    Secondary controller serial number: 0   

(3) the new controller would cross-load, and may even work, but after about 10 minutes the server will panic because of an issue on a filesystem belonging to the new controller's LUN:

    alloccgblk: can't find blk in cyl, pos:0, i:253, fs:/bb bno: 0

Single Controller Environment:

This issue does not affect the Single Controller units, as 3.66 firmware is not supported. The current procedure in a single RAID controller environment is to downgrade the firmware to 3.25, and has already been documented.

Dual Controller Environment:

The following scenario assumes that the 3310 has one surviving controller, and the end user received a RAID controller with 3.66 BEFORE THE FIX HAS BEEN PUT IN PLACE. Also, a serial port connection is required to set the IP address in order to perform this procedure out of band:

1. Stop all I/O to the array and unmount any filesystems or volumes mounted from the array
2. Power off the RAID enclosure unit
3. Remove the surviving RAID controller (physically pull out the RAID controller)
4. Insert the FRU RAID controller
5. Connect the serial port
6. Power ON the unit and wait until it is initialized
7. Set the IP address of the FRU to the desired number
8. Power up the host (the host does not have to be physically connected to the RAID unit, as this is being done out of band)
9. Invoke sccli out of band (<sccli> <IP Address>)
10. Execute "reset nvram" (This resets the NVRAM structure)
11. Execute "reset controller" (This resets the controller, and ensures a proper NVRAM reset)
12. Remove the FRU RAID controller
13. Insert the original surviving RAID controller
14. Make sure original RAID controller initializes
15. Manually insert the FRU RAID controller

The manufacturing process to remedy this issue for 3310 controllers has been completed. In rare cases where existing systems may experience this issue, please see the "Workaround" section above for the resolution to this issue.

12-Jul-2006:

• Updated Resolution section
• State: Resolved.

The root cause of the issue is the difference in the NVRAM structure between 3.25 and 3.66 firmware. Since the RAID controllers were downloaded from 4.11 to 3.66, a manual step was required to reset the NVRAM and reset the controllers prior to shipment. Unfortunately this was not done properly but in now corrected.

Note: A purge has been issued for all 3310 controller FRU's to resolve the problem with the corrupt firmware. The purge is now completed.

This solution has no attachment