BE 12.5 SBS Premium - Jobs fail with E00084F4 Unknown Error

[endpoint]

Hello board,

I'm using an HP Ultrium 3 Internal, with the latest firmware revision of D22D/Standalone.

This drive passes all tests successfully in Hp Tape Tools 4.7.

However all my backup jobs fail in BE 12.5, with an E00084F4 Unknown Error message.

I've attached an example job log.

Any ideas gratefully appreciated.

[Ben_L_]

Here are a few technotes that may help.

http://support.veritas.com/docs/305233

http://support.veritas.com/docs/280508

http://support.veritas.com/docs/285630

[endpoint]

Thanks for the links Ben.

In response to 285630, all entries return SCSISTAT_GOOD, along with STATUS_SUCCESS.

The drive is on SCSI ID 3 & passes every test HP Tape Tools 4.7 has to offer.

Despite not receiving the SCSISTAT_QUEUE_FULL message through Tracer.exe, I have followed steps 1, 3 & 4 within document 305233.  This now gives me a different error code during backup - E00084C8, with the tape ejecting before job completion.  Detailed information from within the job log suggests "Storage device " * " reported an error on a request to read data from media".  On looking up this error code, it appears to be linked to the verification part of the job.  I therefore ran the job again with verification turned off.  This ran through as 100% successful.

I will continue to look into why this may be occurring during verify, though any further assistance is gratefully appreciated.

[endpoint]

It would appear that this mornings successful backup job (albeit with verify turned off) was a one off.

The exact same backup job is now failing again with the E00084F4 error code.

[Larry_Fine]

If this is reproducible on a small local backup of a few files, then try using Tracer to see what the error at the low levels is.  I bet that the failing command has a check condition (but not all check conditions are bad or unexpected).  Post lines from the top pane of Tracer and we can dig from there.
http://support.veritas.com/docs/285630

[endpoint]

Thanks Larry,

Well it appears hit & miss on jobs - can fall over & give this error randomly on anything from a few Mb to 6Gb (I've not tried beyond 6Gb yet).

I've ran Tracer again this morning, & this is the first time I've seen a SCSI IO error.

Event 4, Check C 23a00, TEST_UNIT_READY
Function   SRB_FUNCTION_EXECUTE_SCSI
SRB Status   SRB_STATUS_ERROR | SRB_STATUS_QUEUE_FROZEN | SRB_STATUS_AUTOSENSE_VALID
SCSI Status   SCSISTAT_CHECK_CONDITION
Flags   SRB_FLAGS_DISABLE_SYNCH_TRANSFER
Sense Length   18
Data Length   0
Driver Result   STATUS_IO_DEVICE_ERROR

Strange though this is the first time I've seen this error through Tracer, & also the drive still passes all the tests available through HP Tape Tools 4.7.

Thanks.

[endpoint]

Windows Backup does not see the LTO3 drive at all.  The only selectable backup destinations are hard drive array partitions.

It's listed as working correctly in Device Manager.

I have also tried stopping all the Backup Exec service to see if that then made the LTO3 available for Windows Backup, but it doesn't.

[Larry_Fine]

Can you post more of the exents before and after this event?  It looks like you are dealing with a hardware issue or a SCSI cable/configuration issue that is causing intermittant problems

This may help: http://support.veritas.com/docs/255501
Double check your cable and SCSI termination.

[endpoint]

Thought I'd finally got a work round for this last week, as I managed to achieve many succesful scheduled backups one after the other.

I utilise the bemcmd -o503 & -o502 commands from the BEX program folder - this is done via 2 batch files set up in Task Manager.  The only way to get continued backups without this error was to stop/start the BEX services in between scheduled jobs.

This has now stopped working, & I'm well & truely at a frustrating halt with this now.

Tracer fully passes tests, as does HP Tape Tools - so it's not a hardware issue.

I've tried removing the device & letting it redetect, as seemed to fix it for other users, but not for me.

I have the following updates installed in my 12.5 installation:

SP2, 322898, 324947, 317436, 325647, 326004, 319242, 324012 & 323894.

With the time & effort spent on this product so far, I'm seriously thinking of ditching it for something else!!

[endpoint]

Thought I'd finally got a work round for this last week, as I managed to achieve many succesful scheduled backups one after the other.

I utilise the bemcmd -o503 & -o502 commands from the BEX program folder - this is done via 2 batch files set up in Task Manager.  The only way to get continued backups without this error was to stop/start the BEX services in between scheduled jobs.

This has now stopped working, & I'm well & truely at a frustrating halt with this now.

Tracer fully passes tests, as does HP Tape Tools - so it's not a hardware issue.

I've tried removing the device & letting it redetect, as seemed to fix it for other users, but not for me.

I have the following updates installed in my 12.5 installation:

SP2, 322898, 324947, 317436, 325647, 326004, 319242, 324012 & 323894.

With the time & effort spent on this product so far, I'm seriously thinking of ditching it for something else!!

[thegoolsby]

Can you reproduce this failure while running SGMON with Verbose Device and Media debugging enabled and get us a copy of that entire log:  support.veritas.com/docs/308975

   NOTE: Depending on how quickly this fails, the SGMON large could grow quite large so you may want to compress the file before uploading it.

Also, if you could post a copy of your adamm.log that would help as well.

Also, when you run LTT, make sure to configure the test to write around 125% of the largest backup that you've run. For example, if your largest backup you've run wrote 10 GB before it failed, configure the test to write at least 12.5 GB in its test. Make sure that test passes.