HP C5683A Surestore DAT40, backup to DDS-2 works, DDS-4 gives I/O error

[Marino Meloni_1]

I had a look at the ticket,
most of the errors are related to the tape or to the drive head, not sure if these errors are caused by the tape itself or by the drive.
I would like you run the assesment test using a known good tape (new one is best) and at the end the test should give the answer if the drive is good or not.
Related to the use of DDS2 tapes for a long time on new drives, this can cause some kind of profiling on the read/write head, causing the drive to be unable to use higher density tapes.
There was in the past a recalibration script available, but using it may cause the drive to not be able to use the DDS2 drive anympre in addition to not use the DDS4.
The only strange thing from your thread is that you report that using another DDS4 drive you get the same issue, did you try to attach them to another HBA with different OS and see how it run? every communication goes through drivers, so a old or wrong drive can cause potentially communication issues, and this can cause unpredictible results

[evdsanden]

Hi Marino,

I repeated the test with a complete new tape and that test went OK. The previous "new" tapes I used, I tried to use them previously on an other DDS4 tape drive, looks like that drive ruined my tapes or is there a way to reformat the tapes so they can be used with this tapedrive ?

[Marino Meloni_1]

If you cannot use them with LTT, i doubd you can reformat them.
Depending how they are damaged, you may try to degaus them and see if you can reuse again

[Richard Thomson_1]

I was Senior German Engineer for Tech-Support at Veritas Enterprise Tech-Support and I used to deal with at least 20 of these calls per week.

The main reason for the I/O error is that the tape drive has probably been configured for SCSI ID six (6). There is a known issue with configuring it to this ID and the source can be found in the c't Magazine, vol 18 from 1998 page 193.

If you reconfigure your drive to SCSI ID five (5) then that will sort it.

The problem relates to the introduction of SCAM - "SCSI Configured AutoMagically" by Adaptec.

Also if your 2940U2W is an onboard solution then that would account for the SCSI sense ID 9 and 11 errors you are getting.

[Marino Meloni_1]

Hi Richard
reading the support ticket attached to the thread:

Tape Drive at address (0.5.0[0-/dev/sg0])

that was ok, aslo because if you have a scsi id conflict you cannot see the device at all

Regards

Marino

[Richard Thomson_1]

QUOTE
aslo because if you have a scsi id conflict you cannot see the device at all
UNQUOTE

My post did not in any way shape or form refer to a SCSI ID conflict.

Even in the case of an apparent "SCSI ID conflict" then one might be dealing with something like a Surestore DAT 40*6 which has two SCSI devices on the same ID but on separate LUNs.

Here is the Technote I personally wrote because I got sick of customers telling me that HP engineers were on-site and that the other number could NOT be seven because that was what the SCSI adapter is on - read the acknowledgement:

http://seer.entsupport.symantec.com/docs/231508.htm

Now it would be nice if you could share the ticket so that I could resolve the problem as I did back then, because I can guarantee it will take me longer to write the solution than to think about it.