SUN72G SAS drives refuse to be mpxio'ed

"James Noyes (SunManagers)" <[email protected]> Tue, 12 Nov 2013 10:42:19 -0700
Newsgroups gmane.os.solaris.managers
Message-ID <[email protected]>
Fellow Managers:

I've used mpxio with great success for many years, with both FC and  
SAS storage.  I've never had a problem making it do what I need it to  
do, until now.  I typically use mpxio globally, even when the storage  
is single-pathed, so that the drive identifier is tied to the drive,  
not to its physical location.  Now all of a sudden, I've run into a  
batch of drives that - for whatever reason - simply REFUSE to let the  
scsi_vhci module bind to them.

System is a T5220 running Solaris 10 1/13, with latest Recommended  
patches.  I have a mixture of 72G, 146G, and 300G SAS 2.5" drives  
available to use.  All of the drives are Sun-labeled and Sun-firmwared  
drives.  Some are Seagate, some Fujitsu, a couple are Hitachi OEM -  
but all genuine Sun parts.

The 146G and 300G drives all do what's expected.  With mpxio enabled,  
they all appear as their respective device using their WWN as the  
target (e.g., /dev/dsk/c5t5000500fd38b9278d0 and so on).  Under  
"cfgadm -al", the devices show as a "disk-path" type: (c1::2,0   
disk-path  connected  configured  unknown).  "mpathadm list lu" shows  
the devices, even though the total/operational path counts are both 1.  
  So far, so good.

But the 72G drives are a different story.  No matter WHAT I do, these  
drives always show up as the typical cXtXdX devices.  "cfgadm -al"  
shows them differently as well - as "disk" type: (c1::dsk/c1t3d0  disk  
  connected  configured  unknown).  Even if I explicitly add the  
sometimes-necessary "device-type-scsi-options" and "symmetric-options"  
parameters to scsi_vhci.conf to force multipathing, the system seems  
to simply ignore it.  "mpathadm list lu" shows no trace of them.

What is it about these drives?  I'm pretty sure I haven't missed  
anything in the mpxio configuration, since all the other drives work  
as expected.  Is it something in their firmware?  Something about them  
physically?  Why won't the scsi_vhci driver attach/take control of  
them?  I'd like to use them, but I'd like to have consistent behavior  
with the rest of the drives if I do.

I welcome any suggestions/comments/questions.
-- 
Cheers,
James Noyes
([email protected])