E6300 - SCSI Port error on ARCserve 9 backup 2

[half2]

I've installed a copy of ARCserve 9 on a Win 2000 server more often than not when I run a backup, it fails and gives me this error:

E6300 Windows NT SCSI Port error [ABSL:2060 CMD:Ah NT:45Dh 1117]

Any suggestions?

 

[suckit]

Have you licensed the product, if not then try to get a trial code and do it.

Activate the tape log and check out whether the problem is with the software or with the hardware.....

Try testing a NT backup on the hardware....

 

[half2]

The problem is intermittant. About a quarter to a third of the time I run a backup, I can get a full backup. The other times it will start the backup and then quit part way through.

I licensed the product as soon as I installed it. I checked the tape log and it also comes up with an E3719 error, which indicates a hardware error. This error says that the media may not be positioned correctly or the heads may need cleaning. I've tried cleaning the heads and putting in new tapes and the problem comes back, but again, not always.

Per your suggestion, I tried to run an NT backup, but apparently the ARCserve program has captured the tape drive and I can't get the NT backup to run.

I'm going to try to reset all the boards and cables when the server is not in use. Any other suggestions?

Thanks!

 

[ACiDelic]

By reading the error message it looks like you are getting error 1117. You can verify this by turning on tape engine debug tracing (using the server admin tool) and verifying the error message in the trace.

If you are getting error 1117, then the problem most likely lies within your hardware or the operating system (not ARCserve). 1117 means "The request could not be performed because of an I/O device error." It is an indication that the operating system cannot communicate with the device. Likely suspects are the cable, terminator, operating system configuration, etc. Once you fix the hardware problem, ARCserve should no longer report the SCSI errors.

Be sure to turn off the tape engine tracing after you fix the problem. It may impair performance.

Good luck!

 

[smeek]

I had some similar errors with AS2000 on a Compaq server. I reseated all cables. Updated server BIOS with SupportPaqs. Updated software driver and such to finally get rid of issue. It was weird because backups worked for a year with no issue, then suddenly they started. Seemed to be gone now.

 

[dudenjersey]

We just had the same issue, after checking the cables I had completely shutdown the library then powered it back on.

Fixed the problem.

 

[half2]

Thank you ACiDelic and smeek! I ended up reseating the board and also moved the connections on the SCSI cable. Tried reseating the board first with no solution. Then I tried reseating the SCSI connections in the same ports on the cable and it still wouldn't work. Only when I moved the SCSI connections did it work. Haven't had a problem since. Thanks for the tips!

 

[webnetwiz]

I had the same problem, went as far as replacing one of the tape drives (it's a multi-drive unit), and swapping a SCSI controller. The problem turned out to be a bad SCSI cable. Wierd.

 

[nh39]

Hello,

We just got a similar error message today:
"E6300 Windows NT SCSI PORT Error [ABSL:3000 CMD:0h] SCSI Command Retry."
Here we run ARCServe 6.61 on NT 4.0 and the tape drive is HP Auto Loader DLT 818. It happened right after the backup job on Friday finished. The activity log for the jobs on Saturday and Sunday has nothing but full of the mentioned error message. Now the tape that was supposed to be used for the Saturday job has been stuck in the drive and can't be unloaded. First of all, I'm trying to unload the tape, and then, fix the whole problem. Please help!!!

Thank you.

 

[smeek]

Sometimes if you restart the server, the OS releases the access to the tape drive. Then you can eject tape.

HP makes a Tools Library that yopu can download and update firmware and such for your unit.

Steve

 

[rabowsm1]

We had this error on several hundreds of servers. All E6300 events in the arcserve.log. I had contact with Arcserve and they told me it was a conflict between the Compaq Storage Agents and the SCSI driver of the machine.
For us the solution was to stop the Compaq Storage Agent (together with its dependent services). It works like a charm!
However, I now understand that Compaq/HP has released a SCSI driver which should also correct the problem (version 5.24 I believe it was).
So I suggest you first stop the Storage Agent to verify whether that helps. If so, try the new SCSI driver.

And be sure to post the results here

Good luck
Maurits

 

[Dito74]

I'm using BAB 11.1 and Update Device 4 (I also have 5 but I can't install it). windows 2000 SP$ + Rollup 1

