StorageTek SL150 Modular Tape Library
 

PLA-Support>Sun Systems>TAPE>Tape Hardware>SN-TP: SL150 Library
 

In this Document

Symptoms

Changes

Cause

Solution

References

Oracle Confidential PARTNER - Available to partners (SUN).
Reason: Confidential for Service Personnel

Applies to:

Symptoms

Drive Reset Issues. 

Want to make sure that everyone is aware of what to look for and what engineering needs to find the root cause of these drive reset issues.

First off to verify that the customer is getting the drive reset issues, go to the warning log from the SL150 service bundle.  Below is an example of what will be seen on the drives if the customer is in fact seeing the drive reset issue on their drives. 

2015-09-07T12:23:06.188, 0.0.0.0.0, 000, VMonitor, warn, 0000, 7030, "VDriveStateChangeHandler: Port(s) got disabled! Reinitializing drive: 3"

2015-09-07T12:20:23.396, 0.0.0.0.0, 000, tti-dbg, warn, 0000, 0000, "ADT: sendPkt: Drive: 3 - Was logged out, had to renegotiate the link!"

2015-09-07T14:18:16.466, 0.0.0.0.0, 000, VMonitor, warn, 0000, 7030, "VDriveStateChangeHandler: Port(s) got disabled! Reinitializing drive: 4"

2015-09-07T14:17:08.404, 0.0.0.0.0, 000, tti-dbg, warn, 0000, 0000, "ADT: sendPkt: Drive: 4 - Was logged out, had to renegotiate the link!"

2015-09-07T15:15:56.349, 0.0.0.0.0, 000, VMonitor, warn, 0000, 7030, "VDriveStateChangeHandler: Port(s) got disabled! Reinitializing drive: 2"

2015-09-07T15:14:46.944, 0.0.0.0.0, 000, tti-dbg, warn, 0000, 0000, "ADT: sendPkt: Drive: 2 - Was logged out, had to renegotiate the link!"

Note: The drive reset issue will typically cause both the "...Was logged out, had to renegotiate link!" and "...Port(s) got disabled! Reinitializing drive..." entries in the log_warning logs. But sometimes you may just get "...Port(s) got disabled! Reinitializing drive..." entry in the log_warning logs.  If you only get "Was logged out, had to renegotiate link!" please see knowledge doc 1965374.1.

9022

DRIVE_UNSPECIFIED_FAILURE

Changes

Cause

Issue on KLD card.

Solution

If the customer is getting the drive resets on any of the drives, there are a couple workarounds that can be tried depending on the configuration that the customer is running. These workarounds are:

The first and most proven workaround is to move the customer's drives around in the library so that there is only 1 drive installed in each module. This might be limited depending on what configuration the customer has. For example if the customer has a 2 module library and only 2 drives they would install a drive in the base module and then a drive in the expansion module. An example of a configuration that the customer wouldn't be able to move drives around on would be only a base module with 2 drives.

The second workaround is to take a power supply out of the module if that module has 2 power supplies installed. So if you have a customer who's configuration doesn't allow you to move drives around and they have redundant power supplies (2 per module) then you can have them take one of the power supplies out and see if it helps with the drive reset issue. We have not seen this workaround work all the time so that is one of the reasons it is a secondary workaround. The other reason is that customers would lose their power supply redundancy.

If the work around cannot be done, the next step is to replace the drives with reworked KLD cards to resolve this issue.

For any drives that are replaced for the customer the TSC engineer whom dispatched the drives will need to put a Site Note or a Serial Number note in SPLAT for that SL150 library S/N so that others know which drives have been replaced in the library for the drive reset issue.

Here is an example of the note that should be entered into SPLAT for the SL150 library S/N:

SL150 S/N 464970G+1537SY4631 had drive resets on Drives 1, 2, 3, 4, and 5.

Drives 1, 2, 3, 4, and 5 were replaced with P/N 7321896 which has the new KLD card to fix the drive reset issue.

If Drives 1, 2, 3, 4, or 5 need to be replaced in the future please only use P/N 7321896 or higher so that the customer doesn't have drive resets again.

=================================================================================================================================

(Update 31-Jan-2016)

Here are the new P/N's that repair will be shipping out to the field spares depots that should be used to replace the customer's drive/drives that are seeing the drive reset issue:

n/a 7321896 [C] HP LTO6 8Gb FC Half Height Drive with Tray n/a
n/a 7321900 [C] HP LTO5 8Gb FC Half Height Drive with Tray, 12V Fan n/a
n/a 7321902 [C] HP LTO5 6Gb SAS Half Height Drive with Tray, 12V Fan n/a
n/a 7321903 [C] HP LTO6 6Gb SAS Half Height Drive with Tray

Note: (12-Aug, 2016)

There was an issue in repair where they didn't program the FRU ID of the KLD with the correct P/N so the drive P/N is correct with the latest 732nnnn P/N programmed but the KLD P/N would not be the new P/N of 7321732?

Only a L2 engineer would see this since this info is only found in the OdsDump.txt file and we don't report it out to SPLAT.

This solution has no attachment