Veritas-bu
[Top] [All Lists]
<prev [Date] next>
[Advanced]
 <prev [Thread] next>

Re: [Veritas-bu] New tape drives not appearing in /dev/rmt.

2007-12-12 12:42:56
Subject: Re: [Veritas-bu] New tape drives not appearing in /dev/rmt.
From: "Ellis, Jason" <Jason.Ellis AT imb DOT com>
To: "Peter Vines" <psv2b AT virginia DOT edu>, "Peters, Devon C" <Peters.Devon AT con-way DOT com>
Date: Wed, 12 Dec 2007 09:17:10 -0800 
I've been a bit out of practice with Solaris, but have you tried running
devfsadm or performing a reconfiguration reboot?

Failing that you could, as some suggested, rebuild your path_to_inst
file by renaming it and running 'devfsadm -r /a -p /a/etc/path_to_inst'
or 'boot -ar' and accepting all the defaults except for the path_to_inst
file.

Hope that helps.



Jason Ellis 

-----Original Message-----
From: veritas-bu-bounces AT mailman.eng.auburn DOT edu
[mailto:veritas-bu-bounces AT mailman.eng.auburn DOT edu] On Behalf Of Peter
Vines
Sent: Wednesday, December 12, 2007 7:12 AM
To: Peters, Devon C
Cc: veritas-bu AT mailman.eng.auburn DOT edu
Subject: Re: [Veritas-bu] New tape drives not appearing in /dev/rmt.

Hum, the new drives are NOT in /devices, nor in /etc/path_to_inst.

And they do appear in cfgadm.

On a Solaris 10 system, path_to_inst contains:
"/ssm@0,0/pci@19,700000/SUNW,qlc@1/fp@0,0/st@w500104f00043e256,0" 0 "st"
"/ssm@0,0/pci@19,700000/SUNW,qlc@1/fp@0,0/st@w500104f00045cbb4,0" 7 "st"
"/ssm@0,0/pci@19,700000/SUNW,qlc@1/fp@0,0/st@w500104f000438bec,0" 14
"st"
"/ssm@0,0/pci@19,700000/SUNW,qlc@1,1/fp@0,0/st@w500308c00189780b,4" 2
"st"  <<new
"/ssm@0,0/pci@19,700000/SUNW,qlc@1,1/fp@0,0/st@w500308c00189780b,3" 4
"st"  <<new
"/ssm@0,0/pci@19,600000/SUNW,qlc@2/fp@0,0/st@w500104f000438e6e,0" 15
"st"
"/ssm@0,0/pci@19,600000/SUNW,qlc@2/fp@0,0/st@w500104f000438f10,0" 16
"st"
"/ssm@0,0/pci@19,600000/SUNW,qlc@2/fp@0,0/st@w500104f000480658,0" 17
"st"
"/ssm@0,0/pci@19,600000/SUNW,qlc@2,1/fp@0,0/st@w500308c00189780a,2" 1
"st"  <<new
"/ssm@0,0/pci@19,600000/SUNW,qlc@2,1/fp@0,0/st@w500308c00189780a,1" 3
"st"  <<new

which has the 6 drives from the old tape library, and the 4 new drives.

