Windows XP backup "Looking for backup devices" very slow

[Jonathan Sachs]

I'm using a 24GB DAT drive (C1537A) with an Adaptec 2910 and Windows XP. When I start Windows Backup, I get a message box which says, "Looking for backup devices." This box
remains open for anything from a fraction of a second to several minutes. Then the backup program's normal window opens and everything proceeds normally.

While the message box is open, there is no entry for the backup program on the taskbar. Also, the message box itself has no "OK" or "Cancel" button, and no Close box in the upper right corner, so there is no way I can close the box.

Before I migrated to Windows XP I used the same drive, cable and terminator with Windows 2000 for over two years, and never had this problem. Thus it seems to be a Windows XP issue, but I got a runaround when I tried to get advice in one of Microsoft's support forums.

[meloni]

1- this HBA has never been tested with DAT24
2- Does the dat appear at boot time?
3- does the DAT appear in device manager?
4- have you downloaded the tape drivers from HP
5- have you tried with differents drivers for the HBA?

You can also try to run L&TT to isolate the problem

[Jonathan Sachs]

Thank you for trying to help, but much of your response is unclear.

1. What is an HBA?

2. I assume you mean, does the DAT appear at boot time in the SCSI controller's list of devices? There is no list, because the 2910 does not have a BIOS. It is not intended to support bootable devices.

3. Does the DAT appear in the device manager? -- yes.

4. Have I downloaded the tape drivers from HP? -- Iâ m not sure what drivers youâ re talking about. Windows NT/2000/XP has had built-in device support for HP DAT drives for as long as I can remember.

5. Have I tried different drivers for the HBA? -- may become clear when you respond to 1 a

[meloni]

HBA is the scsi controller (Host Bus Adapter),
and the drivers for the tape may be downloaded from HP site:
http://h20000.www2.hp.com/bizsupport/TechSupport/DriverDownload.jsp?locale=en_US&pnameOID=12188&taskId=135&prodTypeId=12169&prodSeriesId=42846〈=en&cc=us&swEnvOID=228#840.
I had no problem within XP with my DAT 24, so it may be you changed somthing in the config? check for bad connection, bend pin, bad terminator, Running L&TT is a good way to identify problems

[Jonathan Sachs]

I will look at the drivers soon (probably next weekend) and see if they help.

"Maybe you changed something in the config" -- again, I'm not sure what configuration you're referring to, but I think I can answer with confidence that I did not. Under Windows XP this process is essentially plug-and-play; I did not change anything, because I did not have to set anything. Now, maybe THAT is the problem -- I need to change something and did not.

What is L&TT? If it is a useful diagnostic tool, I would like to try it as well.

I should add that I have actually used this drive with two different Windows XP systems, having completely different types of SCSI controllers, and both exhibited exactly the same problem. The other one was a Dell laptop, with software installed and configured by Dell, using an Adaptec USB2-to-SCSI converter.

[CA843380]

Hi Jonathan,

LTT (Library and Tape Tools) is the diagnostic and support tool we provide to customers for testing, diagnosing and debugging our tape products. It also includes the ability to update firmware and generate support tickets.

It is available via hp.com, I have posted a link for you below for the winxp version.

http://h20000.www2.hp.com/bizsupport/TechSupport/DriverDownload.jsp?pnameOID=21421&locale=en_US&taskId=135&prodTypeId=12169&prodSeriesId=42863&swEnvOID=228

By all means generate a support ticket, zip it up and post here here if you need further help debugging your issue.

Cheers,

Dave Dewar

[Jonathan Sachs]

I installed the HP device driver and tried it. It works. I cannot say whether it works better or not.

Before I installed the driver, Windows Backup resumed exhibiting the "Searching for devices..." message for only a couple of seconds instead of several minutes. With the new driver, it still does so. That problem has started and stopped spontaneously in the past. If it ever recurs, I'll be able to say that the new driver didn't help. If it doesn't, I won't. This is, of course, totally inconclusive and rather frustrating.

After I posted my first message, but before I had a chance to install the new driver, Windows Backup began exhibiting a new bad habit: taking over ten times as long to verify a backup as to create one. The extra time is distributed evenly over the entire backup set, and is not associated with any verification errors, so I don't think the drive is struggling with a bad tape or a dirty recording head. With the new driver, this behavior continues.

I installed the LTT utility. It told me that my firmware was out of date, and I would have to update it before I could test the drive. I did so successfully, but when the update was complete, the utility reported a fatal error when I tried to select the drive after re-scanning the devices. I tried all of the corrective measures suggested by the error message, including the last resort of a reboot, but nothing helped. I do not think I tried this operation before replacing the firmware, so I cannot say whether installing the new firmware caused it, or merely failed to correct it. As far as I can tell, the tape drive is still operational with Windows Backup.

