SCSI error causing delay in backup????

[shrikant 1]

We have got following error for path 0/12/0/1.
There are few disks connected to this path which are used for a datbase.
The database backup is getting delayed since then by almost 6 hrs.
Can anyone tell me what has happened here and what needs to be done...
======================================

May 27 22:14:35 rter3y vmunix: SCSI: Reset detected -- path: 0/12/0/1
May 27 22:14:35 rter3y vmunix: SCSI: -- lbolt: 1383676756, bus: 6
May 27 22:14:35 rter3y vmunix: lbp->state: 30008
May 27 22:14:35 rter3y vmunix: lbp->offset: ffffffff
May 27 22:14:35 rter3y vmunix:
May 27 22:14:35 rter3y vmunix: lbp->nominalOffset: 228
May 27 22:14:35 rter3y vmunix: lbp->Cmdindex: 1
May 27 22:14:35 rter3y vmunix: lbp->last_nexus_index: 0
May 27 22:14:35 rter3y vmunix: lbp->nexus_index: 1
May 27 22:14:35 rter3y vmunix: uCmdSent: 1005840 uNexus_offset: 105604
May 27 22:14:35 rter3y vmunix: last lbp->puStatus [000000004070d600]:
May 27 22:14:35 rter3y vmunix: 00030077 00030068 0003006a 00030068
May 27 22:14:35 rter3y vmunix: next lbp->puStatus [000000004070d7f0]:
May 27 22:14:35 rter3y vmunix: 0003005e 0003005e 00030077 0003005e
May 27 22:14:35 rter3y vmunix: From most recent interrupt:
May 27 22:14:35 rter3y vmunix: ISTAT: 02, SIST0: 02, SIST1: 00, DSTAT: 80, DSPS: 00000000
May 27 22:14:35 rter3y vmunix: lsp: 0x0000000000000000
May 27 22:14:35 rter3y vmunix: DSAtbl->host_iocb_index: 1
May 27 22:14:35 rter3y vmunix: DSAtbl->host_iocb_addr: 105840
May 27 22:14:35 rter3y vmunix: scratch_lsp: 0x0000000000000000
May 27 22:14:35 rter3y vmunix: c8xx_iocb [ffffffff99ffcb00]:
May 27 22:14:35 rter3y vmunix: 01005840 ff00005e 00101040 9f021f80
May 27 22:14:35 rter3y vmunix: 00000003 00105820 0000000a 00105828
May 27 22:14:35 rter3y vmunix: Pre-DSP script dump [ffffffff99ffc340]:
May 27 22:14:35 rter3y vmunix: 727f0000 00000000 f1700001 0000006c
May 27 22:14:35 rter3y vmunix: 73f00000 00000000 80840000 fffffddc
May 27 22:14:35 rter3y vmunix: Script dump [ffffffff99ffc360]:
May 27 22:14:35 rter3y vmunix: 54000000 fffffdd4 740a0f00 00000000
May 27 22:14:35 rter3y vmunix: 6a5e0000 00000000 60000400 00000000
May 27 22:14:35 rter3y vmunix: NCR chip register dump for: 0x400200a
May 27 22:14:35 rter3y vmunix: 00: SCNTL3: 9f SCNTL2: 00 SCNTL1: 00 SCNTL0: da
May 27 22:14:35 rter3y vmunix: 04: GPREG: 0b SDID: 02 SXFER: 3e SCID: 47
May 27 22:14:35 rter3y vmunix: 08: SBCL: 00 SSID: 80 SOCL: 00 SFBR: 00
May 27 22:14:35 rter3y vmunix: 0c: SSTAT2: 0a SSTAT1: 0f SSTAT0: 00 DSTAT: 80
May 27 22:14:35 rter3y vmunix: 10: DSA: 99ffcb00
May 27 22:14:35 rter3y vmunix: 14: MBOX1: 00 MBOX0: 00 ISTAT1: 00 ISTAT: 00
May 27 22:14:35 rter3y vmunix: 18: CTEST3: 01 CTEST2: 30 CTEST1: 00 CTEST0: ff
May 27 22:14:35 rter3y vmunix: 1c: TEMP: 99ffc310
May 27 22:14:35 rter3y vmunix: 20: CTEST6: 00 CTEST5: 24 CTEST4: 08 DFIFO: 00
May 27 22:14:35 rter3y vmunix: 24: DCMDDBC: 54000000
May 27 22:14:35 rter3y vmunix: 28: DNAD: 99ffc360
May 27 22:14:35 rter3y vmunix: 2c: DSP: 99ffc368
May 27 22:14:35 rter3y vmunix: 30: DSPS: fffffdd4
May 27 22:14:35 rter3y vmunix: 34: SCRATCHA: 00000077
May 27 22:14:35 rter3y vmunix: 38: DCNTL: a1 DWT: 00 DIEN: 7f DMODE: 4c
May 27 22:14:35 rter3y vmunix: 3c: ADDER: 99ffc13c
May 27 22:14:35 rter3y vmunix: 40: SIST1: 00 SIST0: 00 SIEN1: 97 SIEN0: 8f
May 27 22:14:35 rter3y vmunix: 44: GPCNTL: 2f MACNTL: 00 SWIDE: 00 SLPAR: 00
May 27 22:14:35 rter3y vmunix: 48: RESPID1: 00 RESPID0: 80 STIME1: 00 STIME0: fc
May 27 22:14:35 rter3y vmunix: 4c: STEST3: 80 STEST2: 00 STEST1: 0c STEST0: 76
May 27 22:14:35 rter3y vmunix: 50: RESV50: 00 RESV51: c0 SIDL1: 00 SIDL0: 00
May 27 22:14:35 rter3y vmunix: 54: CCNTL1: 01 CCNTL0: 01 SODL1: 00 SODL0: 00
May 27 22:14:35 rter3y vmunix: 58: RESV58: 00 RESV59: 00 SBDL1: 00 SBDL0: 00
May 27 22:14:35 rter3y vmunix: 5c: SCRATCHB: 00000000
May 27 22:14:35 rter3y vmunix: 60: SCRATCHC: c0ffffff
May 27 22:14:35 rter3y vmunix: 64: SCRATCHD: 99ffc240
May 27 22:14:35 rter3y vmunix: 68: SCRATCHE: 99ffcff4
May 27 22:14:35 rter3y vmunix: 6c: SCRATCHF: 00100f00
May 27 22:14:35 rter3y vmunix: 70: SCRATCHG: ff010301
May 27 22:14:35 rter3y vmunix: 74: SCRATCHH: 00105604
May 27 22:14:35 rter3y vmunix: 78: SCRATCHI: 09819f3e
May 27 22:14:35 rter3y vmunix: 7c: SCRATCHJ: 01005840
May 27 22:14:35 rter3y vmunix: bc: SCNTL4: 80
May 27 22:14:35 rter3y vmunix: PCI configuration register dump:
May 27 22:14:35 rter3y vmunix: Command: 0157
May 27 22:14:35 rter3y vmunix: Latency Timer: ff
May 27 22:14:35 rter3y vmunix: Cache Line Size: 10

[TTr · Accepted solution]

This type of error is in the SCSI commumication layer and not in the data itself and is not easy to pinpoint the cause. It could be the SCSI adapter or a disk drive, a cable connection, or a SCSI patch or device driver patch.

First check if you need any patches in this area (SCSI adapter, SCSI, disk etc)

Try verifying the disks one by one by causing some I/O on each disk separately and observe if this error occurs. Note that you will probably NOT find any read errors with the disk but the I/O load may make the error appear. Check the cable connections and replace it if needed. Finally you may try and replace the card or move the disk devices to another SCSI interface if you have one available.

[Jeeshan]

Normally an lbolt means a bad disk.

With an entire section(side) of the array down, I suspect a hardware problem with the array. Have the hardware people replace that part of the disk array, not the disks.

This will require downtime.

[Jeeshan]

or may be

Posbble causes:


A disk has failed
A disk is failing
A disk will fail

Back up the data if any and prepare to identify and replace the disk.

[TTr]

Usually when there is a disk device failing, the lbolt errors are followed by disk device error entries such as the ones in

http://forums12.itrc.hp.com/service/forums/questionanswer.do?threadId=1238312