Problem with LUNs over Fiber

Question

We have recently installed a SAN but are having a few problems with the Solaris machines we are trying to connect to it.
Hardware: LSI SAN with dual controler and 3 trays of 6x73Gb disks. Brocade fiber switch. A Sun V880 and a Sun E420 both with LSI40919O 2gb fiber cards. Both Solaris machines have resonably upto date patch clusters on them.
I can create volumes on the SAN, create LUNs on these volumes, map them to individual hosts, and (assuming the relevant entries were in /kernel/drv/ssd.conf at boot time) I can see the LUNs when I run the 'format' command on the Solaris boxes. I can label, partition, format and mount slices from these disks.
The problems occur when I want to delete or change a mapping. When I do this (delete a mapping between a LUN and a host for instance), on the Solaris box no matter what I do the disk changes to "drive type unknown". Running devfsadm (or drvconfg; devlinks; disks) has no effect. The disk is not manually configurable (it's not there after all). Only a reboot (boot -r) will actually remove the incorrect entries.
Sample output from format:
Searching for disks...done
AVAILABLE DISK SELECTIONS:
0. c0t0d0 <SUN18G cyl 7506 alt 2 hd 19 sec 248>
/pci@1f,4000/scsi@3/sd@0,0
1. c0t1d0 <SUN18G cyl 7506 alt 2 hd 19 sec 248>
/pci@1f,4000/scsi@3/sd@1,0
2. c4t0d0 <STK-OPENstorageD178-0530 cyl 2558 alt 2 hd 64 sec 64>
/pci@1f,2000/IntraServer,fc@1/ssd@0,0
3. c4t0d1 <STK-OPENstorageD178-0530 cyl 3070 alt 2 hd 64 sec 64>
/pci@1f,2000/IntraServer,fc@1/ssd@0,1
4. c4t0d2 <STK-OPENstorageD178-0530 cyl 2046 alt 2 hd 64 sec 64>
/pci@1f,2000/IntraServer,fc@1/ssd@0,2
5. c4t0d3 <STK-OPENstorageD178-0530 cyl 1534 alt 2 hd 64 sec 64>
/pci@1f,2000/IntraServer,fc@1/ssd@0,3
6. c4t0d4 <STK-OPENstorageD178-0530 cyl 1022 alt 2 hd 64 sec 64>
/pci@1f,2000/IntraServer,fc@1/ssd@0,4
7. c4t0d5 <drive type unknown>
/pci@1f,2000/IntraServer,fc@1/ssd@0,5
It is of course the last drive for which I removed the mapping. I can remake the mapping and the drive willonce again be available. I can add additional mappings and the new disks will be available (again assuming the relevent entry existed in /kernel/drv/ssd.conf at boot time). But any attempt to remove the mappings results in the above situation.
Sean Timmins

Answer 1

Have you tried luxadm remove <your_device> ?