Ivie
asked on
Backup is failing, SCSI errors in event viewer
My environment is:
dual AMD 1900+ cpu, 1 Gig RAM, Tyan Thunder K7 motherboard, 3com Gig etherlink card, 3 adaptec ultra160 SCSI cards (model 31960), 3 Exabyte VXA-1 autoloader 1X15 tape libraries with 2 tape drives in each, and 1 adaptec AhA-2940U2W ultra SCSI card connected to Qualstar 4220 tape library, retrospect 6.5 and windows 2003.
The 31960 Ultra160 cards have one channel each connected to 1 exabyte autoloader. I have bought new SCSI cables that are 1M and each tape library has a terminator which is functional and attached.
The 31960 cards are where my problem lies. I am getting eventID 15 The device, \Device\Chang, is not ready for access yet and event ID 11 (source adpu160m) The driver detected a controller error on \Device\Scsi\adpu160m3 <-the 3 is any of the drives 1, 2 or 3 but not a consistent drive.
Here is what I have tried and it is still failing:
1. updated the 31960 cards to the latest bios (if I remember correctly it is 3.1)
2. in the SCSI bios, I set the transfer rate to 80 to match my drives
3. changed the cabling so that all are connected with 1M new cables
4. checked for new drivers (I am running windows 2003 and the latest is on the cd)
5. took out the AHA-2940U2W and one of the 31960 cards and connected the libraries to independant channels on the 2 31960s that are still in the system and removed the gig ethernet card---still NO luck so I put the Gig etherlink card back but left the other 2 cards out of the system
6. set the exabyte SCSI IDs to point to the library first IE each exabyte library is set so that the library is SCSI ID 3, tape drive 1 is SCSI ID 4 and tape drive 2 is SCSI ID 5
7. I have also tried setting the transfer rate to 10, but the results were the same as it was at 80 so I set it back to 80.
8. installed the latest motherboard bios version 2.14
9. disabled the windows 2003 device driver for the exabyte drives (as suggested by exabyte support)-at least I am not getting SCSI errors on qic157 anymore after this.
10. changed the config on the exabyte drives to 7 which makes the libraries report exb-210 instead of spectra215 (got the same errors so set it back to the default of spectr-215).
The ONLY thing I feel like I haven't done is install the ASPI from adaptec (mainly because I didn't know how that would affect my system running windows 2003 when adaptec is advertising the ASPI for windows 2000 but not for windows 2003).
If anyone has had this kind of problem and has any information, please help!
dual AMD 1900+ cpu, 1 Gig RAM, Tyan Thunder K7 motherboard, 3com Gig etherlink card, 3 adaptec ultra160 SCSI cards (model 31960), 3 Exabyte VXA-1 autoloader 1X15 tape libraries with 2 tape drives in each, and 1 adaptec AhA-2940U2W ultra SCSI card connected to Qualstar 4220 tape library, retrospect 6.5 and windows 2003.
The 31960 Ultra160 cards have one channel each connected to 1 exabyte autoloader. I have bought new SCSI cables that are 1M and each tape library has a terminator which is functional and attached.
The 31960 cards are where my problem lies. I am getting eventID 15 The device, \Device\Chang, is not ready for access yet and event ID 11 (source adpu160m) The driver detected a controller error on \Device\Scsi\adpu160m3 <-the 3 is any of the drives 1, 2 or 3 but not a consistent drive.
Here is what I have tried and it is still failing:
1. updated the 31960 cards to the latest bios (if I remember correctly it is 3.1)
2. in the SCSI bios, I set the transfer rate to 80 to match my drives
3. changed the cabling so that all are connected with 1M new cables
4. checked for new drivers (I am running windows 2003 and the latest is on the cd)
5. took out the AHA-2940U2W and one of the 31960 cards and connected the libraries to independant channels on the 2 31960s that are still in the system and removed the gig ethernet card---still NO luck so I put the Gig etherlink card back but left the other 2 cards out of the system
6. set the exabyte SCSI IDs to point to the library first IE each exabyte library is set so that the library is SCSI ID 3, tape drive 1 is SCSI ID 4 and tape drive 2 is SCSI ID 5
7. I have also tried setting the transfer rate to 10, but the results were the same as it was at 80 so I set it back to 80.
8. installed the latest motherboard bios version 2.14
9. disabled the windows 2003 device driver for the exabyte drives (as suggested by exabyte support)-at least I am not getting SCSI errors on qic157 anymore after this.
10. changed the config on the exabyte drives to 7 which makes the libraries report exb-210 instead of spectra215 (got the same errors so set it back to the default of spectr-215).
The ONLY thing I feel like I haven't done is install the ASPI from adaptec (mainly because I didn't know how that would affect my system running windows 2003 when adaptec is advertising the ASPI for windows 2000 but not for windows 2003).
If anyone has had this kind of problem and has any information, please help!
I would definitely take a look at the exabyte library and drive switch settings. Make sure they match your type of environment and operating system. It's possible that they are set for a different enviornment.
Off hand I can not think of anything that you have not tried, and can not imagine that ASPI would help.
I say time to check to see if it is caused by the application. If the application is not communicating correctly with the device it can send a command that times out and produces the error. Try a different application, either load the OS drivers and try windows backup, or get a live trial of Backup Exec or ARCserve. If the other application works then get with Retrospect support.
Question is does Restrospect use tape device drivers. If it does then windows backup or Backup Exec are a good choice since they do. You want a program the communicates to the device in the same way to have a fair test. They if it works you can tell Retrospect support hey this functions the same way and it works. If Retrospect does not use drivers then use ARCserve. The ARCserve Tape Engine sends SCSI commands to the tape device instead of to a driver. Because of this the Tape Engine debug log has a record of the SCSI level communication and can be very instrumental in troubleshooting these type of problems.
The best way is not practical but for what it is worth, the best way is to get an engineer in with a SCSI analizer.
I say time to check to see if it is caused by the application. If the application is not communicating correctly with the device it can send a command that times out and produces the error. Try a different application, either load the OS drivers and try windows backup, or get a live trial of Backup Exec or ARCserve. If the other application works then get with Retrospect support.
Question is does Restrospect use tape device drivers. If it does then windows backup or Backup Exec are a good choice since they do. You want a program the communicates to the device in the same way to have a fair test. They if it works you can tell Retrospect support hey this functions the same way and it works. If Retrospect does not use drivers then use ARCserve. The ARCserve Tape Engine sends SCSI commands to the tape device instead of to a driver. Because of this the Tape Engine debug log has a record of the SCSI level communication and can be very instrumental in troubleshooting these type of problems.
The best way is not practical but for what it is worth, the best way is to get an engineer in with a SCSI analizer.
ASKER
I have tried ArcServe 2000. Unfortunately, I still had SCSI errors in the event viewer that paused backup :( Retrospect doesn't use the windows drivers so hopefully ArcServe was a good test.
I have also rebuilt the machine to make sure that ArcServe didn't leave any unwanteds and reinstalled Retrospect.
I have worked with Exabyte to make sure the emulation on the tape drives is correct for my software (both with ArcServe and Retrospect).
I have also rebuilt the machine to make sure that ArcServe didn't leave any unwanteds and reinstalled Retrospect.
I have worked with Exabyte to make sure the emulation on the tape drives is correct for my software (both with ArcServe and Retrospect).
At what point do the errors happen?
For example do they only happen while data is being written to tape?
or
Do they happen at most any time such as when a tape is being loaded, written to, or read?
For example do they only happen while data is being written to tape?
or
Do they happen at most any time such as when a tape is being loaded, written to, or read?
ASKER
The errors occur regularly at 2 times, one at initialization during system boot and when the tapes are being written (never do they occur when loading, I haven't got any data to test read)
More info:
The most likely cause of SCSI errors is Retrospect nor ArcServe can't see my autoloader (library) when the SCSI bios is set to ASYN which this device should be ASYN. The operating system sees the library in device manager no matter the setting (ie SYNC, ultrawide or ASYN no ultrawide) but the software does not see the library when it is set to ASYN with wide negotation set to yes or no (tried it both ways). So, to use the library, the communications is set wrong in the SCSI bios (IE 80 sync and I've tried 10 sync which is the lowest setting for sync in my scsi bios) which I now am sure is what is causing the SCSI errors.
My configuration is set to ASYN right now and there are no errors on intialization at system boot, but I cannot see the library in retrospect or ArcServe and since both send raw SCSI commands to the library perhaps there is something I am missing on the library itself. I talked with exabyte tech support and they verifyed that the library is set to SCSI interface mode.
(Auxillary info: in retrospect, I see the library only under the enviroment tab, but without it showing in the status tab, I cannot manipulate any tapes).
So I am at a loss right now. Can anyone think of something I have missed? (In order to troubleshoot I changed my hardware configuration to a bare minimal by removing all pci cards but 1 adaptec 31960 and I have only 1 exabyte autoloader 1X15 connected)
More info:
The most likely cause of SCSI errors is Retrospect nor ArcServe can't see my autoloader (library) when the SCSI bios is set to ASYN which this device should be ASYN. The operating system sees the library in device manager no matter the setting (ie SYNC, ultrawide or ASYN no ultrawide) but the software does not see the library when it is set to ASYN with wide negotation set to yes or no (tried it both ways). So, to use the library, the communications is set wrong in the SCSI bios (IE 80 sync and I've tried 10 sync which is the lowest setting for sync in my scsi bios) which I now am sure is what is causing the SCSI errors.
My configuration is set to ASYN right now and there are no errors on intialization at system boot, but I cannot see the library in retrospect or ArcServe and since both send raw SCSI commands to the library perhaps there is something I am missing on the library itself. I talked with exabyte tech support and they verifyed that the library is set to SCSI interface mode.
(Auxillary info: in retrospect, I see the library only under the enviroment tab, but without it showing in the status tab, I cannot manipulate any tapes).
So I am at a loss right now. Can anyone think of something I have missed? (In order to troubleshoot I changed my hardware configuration to a bare minimal by removing all pci cards but 1 adaptec 31960 and I have only 1 exabyte autoloader 1X15 connected)
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
After a few more iterations, I think I have solved the problem. (I will be convinced after a month of reliable backups). To resolve the problems, I removed the 31960 cards and replaced them with aha-2940u2w cards. For some reason, the 31960s kept giving me errors and stopping the backup. Everything I had read on the internet said that these cards were compatiable with legacy systems (tape libraries are 2 years old and are considered legacy, wow it is amazing what we are doing with technology). But it was my experience that these cards (no matter how they are set in the SCSI bios) are NOT compatible with the VXA-1 Autoloader tape libraries.
ASKER
dovidmichel Thank you very much for your help/advice. I really needed a second opinion to remind me that I was still sane.