Every latest Windows Updates. The drive is a DELL PV122T (VS80).

It worked for a long time until few weeks ago. Our CA support expired and I'm wasting time tryin to get the renewal PO signed..... the issue:

Now the job starts and backs up the first 2 nodes in the job repeatly.... 1-2-1-2-1-2 and it never ends... I try to modify the job and change the priority order, btu still 1st node, 2nd node, 1st node, 2nd node, etc...

I called DELL and I ran test on the Tape drive.. seems good.
I was hoping that Device Update 5 would fix the issue, but I can't get this patch installed (the button NEXT is greyed out and I can't seem to keep going thru the install wizard).

What's next ? There aren't error in the log... the sessions stop and start a new one with a new number...
sometimes I get
E6300 10/19/2005 05:11:16 PM 5000 Windows NT SCSI PORT Error

 

[sandyboy]

Hi,

Windows scsi port error might occure due to the scsi bus timeouts.
A SCSI bus timeout occurs when either the SCSI controller or the SCSI device detects that a command has not been responded to within a specific timeout period. Normally, commands are issued by the SCSI controller, which then waits for a response from the device being addressed. If no response is detected, the controller may reset the bus to reinitiate communication. While disk drives normally recover well from SCSI bus timeouts and resets, tape drives have much greater difficulty in doing so.

Normally, these timeout values are large enough to accommodate any delay, including retries, in executing the specific command being attempted. In the event that the device does not respond in the amount of time indicated by the timeout value, a timeout occurs.Usually, the first indication of a timeout is that the tape drive ceases activity. However, because some operations can take several hours on some tape drives, some timeout values are very long, which can make it seem as if the program itself has stopped responding, or that there is an application error of some kind

try these ones:
=================
check configuration on the SCSI controller.

Set the tape drive SCSI ID as low as possible, avoiding 0 or 1, which are usually reserved for bootable devices

Set INITIATE WIDE NEGOTIATION to off for controllers with a wide bus

Set INITIATE SYNC NEGOTIATION for the ID of the tape drive to off
WARNING: The Parity Checking adjustment is for diagnostic use only and should never be left disabled during production backups

Recommendations:

1. Check for firmware and driver updates from controller and tape drive vendors

2. Use good quality cabling that follows the SCSI specification

3. Use heavy duty shielded cables for external cables. An external SCSI cable should never be detached from any connection while power is still applied to any device on the bus.

4. For single-ended internal cables, ensure that there is at least 1 foot of cable between devices. For single-ended buses, ensure that the overall cable length from termination to termination does not exceed the maximum bus length of 3 meters (roughly 9 to 10 feet)

5. Use active termination on both ends of the SCSI bus. All external devices should be set to supply termination power.

6. Make sure that no two SCSI devices are sharing the same SCSI ID

7. Verify that there are no mirrored, duplexed, striped, or any other RAID configurations on the same SCSI bus that the tape drive is on

8. Do not use SCSI RAID controllers for tape devices

9. Clean the tape drive. Refer to manufacturer's procedures for cleaning the tape drive.

10. Verify that the manufacturer of the tape drive supports the tape brand being used

11. Verify that the tape device and SCSI controller are supported by CA for Windows Servers

12. Apply all the patches from CA to have the latest build
and make sure that windows drivers for the drive is disabled and removable storage service is disabled in the control panel


Set MAXIMUM SYNC TRANSFER RATE to the slowest possible setting

DISCONNECT must be enabled for all tape drive SCSI IDs
Set SCSI PARITY CHECKING to off

Last resort:

1. Put the tape device on a separate controller by itself

2. Have the media replaced

3. Have the tape drive replaced

4. Replace the controller that the tape drive is connected to

5. Try another PCI slot on the motherboard

Good Luck!!!
Cheers