I agree with Simon, work backwards from the robot.
You said you rebooted the fibre-scsi bridge, I guess this the the standard SN3300 or similar Crossroads router.
So step 1 is to power cycle or reboot the L180 assuming that is permitted.
Next log on to the FC/SCSI router, reboot it and then check that it can see the devices on the SCSI side – you’ll immediately see if it can see the robot
and drives. Bear in mind that AFAIR on the L180 (if like the L700s that we have) the robot is on a dedicated path, unlike other robots where it is a LUN presented with a drive on the same target. That means that it has its own MPC card, SCSI cable, terminator
etc all of which can fail without any effect on the drives.
Look to see which fibres and on which LUNs the devices are mapped to.
If the router can see the drives and robot then look at the fabric. Log in to the switch and check that the fibres from the router are all logged in OK,
zero the counters and check that you are not clocking errors. In the (fairly unlikely) case that the robot is presented by the router over a different FC cable to the drives, it could fail separately or be zoned wrongly.
On the server check for driver updates that may have happened – we have seen cases where a routine patch set included upgrades to the st driver that blew
away the configuration we needed. Not sure what OS you are using but worth a check of the dates on any configuration files or driver executables.
Check your LUN mapping; of course it should not have changed. But some drivers can be configured only to scan a target for consecutive LUNs from 0, if any
are missing (e.g. a dead drive) they stop scanning (saves time at boot). If the robot is presented at a LUN higher than the drives, it can go missing. On Sun, if the st.conf is not set up to scan high enough targets or LUNs they are seen by the OS but not
by sgscan. NetApps require that the lowest LUN is a drive, not the robot….many variations.
It is most likely a hardware problem, but it could just be someone walked into the cable to the MPC card. If you have the L180 GUI, go over it and check
the FSC LOG. If you have physical access to the front panel, you can do the same from there, slowly.
From: veritas-bu-bounces AT mailman.eng.auburn DOT edu
[mailto:veritas-bu-bounces AT mailman.eng.auburn DOT edu] On Behalf Of WEAVER, Simon (external)
Sent: 24 November 2010 07:22
To: Nate Sanders; Ed Wilts
Cc: VERITAS-BU AT MAILMAN.ENG.AUBURN DOT EDU
Subject: Re: [Veritas-bu] ST L180 Robot problems
Reboot the Server? Know its drastic, but I have had to power the lot down and bring up the Robot first, prior to the Server.
Is the library under any Hardware support?
S.
From: veritas-bu-bounces AT mailman.eng.auburn DOT edu
[mailto:veritas-bu-bounces AT mailman.eng.auburn DOT edu] On Behalf Of Nate Sanders
Sent: Tuesday, November 23, 2010 5:14 PM
To: Ed Wilts
Cc: VERITAS-BU AT MAILMAN.ENG.AUBURN DOT EDU
Subject: Re: [Veritas-bu] ST L180 Robot problems
Did a reboot of the library, scsi-fiber bridge and the host. still can't talk to the library with vmchange -robot_info or through the GUI. I tried adding a new robot as TLD(1) in the GUI but inventory fails with "cannot connect to robotic
software daemon (42)". bpps -a doesn't show any tld processes running.
Using robtest I AM able to connect to TLD(1) and pull drive info, but not TLD(0). Where does this leave me?
On 11/23/2010 10:47 AM, Ed Wilts wrote:
On Tue, Nov 23, 2010 at 10:39 AM, Nate Sanders <sandersn AT dmotorworks DOT com> wrote:
> root@office-backup:/usr/openv/netbackup$ netbackup start
> Rebuilding device nodes.
> Media Manager daemons started.
> NetBackup request daemon started.
> Drive index 2 is incorrect, drive name /dev/st/nh2c0t0l1 is
> incorrect, No such file or directory
> Cannot terminate tldcd: cannot connect to robotic software daemon (42)
Since yesterday NBU has suddenly lost its ability to talk to the robot.
I don't know if this is a hardware issue or a software issue. Version is
NBU 5.1MP6 so we can't call support. Library is an StorageTek L180 with
6 drives. Scan still works though and shows two drives and the library:
I'd take 2 steps before panicking, assuming that nothing else has changed in your environment.
1. Reboot your robot control host
2. Run the device configuration wizard
If neither works, then you may have a hardware problem...
An upgrade should be done but you probably already know that )
--
Nate Sanders Digital Motorworks
System Administrator (512) 692 - 1038
This message and any attachments are intended only for the use of the addressee and may contain information that is privileged and confidential. If the reader of the message is not the intended recipient or an authorized representative
of the intended recipient, you are hereby notified that any dissemination of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail and delete the message and any attachments from
your system.
This email (including any attachments) may contain confidential
and/or privileged information or information otherwise protected
from disclosure. If you are not the intended recipient, please
notify the sender immediately, do not copy this message or any
attachments and do not use it for any purpose or disclose its
content to any person, but delete this message and any attachments
from your system. Astrium disclaims any and all liability if this
email transmission was virus corrupted, altered or falsified.
-o-
Astrium Limited, Registered in England and Wales No. 2449259
Registered Office:
Gunnels Wood Road, Stevenage, Hertfordshire, SG1 2AS, England
|
