Raid Manager GUI (rm6) does not report configuration information. GUI does not allow any operations to be performed on any of the raid manager objects, such as luns, drive groups, etc..

The clue to the source of this problem is in this output of lad:

c2t4d1s0 1T83333339 LUNS: 1 3 5 7 9 11 13 14 16

c3t5d0s0 1T92000882 LUNS: 0 2 4 6 8 10 12 13 15

c4t5d0s0 1T04000497 LUNS: 0 2 4 6 8 10 12 15

c5t4d1s0 1T91700611 LUNS: 1 3 5 7 9 11 14 16

The number 16 reflects that a 17th lun was created.

The following is a excerpt of the output of Module Profile:

NOTE: There are 16 luns, 0 to 15.

Detailed LUN Information for Rack 2 Ctl A (continued)

Segment Write Cache Cache Without

LUN Size Cache Mirroring Batteries Status

(Blocks)

0 128 Enabled Enabled Disabled Optimal

1 128 Enabled Enabled Disabled Optimal

2 128 Enabled Enabled Disabled Optimal

3 128 Enabled Enabled Disabled Optimal

4 128 Enabled Enabled Disabled Optimal

5 128 Enabled Enabled Disabled Optimal

6 128 Enabled Enabled Disabled Optimal

7 128 Enabled Enabled Disabled Optimal

8 128 Enabled Enabled Disabled Optimal

9 128 Enabled Enabled Disabled Optimal

10 128 Enabled Enabled Disabled Optimal

11 128 Enabled Enabled Disabled Optimal

12 128 Enabled Enabled Disabled Optimal

13 128 Enabled Enabled Disabled Optimal

14 128 Enabled Enabled Disabled Optimal

15 128 Enabled Enabled Disabled Optimal

Customer ran the 16 lun support script and followed all procedures in the 16 lun cookbook.

Hardware configuration was correct. Module profile reported 16 luns, 0 to 15.

lad reports that there is a lun number 16. This is the only clue that 17 luns were created.

Module profile does not report 17 luns. Module Profile sees luns 0 to 15, which is 16 luns.

But the number 16 in the lad output is actually lun 17, because the basis of the count is the

numbering from 0 to 15. Therefore, lun 16 is actually lun 17 and lun 15 is actually the 16th lun

when the numbering starts from 0(zero). The customer exceeded the number of luns

allowed under his current configuration because lun 15 was used as a reference.

It is for this reason the functionality of the rm6 GUI failed.

There are a few options available to resolve this problem, and they are as follows:

1. An SSE can go out to the site and use a laptop to plug into the serial port of one of the controllers. That will allow the configuration to be seen including the 17th lun. It can be deleted. Once the 17th lun has been deleted, the rm6 GUI should be able to view lun configuration and perform all other operations on the configuration.

2. By default, only 8 luns are allowed. Unless, either the 16 or 32 lun support script and related

procedures are followed to achieve 16 or 32 luns. Creating the 9th or 17th lun, respectively, will

cause the rm6 GUI to fail. The solution in this case is to run either the 16 or 32 lun support script and follow procedures to configure the 16 or 32 lun support. This should allow the rm6 GUI to run without problems.

3. If you know exactly which disks were used to create the 9th or 17th lun, those disks can be removed and put into another machine where all data on the disk(s) can be zeroed out using dd or format the disk(s) Those disk(s) can then be put back into the array and reconfigured. This should clear the problem with the GUI.

4. The last, and least desirable solution, is to reset the Raid Manager configuration back to a single lun and recreate the configuration. This will involve a restoration from backup.

email address: leonard.schoenborn@Ebay.Sun.COM