Dave: in your last message you invited me to create a trouble ticket and post it here if I still have problems. I looked up that process in the LTT help file, and learned that "When a support ticket is generated, L&TT collects configuration information and executes a Device Analysis test on the selected device." Since my most immediate problem is that LTT blows up when I try to select a device in order to execute a device analysis test, this poses certain difficulties. If you can give me any further advice, I will welcome it.

[CA843380]

Hi Jonathan,

Have you tried the drive on windows backup since trying to upgrade firmware via LTT? I am concerned that you might have had an error during firmware download that has caused firmware corruption and this might explain why LTT can no longer talk to the drive.

Also, we have had some issues reported with LTT 3.5, our latest release which we are investigating, I would recommend you uninstall LTT3.5 if that is the version you have and reinstall version 3.4sr1 from link below and see if you get better results.

http://h20000.www2.hp.com/bizsupport/TechSupport/DriverDownload.jsp?locale=en_US&pnameOID=21419&taskId=135&prodTypeId=12169&prodSeriesId=42863&submit.y=9&submit.x=7〈=en&cc=us&swEnvOID=228

Let me know how you get on and ill do my best to help you.

Cheers,

Dave Dewar

[Jonathan Sachs]

I tried making a backup, and it was successful. The verifying operation now takes about the same amount of time as the backup.

It appears that the new driver has solved the verifying problem, and perhaps it will prevent the "Looking for devices..." problem from recurring.

I will try to find time to check out the older LTT utility next weekend. If I can do so, I will report here.

[Jonathan Sachs]

When I ran a backup today the tape drive returned to its prior habit of verifying very slowly. It took about 15 minutes to create the backup, and somewhat over two hours to verify it. The "Looking for devices..." problem did not return, though.

I loaded the earlier version of LT&T without incident. When I started it, it told me that new scripts were available; I allowed it to load its default selection.

I was not sure which tests I should run, if any, before producing the support ticket. I tried running the DDS Acceptance Test, but after asking me to load a data tape, it began asking me to load a cleaning tape over and over. The fifth or sixth time it asked me, I killed it. There appeared to be no clean way to terminate the test.

I restarted the program and looked at the log. I ran a Device Analysis Test, which was successful but gave warnings. The warnings told me that I should "please insert a cleaning cartridge 5 times in a row." I doubt that would be useful, and I'm skeptical that it's even relevant, since I just did so in the previous, abortive DDS Acceptance Test. It also told me that "You have media errors logged on your drive -- please replace your media." I am skeptical about that too, since this test never asked me to load media. Perhaps it is reporting information from the previous DDS Acceptance Test. However, the media I used in that test was a high-quality brand (Fujifilm) and had been used only once before, so I'm skeptical that it has failed.

I ran a Device Analysis test, a Read/Write Test, and a Device Self Test, all of which were successful. I was particularly interested in the speed of the read phase in the Read/Write Test, in view of the very slow verify operation, but it appeared to go just as fast as the write phase.

After that I generated a support ticket, which is attached. I hope all of this will make sense to you; it did not make much sense to me!

[CA843380]

Hi Jonathan,

The acceptance test will ask for a cleaning tape 5 times before moving on to the write/read portion of the test. It does this to make sure that the heads are clean. Debris is not always removed with a single clean pass, hence the repeated cleans. The test messaging could probably be better in this respect.

The drive stores quite alot of information in non volatile storage (EEPROM) about its usage history, errors logged etc etc, it is this information that is used by the device analysis and acceptance test routines to make decisions about recommendations to users about "next steps".

Your drive has logged an error relating to read recently and this is why the device analysis script is asking you to clean the drive and check your media. These things quite often address the issue for customers, but maybe not in your case.

Your "searching for devices" issue and your "slow verify issue" I think are separate problems. As a final check to this did you see the "searching for devices" issue with a tape loaded? Or was it not dependent on this?

I suspect your drive is having problems reading sometimes, hence the delay to verify written data. This could be media or drive related. Unfortunately, I cannot see the read error rates in you support ticket so I cannot be sure since there is no cartridge present. You mentioned you have run the write/read test successively, did you turn on the "everything setting" in test results? this should give you access to the error rates measured.

The other thing that might be causing slow verify is actually system related. NTbackup does the verify operation in software and so this will require processor time, if you have alot of other apps running during the verify then this can slow things down, however a 2 hour verify on a 15min backup time sounds extremely excessive for this to be the cause.

[Jonathan Sachs]

>The acceptance test will ask for a cleaning tape 5 times before moving on...
>The test messaging could probably be better in this respect.