The Solaris 8 path_to_inst has:
"/pci@5d,700000/SUNW,qlc@1/fp@0,0/st@w500104f000438e6e,0" 135 "st"
"/pci@5d,700000/SUNW,qlc@1/fp@0,0/st@w500104f000438f10,0" 136 "st"
"/pci@5d,700000/SUNW,qlc@1/fp@0,0/st@w500104f000480658,0" 137 "st"
"/pci@3c,700000/SUNW,qlc@1/fp@0,0/st@w500104f00045cbb4,0" 28 "st"
"/pci@3c,700000/SUNW,qlc@1/fp@0,0/st@w500104f000438bec,0" 29 "st"
"/pci@3c,700000/SUNW,qlc@1/fp@0,0/st@w500104f00043e256,0" 30 "st"
"/pci@3c,700000/SUNW,qlc@1/fp@0,0/st@w500104f0007c90ef,0" 126 "st"
"/pci@3c,700000/SUNW,qlc@1/fp@0,0/st@w500104f00045ccbb,0" 128 "st"
"/pci@3c,700000/SUNW,qlc@1/fp@0,0/st@w500104f0007c9602,0" 129 "st"
"/pci@3c,700000/SUNW,qlc@1/fp@0,0/st@w500104f000438e6e,0" 130 "st"
"/pci@3c,700000/SUNW,qlc@1/fp@0,0/st@w500104f000438f10,0" 133 "st"
"/pci@3c,700000/SUNW,qlc@1/fp@0,0/st@w500104f000480658,0" 134 "st"
"/pci@5c,700000/SUNW,qlc@1/fp@0,0/st@w500104f000438e6e,0" 31 "st"
"/pci@5c,700000/SUNW,qlc@1/fp@0,0/st@w500104f000438f10,0" 32 "st"
"/pci@5c,700000/SUNW,qlc@1/fp@0,0/st@w500104f000480658,0" 33 "st"
"/pci@5c,700000/SUNW,qlc@1/fp@0,0/st@w500104f000438bec,0" 127 "st"
"/pci@5c,700000/SUNW,qlc@1/fp@0,0/st@w500104f00043e256,0" 131 "st"
"/pci@5c,700000/SUNW,qlc@1/fp@0,0/st@w500104f00045cbb4,0" 132 "st"

which has the 6 drives from the old tape library, as well as entries
from tape drives that no longer exist.

Looking like an st driver issue.  I'll update my SUN issue with this
info.


