Sun Microsystems, Inc.  Oracle System Handbook - ISO 7.0 May 2018 Internal/Partner Edition
   Home | Current Systems | Former STK Products | EOL Systems | Components | General Info | Search | Feedback

Asset ID: 1-72-1390586.1
Update Date:2017-09-21
Keywords:

Solution Type  Problem Resolution Sure

Solution  1390586.1 :   SL8500/SL3000 - Robots Went Offline After "Robot Reach Not Safe" Errors During Put Operations  


Related Items
  • Sun StorageTek SL3000 Modular Library System
  •  
  • Sun StorageTek SL8500 Modular Library System
  •  
Related Categories
  • PLA-Support>Sun Systems>TAPE>Tape Hardware>SN-TP: SL3000-8500 Library
  •  




In this Document
Symptoms
Changes
Cause
Solution


Oracle Confidential PARTNER - Available to partners (SUN).
Reason: For tape support engineers reference

Applies to:

Sun StorageTek SL3000 Modular Library System - Version Not Applicable to Not Applicable [Release N/A]
Sun StorageTek SL8500 Modular Library System - Version Not Applicable to Not Applicable [Release N/A]
Information in this document applies to any platform.

Symptoms

More than one robot went offline after each one experienced a "Robot reach not safe" error during a put operation


The following sequence of error messages can be observed with regards to the failed robot:

2011-12-26T06:56:20
.778, 1.3.0.1.0, root, hli0, move, 8280401, error, 3955, "Error from device Code: 506 - Robot reach not safe", Data=<response sequence="200060"
final="true"><command>putCartridge</command><result identifier="1"><resultStatus><resultSeverity>error</resultSeverity><resultCode>5069</resultCode><resultText><!|CDATA|cmo_user_put: Retry Performed 5611; cmo_eval_op_state, Reach Not Safe: SENSORS; servo mech reach event 5069 at 3925 tachs, 4829 mils||></resultText><operationalState>506</operationalState></resultStatus><address>1,3,2,1,0</address></result></response>

2011-12-26T06:56:20.831, 1.0.0.0.0, root, hli0, move, 8280401, warn, 3420, "Invalid SCSI library state changed attemptedFrom Inoperative by robotOffline PLI",
2011-12-26T06:56:20.853, 1.0.0.0.0, root, hli0, move, 8280401, info, 3908, "Hli LSM is not ready", hliLsm=2

2011-12-26T06:56:20.934, 1.3.0.1.0, root, hli0, move, 8280401, error, 1302, "Failure from robot Code: 506 - Robot reach not safe", Data:=<response sequence="200060" final="true"><command>putCartridge</command><result identifier="1"><resultStatus><resultSeverity>error</resultSeverity><resultCode>5069</resultCode><resultText><!|CDATA|cmo_user_put: Retry Performed 5611; cmo_eval_op_state, Reach Not Safe: SENSORS; servo mech reach event 5069 at 3925 tachs, 4829 mils||></resultText><operationalState>506</operationalState></resultStatus><address>1,3,2,1,0</address></result></response> volumeLabel=721365L4 hliLsm=2

2011-12-26T06:56:21.048, 1.3.2.1.2, root, hli0, move, 8280401, error, 3955, "Error from device Code: 603 - Drive cartridge is present", Data=<response sequence="200064" final="true"><command>putComplete</command><result identifier="1"><resultStatus><resultSeverity>error</resultSeverity><resultCode>6022</resultCode><resultText><!|CDATA|drive
1,3,2,1,2: putComplete FAILED: (putFailed = true, state = cartridgePresent)||></resultText><operationalState>603</operationalState></resultStatus></result></response>


Note: A similar error pattern can also be observed with the other robots that failed
 

Changes

No known changes.   However, a lot of these drive load errors can be seen on the EWI log prior to the robots going offline:
3955 - "Error from device Code: 605 - Drive media error"
3337 - "Drive load failed due to media error - on failed load"

These errors seem to follow the tapes when the tapes are loaded onto a drive.
 

Cause

A few tapes have been found to be cracked.  These tapes are getting stuck in the throat of the drive.
When the robot tries to pull the tape from the drive, the tape is getting stuck and the robot is not letting go of the tape.    As a result, the robot gets a "reach not safe" error that caused it to be offlined by the library.
 

Solution

1. Have the field engineer inspect the drives or cells indicated in the EWI error messages.

2. Also check if there is a tape stuck in the robot's gripper and in the PTPs or elevators.

3. If there are tapes stuck in these locations, remove the tapes and do a visual inspection of the tapes.

4. Run diagnostics on the failed robots.  Replace the robot if it fails initialization.

5. Run diagnostics on the tape drives (or PTP or elevators)  with the stuck tapes. 
    Replace the tape drive if it fails the diagnostic test.

6. Give a list of possibly defective tapes to the field engineer so he can have the customer eject the tapes and
    verify with possible frozen tapes in the backup application's tape inventory.    The list of tapes can be
    obtained from SPLAT, tape support's log analysis tool.


Attachments
This solution has no attachment
  Copyright © 2018 Oracle, Inc.  All rights reserved.
 Feedback