Indeed it could. I understand what the test was doing now, but with no explanation, it gave every appearance of being caught in an endless loop. I think it took unusual patience (or stubbornness) to continue to insert the tape after the third prompt.

>Your "searching for devices" issue and your "slow verify issue" I think are separate problems.
>As a final check to this did you see the "searching for devices" issue with a tape loaded?

I did not check this yesterday, but I have experimented with it in the past. As far as I can tell, the "searching for devices" problem is/was unrelated to whether there is a tape in the drive or not.

>You mentioned you have run the write/read test successively, did you turn on
>the "everything setting" in test results?

I reran the test, but did not see an "everything setting." The ???Options" box listed about ten different options which I could change individually. I enabled "Phase 2&3," which was the only option that clearly expanded the scope of the test. Another ticket is attached to this message. (Later -- I found "everything" in the support ticket box itself, and selected that.)

>The other thing that might be causing slow verify is...
>if you have alot of other apps running during the verify then this can slow things down...

Not an issue. I _never_ use other applications while a backup/verify is running, and I usually shut them down completely. This seems to be the only way to avoid incomplete backups due to files that are locked by applications, and false verify errors caused by files that have been chang

[CA843380]

Hi,

I'll feedback your comments to the LTT team on the messaging in this part of the acceptance test.

Ok, to summarise the issue you are currently seeing, your issue is "intermittment slow verify performance on NTbackup", current cause unknown, is it tape independent?

By "test results" and "everything" I mean the test results tab that you can select after running the write/read test and the "current detail setting" = everything. If you run the test, click on the test results tab and select "current detail level" = "everything" on the pull down this will allow you to expand the operation log and see what error rate the drive is reporting on both writes and reads. Let me know what values you see here, I would expect something much less than 5x10-2 on both A and B channels. Let me know what values you have here.

Unfortunately, the error rate information is not persistent in this vintage of DDS drive, (DDS4 and later drives log alot more information in non volatile storage) and so on DDS3 as soon as the tape is unloaded the error rate logs are cleared and the support ticket info for this is cleared.

For future reference, you dont need to adjust the detail level before generating a support ticket. All levels of information are generated in a support ticket anyway and can be viewed using the LTT ticket viewer in LTT.

Cheers,

Dave Dewar

[Jonathan Sachs]

I'm sorry it took me so long to reply; for some reason the server didn't notify me that you had replied.

I ran a test as you suggested, using a new tape. I got these results:

Write error counters: groups written 547, RAW retries 987, group rewrites 0, hard errors 0.

Read error counters: groups read 546, C3 invocations 466, group rewrites 466, hard errors 0.

I'm also attaching a copy of the new ticket.

[Jonathan Sachs]

It has been over two weeks since my last post here. Have you received any answers or suggestions to give me? If not, do you have any idea how soon you will?

The slow verify continues to be a major nuisance for me, occasionally escalating to an intolerable obstacle. I would seriously consider replacing the tape drive at this point if I could afford to do so. For the present I can't afford that, so I'm stuck with a problem that is both unacceptable and unsolveable.

[CA843380]

Hi Jonathan,

Apologies for the delay in replying to you. I have been away and have also had difficulties opening your particular thread in the forum, very odd.

Anyway, thanks for the support ticket. The data you have listed suggests your drive is having to do rewrites and rereads and maybe thats your problem. However without the error rate information from the test results log of the write/read test its difficult to be sure.

You could try doing a recal and see if that addresses your issue

Do the following:
From LTT, select Utilities and run script. Browse the script folder for a file called ddsWriteRecal.ssc. Run this script on you drive to see if it helps recalibrate the read write head.

Then repeat your backup and see if your slow verify goes away.

Cheers,

Dave Dewar

[Jonathan Sachs]

I tried running ddsWriteRecal, and it displayed the following message:

Warning: This script should only be run under the supervision of an HP Support Engineer. There is a risk that your drive may be damaged beyond repair if the procedure is not followed correctly. Check the documentation under..."

That sounds scary. Before I proceed with it, do you have any cautions or reassurances for me?

[Jonathan Sachs]

An additional note: I went to the support area which the message recommended (www.hp.com/support/dat, selected "DAT 24 Tape Drives," then "Troubleshoot a problem"), but I couldn't find any information about recalibrating a drive.

[CA843380]

Hi Jonathan,

The recal script basically tries to optimise the write current settings for best error rate performance. This can help on drives that have had significant usage and/or mixed media usage. As long as you follow the instructions is should not be detrimental to your drive.

Your drive has seen significant usage and is logging write and read retries and so this might help.

Not having seen the error rate data from the write/read test, I can't be sure if this will help you. My assumption is that you have already discounted media or dirty heads as a probable cause.

