How to troubleshoot robot communication issues in Windows

Problem

GENERAL ERROR: How to troubleshoot robot communication issues in Windows

Overview:  
"Unable to sense robotic device" or "Unable to initialize robot" errors occur during the inventory of a robot, or other operations. Drives may also appear in AVR mode within the NetBackup (tm) Device Monitor.

Error Message

Unable to sense robotic device (202)
Unable to initialize robot (204)

Cause

Troubleshooting:

These symptoms usually indicate a robot communication issue. The following are useful tools in determining the root cause.

• Event Viewer logs
  • Be sure to look at the Event Viewer System and Application logs on the NetBackup Server that is configured as the robot control host. If the System Event log indicates a communication error concerning the robot or its drives, the issue should be analyzed from a hardware perspective. Involve the hardware vendor on any errors seen for a robotic device, tape drives, SCSI adapter or HBA adapter in the Windows System Event log.
• Check the LCD panel or Web interface for the robot
  • Most robots have an LCD panel that displays the status of the robot. Observe the status of the robot by looking at this or by using a Web interface to connect the robot, if one is available from the vendor. If the robot is offline or has an error status, it may need to be rebooted. Always follow the manufacturer's recommended procedures for any error that is received from the robot itself.
• Robtest
  • The "robtest" utility in NetBackup can be used to test or diagnose robotic communication failures. Please see the NetBackup Media Manager System Administrator's Guide for more information on robtest.

Master Log Files:  N/A

Media Server Log Files:

Application Log: (Messages similar to the following may appear)

20041108 11:31:09 NetBackup TLD Control Daemon I13892 NA TLD(0) [3096] opening robotic path \\.\Scsi3: (bus 0, target 1, lun 1)
20041108 11:41:19 NetBackup TLD Control Daemon E5122 NA DeviceIoControl() error on bus 0, target 1, lun 1: The semaphore timeout period has expired.
20041211 10:56:11 NetBackup TLD Control Daemon E13943 NA DCI0050VMS2 TLD(4) Mode_sense error, CHECK CONDITION
20041211 10:58:27 NetBackup TLD Control Daemon E13942 NA DCI0050VMS2 TLD(4) key = 0x2, asc = 0x4, ascq = 0x0, LOGICAL UNIT NOT READY, CAUSE NOT REPORTABLE
20041022 09:33:12 NetBackup TLD Control Daemon E13942 NA DCI0050VMS2 TLD(0) key = 0x4, asc = 0x40, ascq = 0x1, HARDWARE ERROR, GENERAL

System log:

9/23/03 12:43:24 AM lp6nds35 Error None 9 N/A INVERS The device, \Device\ScsiPort3, did not respond within the timeout period.
5/14/04 11:31:20 PM adpu160m Error None 9 N/A DENTON The device, \Device\Scsi\, did not respond within the timeout period.

Client Log Files:  N/A

Solution

There are many causes and resolutions for robot communication issues. Here are several of the most common:

1. Ensure the robot is supported by NetBackup
   • Check the Device Compatibility list on the Veritas Support Web site to ensure that the robot is supported. If the robot is not supported, unexpected behavior may occur.
2. Ensure that the Medium Changer driver is properly loaded for the robot.
   • Ensure the Medium Changer driver has loaded successfully for the robot in the Windows Device Manager. The Medium Changer driver that Windows loads automatically for the robot is usually the best driver to use. Additional drivers, if available from the robot's vendor, are often not necessary or are meant for use outside of NetBackup. It is generally okay for a robot to detect as the default "Unknown Medium Changer" in the Windows Device Manager. If a vendor driver is being used, try reverting to the standard Microsoft driver.
3. Ensure robtest isn't already open
   • Co-incidentally, if the robtest utility in NetBackup is open and has an active connection to the robot, errors concerning the robot can occur within the NetBackup application. Be sure to exit robtest when not using it.
4. Power cycle the robot and device host
   • If the robot is unresponsive or reports errors directly, it may be necessary to power cycle the robot. The robot control host should normally be powered off along with the robot itself. When powering the host and robot back on, bring the robot online first. When it has completed its initialization, power on the robot host machine. If the robot is fiber attached and there is other SAN equipment involved between the robot and host, follow the hardware vendor's recommended power cycle procedure for the configuration. Never power off a NetBackup Server if it is involved with an active process such as a backup or restore.
5. Reconfigure the robot in NetBackup
   • If there are no errors in the System Event Log or indicated by the robot itself, the configured device path for the robot may be incorrect. In this case, it should be reconfigured. This can be done either manually or by running the Device Configuration Wizard.  Please see the NetBackup Media Manager System Administrator's Guide for assistance on configuring robots.
6. Removable Storage Manager (RSM) in Windows 2000 and 2003
   • In most configurations, the Operating System's Removable Storage Manager service is not required. In some configurations, stopping this service can resolve robot communication issues in NetBackup. Before disabling RSM, ensure that the service is not required for other unrelated purposes, such as removable hard disks.
   • Note: RSM is no longer available as of Windows Server 2008 R2.