Adaptec 39320A "Card was not paused"

From: Cameron Murdoch <cam_at_macaroon.net>
Date: Sun, 16 Jan 2005 21:50:26 +0000
I am having a problem with an adaptec 39320A SCSI card accessing an 
external raid box, (JetStor III 416S).

Host computer is a Dell PowerEdge2650 with a single processor.

6-CURRENT from Saturday has the following relevant dmesg:

**snip**
Jan 16 21:13:35  kernel: ahd0: <Adaptec 39320A Ultra320 SCSI adapter> 
port 0xd800-0xd8ff,0xdc00-0xdcff mem 0xfcf02000-0xfcf03fff irq 20 at 
device 8.0 on pci1
Jan 16 21:13:35  kernel: ahd0: [GIANT-LOCKED]
Jan 16 21:13:35  kernel: aic7902: Ultra320 Wide Channel A, SCSI Id=7, 
PCI-X 101-133Mhz, 512 SCBs
Jan 16 21:13:35  kernel: ahd1: <Adaptec 39320A Ultra320 SCSI adapter> 
port 0xd000-0xd0ff,0xd400-0xd4ff mem 0xfcf00000-0xfcf01fff irq 21 at 
device 8.1 on pci1
Jan 16 21:13:35  kernel: ahd1: [GIANT-LOCKED]
Jan 16 21:13:35  kernel: aic7902: Ultra320 Wide Channel B, SCSI Id=7, 
PCI-X 101-133Mhz, 512 SCBs
**snip**
Jan 16 21:13:35  kernel: da0 at ahd0 bus 0 target 0 lun 0
Jan 16 21:13:35  kernel: da0: <JetStor Volume Set # 00 R001> Fixed 
Direct Access SCSI-3 device
Jan 16 21:13:35  kernel: da0: 320.000MB/s transfers (160.000MHz, offset 
127, 16bit), Tagged Queueing Enabled
Jan 16 21:13:35  kernel: da0: 1192092MB (2441405440 512 byte sectors: 
255H 63S/T 151970C)

Attempts to newfs a bsdlabeled slice results in the following errors:

Jan 16 21:20:21  kernel: ahd0: Recovery Initiated - Card was not paused
Jan 16 21:20:21  kernel: >>>>>>>>>>>>>>>>>> Dump Card State Begins 
<<<<<<<<<<<<<<<<<
Jan 16 21:20:21  kernel: ahd0: Dumping Card State at program address 
0x81 Mode 0x22
Jan 16 21:20:21  kernel: INTSTAT[0x0] SELOID[0x0] SELID[0x0] HS_MAILBOX[0x0]
Jan 16 21:20:21  kernel: INTCTL[0x80]:(SWTMINTMASK) SEQINTSTAT[0x0] 
SAVED_MODE[0x11]
Jan 16 21:20:21  kernel: DFFSTAT[0x33]:(CURRFIFO_NONE|FIFO0FREE|FIFO1FREE)
Jan 16 21:20:21  kernel: SCSISIGI[0x25]:(P_DATAOUT_DT|ACKI|BSYI) 
SCSIPHASE[0x0]
Jan 16 21:20:21  kernel: SCSIBUS[0x0] LASTPHASE[0x1]:(P_DATAOUT|P_BUSFREE)
Jan 16 21:20:21  kernel: SCSISEQ0[0x40]:(ENSELO) 
SCSISEQ1[0x12]:(ENAUTOATNP|ENRSELI)
Jan 16 21:20:21  kernel: SEQCTL0[0x0] SEQINTCTL[0x0] SEQ_FLAGS[0x0] 
SEQ_FLAGS2[0x0]
Jan 16 21:20:21  kernel: QFREEZE_COUNT[0x0] KERNEL_QFREEZE_COUNT[0x0] 
MK_MESSAGE_SCB[0xff00]
Jan 16 21:20:21  kernel: MK_MESSAGE_SCSIID[0xff] SSTAT0[0x10]:(SELINGO) 
SSTAT1[0x8]:(BUSFREE)
Jan 16 21:20:21  kernel: SSTAT2[0x0] SSTAT3[0x0] 
PERRDIAG[0xc0]:(HIPERR|HIZERO)
Jan 16 21:20:21  kernel: SIMODE1[0xa4]:(ENSCSIPERR|ENSCSIRST|ENSELTIMO) 
LQISTAT0[0x0]
Jan 16 21:20:21  kernel: LQISTAT1[0x0] LQISTAT2[0x80]:(PACKETIZED) 
LQOSTAT0[0x0]
Jan 16 21:20:21  kernel: LQOSTAT1[0x0] LQOSTAT2[0x40]
**snip (lots of debugging output)**

The same thing occurs in both 5.3 RELEASE and 6-CURRENT.  Newfs will 
actually finish though it takes a while, however, attempts to write to 
the resulting filesystem produce the same debugging output as above.  Is 
this a bug or is there something I need to turn off, etc?  I can provide 
the full output to anybody who is interested.

Cameron Murdoch
Received on Sun Jan 16 2005 - 20:50:34 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:38:26 UTC