If you could rerun the write/read test with a new piece of media that would indicate writing performance currently. Look at the test results tab, within "current detail setting" set to everything you can see the bit error rate info on writes and read and post it here. Look in the window and expand out the test results and look for write and read frame counters. Expand this out and look for the positive and negative channel bit error rates.

Cheers,

Dave Dewar

[Jonathan Sachs]

>Not having seen the error rate data from the write/read test,
>I can't be sure if this will help you...

It's been a while now since will last time I created a ticket, but I recall that I specified the greatest possible level of detail. If the error rate data was not in that ticket, I do not yet know how to capture it. What must I do that I have not already done?

>If you could rerun the write/read test with a new piece of media
>that would indicate writing performance currently.

If by "new piece of media" you mean a tape that has never been used, I can't -- I do not have any more on hand. But I have been using DAT drives for about 10 years, and never had a tape go bad until this problem started; now the drive is performing miserably with most or all of the tapes I try. I ruled out the possibility that the tape is at fault on that basis.

[CA843380]

Hi Jonathan,

I am not refering to the support ticket when I talk about error rate data when running the write/read test.

When you select "test" button in LTT you get the option to run various tests on the drive, you must have used this before to run write/read tests.

Window on bottom right has 2 tabs, "test execution" where you select unit and select and start a test to run and 2nd tab is "test results" where you can display the results of the test.

Select and run the write/read test and when it is completed select the test results tab, select current detail level pulldown to "everything" and navigate the bottom right window +'s to display the error rate data on write and read pass.

Secondly, if you have been using the same tapes for 10 years I would be concerned that they are finally wearing out. I don't know how many passes you have been putting on each tape. Your drive log history indicates a total of 553 DDS3 tape loads and 50 DDS1 tape loads. IF you only have 5 tapes, then that is over 100 backups each minimum, maybe alot more if you have been doing backups with autoeject turned off so media stays in drive for next backup.

Media cause could be a factor here, but if it is happending on all media then its unlikely its all worn out at same time as you rightly point out.

Cheers,

Dave Dewar

[Jonathan Sachs]

Thanks for the additional instructions. I will follow them ASAP (next weekend latest) and post the results.

Regarding tapes, you misinterpreted my previous message. I said I have been using DAT tapes for over ten years -- not the same DAT tapes. I bought my current DDS3 drive about two years ago, so none of my current tapes are older than that.

My backup procedure is, essentially, to run a full backup at the start of each month, and differential backups throughout the month. Each month's differentials are appended to one tape (not the one used to make the full backup). I rotate the tapes on an annual basis. Thus, given the fact that I do not back up every day, each of my tapes is used at most about a dozen times a year. At the moment I have 21 active tapes and roughly a dozen spares.

I like this system because it gives me protection against accidental deletion and change as well as catastrophe. Any file I have had in the last year can be retrieved in a form that is at most three or four days older than a given "target date." In 15 years of using PCs I have had only one system catastrophe that required a complete restore, but I resort to my historical backups several times a year.

[CA843380]

Hi,

Ok, let me know how things go and thanks for clarifying the tape usage.

Cheers,

Dave

[Jonathan Sachs]

I ran the test as you requested. I think it took about 30 minutes. Here are the results:

Checked bit error rate of write channel (Current: 6.62e-002, Limit: 5.00e-001)

Checked bit error rate of read channel (Current: 2.91e-002, Limit: 5.00e-001)

Read Frame Error Counters
Total Frames Read : 27895Total Total Retry Count : 192
Number of C2 Uncorrectables : 591

Main Positive
Error Count : 0xED7F
Bit Error Rate : 1.14e-002

Main Negative
Error Count : 0x3D2A2
Bit Error Rate : 4.68e-002

Overall
Error Count : 0x4C021
Bit Error Rate : 2.91e-002

Write Frame Error Counters
Total Frames Written : 20010
Main Positive
Error Count : 0x33E0C
Bit Error Rate : 5.53e-002

Main Negative
Error Count : 0x48614
Bit Error Rate : 7.72e-002

Overall
Error Count : 0x7C420
Bit Error Rate : 6.62e-002

By the way, L&TT made this information almost impossible to copy. Click-and-drag did not work; the ^C shortcut for "copy" did not work either. I had to select each line of the report individually and copy it with the right-click menu.

[CA843380]

Hi Jonathan,

Sorry for delay, have been away for a week.

Thanks for posting your error rate data. I would recommend you perform a recal. Your write and read error rates are poor and could explain your slow verify problem.

The lack of proper cut/copy in the results windows has been noted before and is an outstanding feature to be addressed in later versions.

Let em know how you get on with the recal.

Cheers,

Dave Dewar