scsi tape error

[Jiann-Ming Su]

I keep getting the following error message:

scsi3:0:2:0: Attempting to queue an ABORT message
scsi3: Dumping Card State in Command phase, at SEQADDR 0x14d
ACCUM = 0x80, SINDEX = 0xac, DINDEX = 0xc0, ARG_2 = 0x0
HCNT = 0x0 SCBPTR = 0x0
SCSISEQ = 0x12, SBLKCTL = 0x2
 DFCNTRL = 0x4, DFSTATUS = 0x6d
LASTPHASE = 0x80, SCSISIGI = 0x84, SXFRCTL0 = 0xa8
SSTAT0 = 0x7, SSTAT1 = 0x2
STACK == 0x188, 0x147, 0x0, 0x37
SCB count = 4
Kernel NEXTQSCB = 2
Card NEXTQSCB = 2
QINFIFO entries:
Waiting Queue entries:
Disconnected Queue entries:
QOUTFIFO entries:
Sequencer Free SCB List: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
Sequencer SCB Info: 0(c 0x48, s 0x27, l 0, t 0x3) 1(c 0x0, s 0xff, l
255, t 0xff


                                    ) 2(c 0x0, s 0xff, l 255, t 0xff)
3(c 0x0, s 0xff, l 255, t 0xff) 4(c 0x0, s 0xf



f, l 255, t 0xff) 5(c 0x0, s 0xff, l 255, t 0xff) 6(c 0x0, s 0xff, l
255, t 0xff


                                    ) 7(c 0x0, s 0xff, l 255, t 0xff)
8(c 0x0, s 0xff, l 255, t 0xff) 9(c 0x0, s 0xf



f, l 255, t 0xff) 10(c 0x0, s 0xff, l 255, t 0xff) 11(c 0x0, s 0xff, l
255, t 0x


                                  ff) 12(c 0x0, s 0xff, l 255, t 0xff)
13(c 0x0, s 0xff, l 255, t 0xff) 14(c 0x0,


                                                                    s
0xff, l 255, t 0xff) 15(c 0x0, s 0xff, l 255, t 0xff)
Pending list: 3(c 0x48, s 0x27, l 0)
Kernel Free SCB list: 1 0
Untagged Q(2): 3
DevQ(0:2:0): 0 waiting
scsi3:0:2:0: Device is active, asserting ATN
Recovery code sleeping
(scsi3:A:2:0): Abort Message Sent
(scsi3:A:2:0): SCB 3 - Abort Completed.
Recovery SCB completes
Recovery code awake
aic7xxx_abort returns 0x2002
scsi2:0:1:0: Attempting to queue an ABORT message
scsi2: Dumping Card State in Command phase, at SEQADDR 0x14d
ACCUM = 0x80, SINDEX = 0xac, DINDEX = 0xc0, ARG_2 = 0x0
HCNT = 0x0 SCBPTR = 0x0
SCSISEQ = 0x12, SBLKCTL = 0x2
 DFCNTRL = 0x4, DFSTATUS = 0x6d
LASTPHASE = 0x80, SCSISIGI = 0x84, SXFRCTL0 = 0xa8
SSTAT0 = 0x7, SSTAT1 = 0x2
STACK == 0x188, 0x147, 0x0, 0x37
SCB count = 4
Kernel NEXTQSCB = 1
Card NEXTQSCB = 1
QINFIFO entries:
Waiting Queue entries:
Disconnected Queue entries:
QOUTFIFO entries:
Sequencer Free SCB List: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
Sequencer SCB Info: 0(c 0x48, s 0x17, l 0, t 0x2) 1(c 0x48, s 0x7, l
0, t 0xff) 2(c 0x0, s 0xff, l 255, t 0xff) 3(c 0x0, s 0xff, l 255, t
0xff) 4(c 0x0, s 0xff, l 255, t 0xff) 5(c 0x0, s 0xff, l 255, t 0xff)
6(c 0x0, s 0xff, l 255, t 0xff) 7(c 0x0, s 0xff, l 255, t 0xff) 8(c
0x0, s 0xff, l 255, t 0xff) 9(c 0x0, s 0xff, l 255, t 0xff) 10(c 0x0,
s 0xff, l 255, t 0xff) 11(c 0x0, s 0xff, l 255, t 0xff) 12(c 0x0, s
0xff, l 255, t 0xff) 13(c 0x0, s 0xff, l 255, t 0xff) 14(c 0x0, s
0xff, l 255, t 0xff) 15(c 0x0, s 0xff, l 255, t 0xff)
Pending list: 2(c 0x48, s 0x17, l 0)
Kernel Free SCB list: 3 0
Untagged Q(1): 2
DevQ(0:0:0): 0 waiting
DevQ(0:1:0): 0 waiting
scsi2:0:1:0: Device is active, asserting ATN
Recovery code sleeping
(scsi2:A:1:0): Abort Message Sent
(scsi2:A:1:0): SCB 2 - Abort Completed.
Recovery SCB completes
Recovery code awake
aic7xxx_abort returns 0x2002

This is the hardware we're running:

scsi2 : Adaptec AIC7XXX EISA/VLB/PCI SCSI HBA DRIVER, Rev 6.2.8
        <Adaptec 2944 Ultra SCSI adapter>
        aic7880: Ultra Wide Channel A, SCSI Id=7, 16/253 SCBs

scsi3 : Adaptec AIC7XXX EISA/VLB/PCI SCSI HBA DRIVER, Rev 6.2.8
        <Adaptec 2944 Ultra SCSI adapter>
        aic7880: Ultra Wide Channel A, SCSI Id=7, 16/253 SCBs

blk: queue c2caac18, I/O limit 4095Mb (mask 0xffffffff)
  Vendor: STK       Model: L80               Rev: 0211
  Type:   Medium Changer                     ANSI SCSI revision: 03
blk: queue c2caae18, I/O limit 4095Mb (mask 0xffffffff)
  Vendor: QUANTUM   Model: SDLT320           Rev: 5E5E
  Type:   Sequential-Access                  ANSI SCSI revision: 02
blk: queue f770b218, I/O limit 4095Mb (mask 0xffffffff)
  Vendor: QUANTUM   Model: SDLT320           Rev: 5353
  Type:   Sequential-Access                  ANSI SCSI revision: 02
blk: queue f76c6e18, I/O limit 4095Mb (mask 0xffffffff)

We've changed out the tape drives and terminators.  The only thing we
haven't changed are the host adapters and cables.  I thought maybe
it's a bad tape, but I wouldn't have expected a bad tape to cause scsi
kernel messages.  I can provide more info if necessary.  Thanks for
any insights.

-- 
Jiann-Ming Su
"I have to decide between two equally frightening options.
 If I wanted to do that, I'd vote." --Duckman
"The system's broke, Hank.  The election baby has peed in
the bath water.  You got to throw 'em both out."  --Dale Gribble