Asset ID:	1-71-1008295.1
Update Date:	2010-10-05
Keywords:

---

Solution Type  Technical Instruction Sure

Solution  1008295.1 :   Lun 31 disappeared on StorageTek [TM] 6130/6140 arrays  


PreviouslyPublishedAs
211358

Description
Customer running upgrades Solaris 9 patches, can no longer manage STK arrays inband with Santricity.

Steps to Follow
Symptoms:

Notice that Lun 31 (d31), the inband management Lun is no longer in format.

Look at messages:
We can see that the qla card enables Lun 31:

Oct 17 14:37:38 isdprtbp005 qla2300: [ID 157811 kern.info] hba1-SCSI-target-id-1-lun-100-enable;
Oct 17 14:37:38 isdprtbp005 qla2300: [ID 157811 kern.info] hba1-SCSI-target-id-1-lun-31-enable;
Oct 17 14:37:38 isdprtbp005 qla2300: [ID 157811 kern.info] hba1-SCSI-target-id-1-lun-30-enable;
Oct 17 14:37:38 isdprtbp005 qla2300: [ID 564312 kern.info] hba1-SCSI-target-id-0-fibre-channel-node-name="200400a0b8184f98";
Oct 17 14:37:38 isdprtbp005 qla2300: [ID 558211 kern.info] hba1-SCSI-target-id-0-fibre-channel-port-name="200400a0b8184f99";
Oct 17 14:37:38 isdprtbp005 qla2300: [ID 868424 kern.info] hba1-SCSI-target-id-0-port-id="610413";

A failure would have looked similar to this (this is Lun 109):

14:44:02 isdprtbp005 qla2300: [ID 157811 kern.info] hba1-SCSI-target-id-0-lun-109-enable;
Oct 17 14:44:02 isdprtbp005 genunix: [ID 408114 kern.info] /pci@8,600000/fibre-channel@2,1/sd@1,1f (sd494) offline
14:44:02 isdprtbp005 qla2300: [ID 157811 kern.info] hba1-SCSI-target-id-0-lun-108-enable;
Oct 17 14:44:02 isdprtbp005 qla2300: [ID 157811 kern.info] hba1-SCSI-target-id-0-lun-107-enable;

Look in patch_date.out from Sun Explorer:

drwxr-xr--   2 root     root         512 Feb 22  2006 113277-40
drwxr-xr--   2 root     root         512 Jul 22 21:57 113277-43
drwxr-xr--   2 root     other        512 Oct 15 02:24 113277-45

In this case 113277-45 is what did it. If they patchrm -45, they will roll back to -43, this is good because 113277-44 and up have this issue. In other words, if you see 113277-44 or higher, you will have the problem. They need to roll back to 113277-43   , which is the highest rev that does not have the problem.

Customer must reboot after removing the patch.

Product
Sun StorageTek 6140 Array

Internal Comments
Lun 31 disappeared on StorageTek [TM] 6130/6140 arrays

Customer must remove patch 113277-44 () or greater. Then they can reboot and access volume inband.


Here is what happened: Bug Id 6340983 ()  . Hiding UTM luns from format 
Added to Patch 113277-44 () .

Cu must go to Patch 113277-43 () .

*******************
Please track fix progress via this BugID 6485570
*Synopsis*: Lun 31 not in format after Solaris 9 update, santricity cannot reach STK inband
*******************
STK, Lun 31, inband, santricity
Previously Published As
87323

Change History
Date: 2006-10-25
User Name: 31620
Action: Approved
Comment: Publishing with new agreed title...
Subject: Re: Document moved back to Draft stage
From: Mike Soulary
Date: Wed, 25 Oct 2006 13:45:26 -0700
To: Andy MacBain
That would work for me.
Andy MacBain wrote:
So what is wrong with the new title Mike...?
Or would "Lun 31 disappeared on StorageTek [TM] 6130/6140 array" work for you...?
Let me know....
Regards,
Andy
Mike Soulary wrote:
Unfortunately, the doc is in a gray area. The issue impacts legacy STK storage, which is not on our voyager
list. The bug is due to another so called "bug fix" that was introduced to hide 6130/6140 inband management paths.
So in Voyager, I would either have to write the doc against the sd driver, wehich I cannot, we are storage. Or the
61x0 architecture (I chose 6140) which caused the bug to be introduced. We need this doc.



Attachments

This solution has no attachment