DLT1 corrupt Product ID

[Diane Lanthier]

I have been having problems with our DLT1 Surestore hanging in a Pending state when it tries to run a restore job.

We use the Veritas software so I went through a bunch of technotes troubleshooting from that angle to no avail, so I decided to go at it from the Hardware angle.

I downloaded the Storageworks Library and Tape Tools and ran that hoping to upgrade the firmware and run any other utilities on it. The program is recognizing the drive but I get error messages at every corner.

Since pictures speak louder then words, attached is a word document (in a ZIP file to minimize it's size) documenting the steps I went through.

It seems the problem may be with a corrupt product ID(?)

Does anyone have any idea how to fix a corrupt Product ID?

TIA
Diane Lanthier

[JohnWRuffo · Accepted solution]

Diane:

If you have the L&TT loaded you can generate a support ticket with your errors. You can add the notes to the effect that you need to set the ID on the drive. They can give you a password to accomplish this. Send off that e-mail and the guru's at HP get get you fixed up!

G'luck

[Diane Lanthier]

Thanks for that info!
I was wondering what exactly that submit ticket thing was (guess I should have read the instructions!)
Thanks for the help, it is greatly appreciated.
Diane

[David Ruska]

LTT is going into restricted mode, because it thinks it is product it may support, but the product ID is corrupted. Some products have downloadable product IDs stored in NVRAM or battery-backed-up RAM. Occasionally those IDs can get corrupted.

LTT goes into the restricted mode with the firmware update tool enabled to allow selection of any firmware file (since it doesn't really know what the right file is). The firmware tool also has a mode to 'update the product ID' which sends a write buffer with the product ID in the firmware file.

Now in your case this probably won't help much, because I don't believe the DLT1 drive has a downloadable product ID (aka Inquiry string). The ID is hard-coded in the firmware.

So, why does your product have a corrupted ID? You most likely have a hardware problem on the SCSI bus, such as a bent pin, loose connection, bad terminator, incorrect termination, too much cable length, etc.

If you can, send the eventlog.ltt file (in the logs folder of LTT) to ltt_team@hp.com, and we can look at the ID the product is returning. None of your screenshots showed what the ID was.

Regards,
Dave
HP LTT Team

[Diane Lanthier]

There is no way the SCSI could have a bent pin, loose connection or other such problem as that as the device has not been touched, moved or changed since I have been at this company. (about a year and a half)

I know nothing about SCSI,(I'm just the IT contact for our office, it's not a job I was hired for but was dropped in my lap when the IT guy left) Can a SCSI terminator can go bad over time?

In the meantime I will send that eventlog file shortly. Thank you very much for your help Dave.

Diane

[Diane Lanthier]

Dave, the event log and other info should be on the way to ltt_team@hp.com as we speak.
Thank you for the help,
Diane

[David Ruska]

> There is no way the SCSI could have a bent pin, loose connection or other such problem as that as the device has not been touched, moved or changed since I have been at this company...

I would agree.

> Can a SCSI terminator can go bad over time?

Yes, but unlikely.

> Dave, the event log and other info should be on the way to ltt_team@hp.com as we speak.

I recieved the support ticket and the resultlog (showing the results of firmware update attempts).

I'm not sure where LTT would have reported a corrupt product ID (the clues to that would be in the eventlog and eventlog_backup files in the logs folder).

The support ticket shows the drive is responding with the correct inquiry string (aka product ID): "BNCHMARK DLT1"

The big clue to your problems is contained in the support ticket:

2.1 Tape at address (2.5.0)
Vendor ID : BNCHMARK
Product ID : DLT1
Firmware Revision : V024
Controller Serial # : 0000029626
SCSI Test Unit Ready returns a check condition
SCSI Info : 0x04 0x4084 (Reportable POST failure)

The drive is reporting that it failed Power On Self Test (Post). In that state it cannot update firmware nor do much of anything.

I suppose it's possible that the self test failure has something to do with the SCSI chip, and that could have caused a corrupt product ID to be reported. If you can zip up the eventlog files (from the logs folder) and sent them to ltt_team@hp.com, we could investigate (we're always looking to improve the LTT program).

Bottom line on your drive is that it has a fatal hardware problem causing it to fail self test. Report that to the call center. Hopefully your drive is still under warranty.

[Diane Lanthier]

Hi Dave,

Thanks for running through that for me, the only good way to learn this crap is by experience!

I was kind of fearing everything was pointing to a hardware problem, but fortunately it is still under warranty till 5/2003.

If I can't get in this weekend, I will get back into work on Monday, zip up the eventlog files (I saw where they were earlier today) and call the call center with all this info and find out what they next step is.

thank you so much for your help!
Diane

[Diane Lanthier]

>I suppose it's possible that the self test failure has something to do with the SCSI chip, and that could have caused a corrupt product ID to be reported.

Just curious, is the SCSI chip IN the device?

Thanks,
Diane

[David Ruska]

You're welcome. I hope you meant to say "under warranty till 5/2004".

> Just curious, is the SCSI chip IN the device?

Yes, the SCSI chip is wired to the rear connectors, and it manages the communication (and data transfer) between the device and the host. It's not a replaceable part (e.g. is part of the controller board).

[David Ruska]

> I hope you meant to say "under warranty till 5/2004".

Here's a website to check your warranty status:
https://partsdirect.hp.com/epdo/Warranty/View_Warranty_Verification.asp

(use the info from the product label - usually on the rear or bottom of product)

[Diane Lanthier]

Oh yes, I did mean 5/2004, it is still under warranty. (thank goodness for small favors).

And while I have you on the line, can you tell me once I get the device repaired or get a replacement, will it just be a matter of plugging it in again or will there be re-configuration that needs to be done with the SCSI configuration? Will the HP call center be able to help me with that?

Well, I'm going to call them now anyway so I guess I'll ask them. Thanks for all your help.

Diane

[David Ruska]

> And while I have you on the line, can you tell me once I get the device repaired or get a replacement, will it just be a matter of plugging it in again or will there be re-configuration that needs to be done with the SCSI configuration?

All you need to do is record the SCSI ID setting off the back (should be a numbered switch), and set the new one to match.

> Will the HP call center be able to help me with that?

I'm sure they could as well.

[Diane Lanthier]

As it turns out, step one is going to be to replace the SCSI controller as the BOZO that installed this device in the first place (before my time here) used the wrong one.

That is beyond my realm of expertise and this is our main server so there is no way I'm going to LEARN on this one. I've got an email in to our main IT department in Miami (I'm in Orlando, about 4 hours apart) to see how they want to proceed.

So it is now out of my hands. I replied to the email you sent directly to me and sent you a ZIP file containing all the error logs I got through the LTT, let me know if you don't get that and I'll attach it here.

Nevermind, I'll just do that anyway. So here they are. Thanks again Dave, you have been a great help.

Diane

[David Ruska]

Thanks Diane, those were the right logs. It looks like the device has been reporting the power on self test error all along (since first running LTT).

[Diane Lanthier]

I only started running the LTT when I first posted to this forum Dec. 29, so the problem was already there then.

It really started a couple weeks back when I was getting an error message through Veritas saying that it was not able to verify at the end of the backup, my main job is working on the projects at work, and I had too many deadlines to deal with the backup drive then but it was still backing up OK.

When I finally got a chance to look at it I thought it was a software problem, or something I didn't have configured correctly. I was trying to troubleshoot through Veritas to no avail, it was soon thereafter that it started going directly into a Pending state. I did further troubleshooting through Veritas and eventually led me here.