Peters, Devon C wrote:
> There goes that idea...  :)
> 
> So, your HBA's can see the LUNs, and cfgadm has identified them as
tape
> devices.  It seems like it's just devfs that isn't getting updated
> correctly...  A couple other things to consider:
> 
> Are there device files for these drives under /devices?    find
/devices
> | grep st.*cbn$
> 
> Are there entries in /etc/path_to_inst for these new tape drives?
> grep st /etc/path_to_inst
> 
> If the /devices files exist, then I believe the st driver is doing
it's
> thing.  If there are no entries in path_to_inst then the devfs stuff
is
> failing, if the entries are there, then I don't know what to say...
> 
> You could try re-building path_to_inst, but Sun support would probably
> be your best bet.
> 
> -devon
> 
> -----Original Message-----
> From: Peter Vines [mailto:psv2b AT virginia DOT edu] 
> Sent: Tuesday, December 11, 2007 3:53 PM
> To: Peters, Devon C
> Cc: sean.mohr AT gmail DOT com; veritas-bu AT mailman.eng.auburn DOT edu
> Subject: Re: [Veritas-bu] New tape drives not appearing in /dev/rmt.
> 
> Thanks again for the thoughts, although I checked this earlier today.
> 
> I've got 108725-26 installed.
> -27 is the latest, pertaining to HP LTO-4 drives. 
> 
> The patch is one level down, but has the "IBM Ultrium Gen 3 LTO" in
the
> st driver.
> 
> strings /kernel/drv/st | grep IBM
> IBM     ULTRIUM-TD4
> IBM     ULT3580-TD4
> IBM     ULTRIUM-TD3
> IBM     ULT3580-TD3
> IBM     ULTRIUM-TD2
> IBM     ULT3580-TD2
> IBM     ULTRIUM-TD1
> IBM     ULT3580-TD1
> IBM Ultrium Gen 4 LTO
> IBM Ultrium Gen 4 LTO
> IBM Ultrium Gen 3 LTO
> IBM Ultrium Gen 3 LTO    <<< 
> IBM Ultrium Gen 2 LTO
> IBM Ultrium Gen 2 LTO
> IBM Ultrium LTO
> IBM Ultrium LTO 
> 
> 
> Peters, Devon C wrote:
>> Interesting...  I just noticed that you mention you're using Solaris
8
>> on this host.  Do you know if you have the st patch that provides IBM
>> LTO3 drive support?  A quick way to check is to run "strings
>> /kernel/drv/sparcv9/st | grep LTO", and see if IBM Gen 3 LTO is
> listed.
>> -devon
>>
>> -----Original Message-----
>> From: Peter Vines [mailto:psv2b AT virginia DOT edu] 
>> Sent: Tuesday, December 11, 2007 3:35 PM
>> To: Peters, Devon C
>> Cc: sean.mohr AT gmail DOT com; veritas-bu AT mailman.eng.auburn DOT edu
>> Subject: Re: [Veritas-bu] New tape drives not appearing in /dev/rmt.
>>
>> Thanks for the thought, but my st.conf already has those entries.
>>
>> name="st" class="scsi" target=0 lun=0;
>> name="st" class="scsi" target=0 lun=1;
>> name="st" class="scsi" target=0 lun=2;
>> name="st" class="scsi" target=0 lun=3;
>> name="st" class="scsi" target=0 lun=4;
>> name="st" class="scsi" target=1 lun=0;
>> name="st" class="scsi" target=1 lun=1;
>> name="st" class="scsi" target=1 lun=2;
>> name="st" class="scsi" target=1 lun=3;
>> name="st" class="scsi" target=1 lun=4;
>> ...
>> continuing through target=15.
>>
>>
>> Peters, Devon C wrote:
>>> Peter,
>>>
>>> I would guess that Sean is correct.  I don't believe the default
>> st.conf 
>>> file for Solaris 10 includes support for tape drives that aren't lun
>> 0.  
>>> From what you show below your tape drives all start after LUN 0 (1,
> 2,
>>> 3, and 4).  I'd suggest changing your st.conf entries from this:
>>>
>>> name="st" class="scsi" target=0 lun=0;
>>> name="st" class="scsi" target=1 lun=0;
>>> name="st" class="scsi" target=2 lun=0;
>>> name="st" class="scsi" target=3 lun=0;
>>> name="st" class="scsi" target=4 lun=0;
>>> name="st" class="scsi" target=5 lun=0;
>>> name="st" class="scsi" target=6 lun=0;
>>>
>>> To something like this:
>>>
>>> name="st" class="scsi" target=0 lun=0;
>>> name="st" class="scsi" target=0 lun=1;
>>> name="st" class="scsi" target=0 lun=2;
>>> name="st" class="scsi" target=0 lun=3;
>>> name="st" class="scsi" target=0 lun=4;
>>> name="st" class="scsi" target=1 lun=0;
>>> name="st" class="scsi" target=1 lun=1;
>>> name="st" class="scsi" target=1 lun=2;
>>> name="st" class="scsi" target=1 lun=3;
>>> name="st" class="scsi" target=1 lun=4;
>>> <etc...>
>>>
>>> Then run devfsadm and see if they're there.  You may have to run 
>>> "update_drv st", or reload the st driver to pickup the changes.
>>>
>>> -devon
>>>
>>> -------------------------------------
>>> Date: Mon, 10 Dec 2007 19:14:10 -0500
>>> From: "Sean Mohr" <sean.mohr AT gmail DOT com>
>>> Subject: Re: [Veritas-bu] New tape drives not appearing in /dev/rmt.
>>> To: "Peter Vines" <psv2b AT virginia DOT edu>
>>> Cc: veritas-bu AT mailman.eng.auburn DOT edu
>>> Message-ID:
>>>
<5107ccec0712101614w6e4c62afm23b1149fd3742dfe AT mail.gmail DOT com>
>>> Content-Type: text/plain; charset="iso-8859-1"
>>>
>>> Did you make sure you have /kernel/st.conf and (lpfc.conf if emulex
>> fiber
>>> attached) entries.
>>>
>>> I'm not fully up on Solaris 10 at the moment but Solaris 10 does a
> lot
>> a 
>>> new
>>> things automatically that solaris 8/9 does not.
>>>
>>> Hope this helps
>>>
>>> Sean Mohr
>>> New York Life
>>> Storage Management Team
>>>
>>>
>>> On Dec 10, 2007 6:39 PM, Peter Vines <psv2b AT virginia DOT edu> wrote:
>>>
>>>  > I recently added connectivity to a Scalar i2000 with 4 LTO3
> drives,
>> to a
>>>  > Solaris 8 server.
>>>  > I removed all the entries in /dev/rmt, reconfigure booted, went
>> through
>>>  > the sg install process, yet the server does not have entries in
>> /dev/rmt
>>>  > for the new drives.  The server is connected to two tape
> libraries:
>>>  > 1-L700 with 6 9840 drives, 2-i2000 with 4 LTO3 drives.  The L700
>> drives
>>>  > continue to be present on the system and usable.
>>>  > I've also tried devfsadm, drvconfig, tapes, etc...
>>>  >
>>>  > Why don't the entries appear in /dev/rmt?
>>>  >
>>>  > I've done the same process on multiple Solaris 10 servers,
>> connected to
>>>  > the same SAN and they all work fine.
>>>  >
>>>  > cfgadm -o show_FCP_dev -al
>>>  > c8                             fc-fabric    connected
> configured
>>>  > unknown
>>>  > c8::500308c00189780a,0         med-changer  connected
> configured
>>>  > unknown
>>>  > c8::500308c00189780a,1         tape         connected
> configured
>>>  > unknown
>>>  > c8::500308c00189780a,2         tape         connected
> configured
>>>  > unknown
>>>  > c9                             fc-fabric    connected
> configured
>>>  > unknown
>>>  > c9::500308c00189780b,0         med-changer  connected
> configured
>>>  > unknown
>>>  > c9::500308c00189780b,3         tape         connected
> configured
>>>  > unknown
>>>  > c9::500308c00189780b,4         tape         connected
> configured
>>>  > unknown
>>>  >
>>>  > sgscan
>>>  > /dev/sg/c0tw500308c00189780al0: Changer: "ADIC    Scalar i2000"
>>>  > /dev/sg/c0tw500308c00189780al1: Tape (???): "IBM     ULTRIUM-TD3"
>>>  > /dev/sg/c0tw500308c00189780al2: Tape (???): "IBM     ULTRIUM-TD3"
>>>  > /dev/sg/c0tw500308c00189780bl0: Changer: "ADIC    Scalar i2000"
>>>  > /dev/sg/c0tw500308c00189780bl3: Tape (???): "IBM     ULTRIUM-TD3"
>>>  > /dev/sg/c0tw500308c00189780bl4: Tape (???): "IBM     ULTRIUM-TD3"
>>>  > /dev/sg/c0tw500104f000438becl0: (/dev/rmt/2): "STK     9840"
>>>  > /dev/sg/c0tw500104f00043e256l0: (/dev/rmt/0): "STK     9840"
>>>  > /dev/sg/c0tw500104f00045cbb4l0: (/dev/rmt/1): "STK     9840"
>>>  > /dev/sg/c1tw500104f000438e6el0: (/dev/rmt/3): "STK     9840"
>>>  > /dev/sg/c1tw500104f000438f10l0: (/dev/rmt/4): "STK     9840"
>>>  > /dev/sg/c1tw500104f000480658l0: (/dev/rmt/5): "STK     9840"
>>>  >
>>>  >
>>>  >
>>>  > _______________________________________________
>>>  > Veritas-bu maillist  -  Veritas-bu AT mailman.eng.auburn DOT edu
>>>  > _http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu_
>>>  >
>>> -------------- next part --------------
>>> An HTML attachment was scrubbed...
>>> URL: 
>>>
>
_http://mailman.eng.auburn.edu/pipermail/veritas-bu/attachments/20071210
>> /637ebd20/attachment-0001.htm_ 

-- 
- Peter Vines : peter.vines AT virginia DOT edu : (434) 924-4644

_______________________________________________
Veritas-bu maillist  -  Veritas-bu AT mailman.eng.auburn DOT edu
http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu


_______________________________________________
Veritas-bu maillist  -  Veritas-bu AT mailman.eng.auburn DOT edu
http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu
[More with this subject...]
<Prev in Thread] Current Thread [Next in Thread>
Previous by Date:  Re: [Veritas-bu] New tape drives not appearing in /dev/rmt., Peter Vines
Next by Date:  Re: [Veritas-bu] recovery of oracle database using netbackup, Robin Small
Previous by Thread:  Re: [Veritas-bu] New tape drives not appearing in /dev/rmt., Peter Vines
Next by Thread:  Re: [Veritas-bu] New tape drives not appearing in /dev/rmt., Peter Vines
Indexes:  [Date] [Thread] [Top] [All Lists]