E1145 Media write error - unit attention

[Pocket]

Hi,

I've got a shiny new NetWare 5.1 server that I'm trying to backup with ARCserve 7 for NetWare.

My backup starts to run and looks like it is going to finish successfully. Sometimes it will even complete a whole volume! But I always end up with it failing with the error "E1145 Media write error - unit attention".

I've tried a different tape device, a different SCSI card, a different cable, many - if not all - of the patches, and several different configuration tips. I've even tried ARCserveIT for NetWare!!! Any ideas? CA Tech Support have been very quiet about this one.

Andy

 

[yvfwc]

I haven't used AS7 but I have 18 NW5.1 servers using ARCserveIT 6.6 with no problem. Are you at NW5.1sp3? Is the tape internal or external, single or library, DAT or DLT? Are you using an Auto Pilot, Rotation or Custom job type? Have you done a multi-session tape test from the console? What brand of server & tape drive? I've had some errors that refer to media through the years and only 1 that I remember was truly the tape. The others were always SCSI controller based. A cold boot (power off) always fixed them.

With some of these anwers maybe we can figure this out.

Cheers,

Mark ;-)

 

[MarkShaw]

Andy

Whats the Tapeserver log show. Any SCSI errors?. What type of drive ?. (DAT, DLT?)
We had problems with DEC TZ88 firmware D887 (I think!). Not compatible. Check the device compatbility list.

We also have TZ89 and Quantum DLT7000 and have various odd messages. Have also had problems with bad (?) batches of DLT tapes. Had to scrap a whole batch of 30 tapes (30 x £50 !!) recently as they kept pulling the leader tapes off or disconnecting the drive spool leader. We thought this was Arcserve at first!.

The tapeserver log usually points you in the right direction

Cheers

Mark

 

[LolaRed]

If you're using SCSI, don't forget that terminator!

Try a full erase on a tape (will take a couple of hours) before you do a backup.

Also, remember to power down, power up your tape drive (if it's external) after you try some changes. It may need it.

 

[Pocket]

Thanks for all the ideas and suggestions.

I'm running NetWare 5.1 SP3A. The box is a Dell PowerEdge 2500, with an Adaptec 29160 SCSI card and an external HP SureStore DAT 40x6. Both ARCserve and HP's websites show the device as compatible and we've run it without problems on other boxes, including a PE2500.

We're using brand new HP DDS-4 tapes. The device is correctly terminated (or at least is terminated in an identical fashion to all the other SureStores we have, which all work fine!). It doesn't matter what type of job we use; they all have the same problem.

The tapeserver log shows the error "E6039 Power on reset occurred (29 00) Usually OK -" and nothing else. We've tried several different power cables and two different power supplies, as well as trying another device as mentioned earlier. We've also tried a different SCSI card and cable.

Aaagghh!!

Thanks again,

Andy

 

[TheLad]

I would suggest putting your whole system (server and DAT)on UPS if it is not already. We had an issue where we were getting the same error in the tape log and it was caused by a power fluctuation

 

[aamaddog]

In the ARCserve installation what kind of driver you has select where ASPI SCSI MANAGER or NWPA Driver Interface or something else.

Use NWPA Driver Interface.
Load in the startup.ncf the Controller driver at first place.

You can install this device support patch too.

http://support.ca.com/Download/patches/asnw7/QO01135.html

Let me know about it works or not.

greetings

MAD

 

[MarkShaw]

Pocket,

Also, I had one recently where I had strange problems with a DLT drive. This turned out to be due to Plug-In-And-Pray PCI bus auto-assigning IRQ 11 which was conflicting with the Adaptect SCSI card. Sometimes it worked, sometimes not.

Another strage one was £95 out-of-the-box SCSI cables ordered by the dept., 2 of which failed then, on trying the 3rd one I found that this one worked. (return to sender!).

Try loading SBACKUP and do some basic ops which access the drive. Check out for any SCSI errors. If you are still getting them then its either a duff SCSI subsystem or maybe a low level NLM.

Regards

Mark

 

[Pocket]

Thanks again for everyone's tips.

We've finally found the problem. We were using an Adaptec 29160 Ultra160 SCSI card in both servers that were having the issue. I've swapped this out for an Adpatec 2940U2W card and have now run three successful backups in a row, which is definitely a first!

Interestingly, the 29160 card also seemed to be causing lockups and hangs on the server. The server would usually come back from these after a lengthy pause. Adaptec's recommendations on specifying the SCSI ID and LUN port when loading the driver didn't work with v16.00 of their driver, which we had downloaded from the website. However, it did work with the Novell 5.1 SP3 driver (v11.00), and this seemed to resolve the lockups. Unfortunately, it didn't resolve the E1145 errors, which persisted until we went back to the older board.

Andy

 

[Pocket]

I know I'm answering my own question here, which I'm sure is bad etiquette. But I thought you might be interested to know the final resolution, having all been so helpful.

Having read thoroughly through the system documentation of my Dell PowerEdge 2500, I've discovered it has three different types of PCI slots. I moved my Adaptec 29160 card from a 64-bit, 66 MHz PCI slot to a 64-bit, 33 MHz slot and - hey presto! - it's working. Strangely, the older 2940U2W card works just fine in the faster slots.

The sickening thing is that one of the first things I tried was changing the slots of the SCSI card. All I did was move it from 64-bit/66 to 64-bit/66 though. Just one slot higher and I could have saved hours of work...

Pocket

 

[yvfwc]

Thanks for the report..Those "If only I..." & "That's the only thing I didn't check/change..." always come back & bite! Good follow through!

Cheers,

Mark ;-)

 

[MattOP]

There also an article on Compaq's site saying that one of their Drives has a firmware bug that causes the same error.