AIC7xxx problem

I have Adaptec SCSI controler, which with 2.4.20-ac2 boots ok:

====================================================================
scsi0 : Adaptec AIC7XXX EISA/VLB/PCI SCSI HBA DRIVER, Rev 6.2.8
<Adaptec 2940 Ultra2 SCSI adapter>
aic7890/91: Ultra2 Wide Channel A, SCSI Id=15, 32/253 SCBs

(scsi0:A:0): 80.000MB/s transfers (40.000MHz, offset 63, 16bit)
Vendor: IBM Model: DPSS-318350N Rev: S96H
Type: Direct-Access ANSI SCSI revision: 03
scsi0:A:0:0: Tagged Queuing enabled. Depth 16 Attached scsi disk sda at scsi0, channel 0, id 0, lun 0 SCSI device sda: 35843670 512-byte hdwr sectors (18352 MB) Partition check:
sda: sda1 sda2 sda3 sda4 < sda5 sda6 sda7 >
====================================================================

but performance is poor - periodically all disk operations stops for few seconds. I try to use newer drivers, but without positiver results. Here is log from boot with verbose option:

====================================================================
[...]
SCSI subsystem driver Revision: 1.00
ahc_pci:2:10:0: Reading SEEPROM...done.
ahc_pci:2:10:0: Manual LVD Termination
ahc_pci:2:10:0: BIOS eeprom is present
ahc_pci:2:10:0: Secondary High byte termination Enabled ahc_pci:2:10:0: Secondary Low byte termination Enabled ahc_pci:2:10:0: Primary Low Byte termination Enabled ahc_pci:2:10:0: Primary High Byte termination Enabled ahc_pci:2:10:0: Downloading Sequencer Program... 423 instructions downloaded ahc_pci:2:10:0: Features 0x56f6, Bugs 0x6, Flags 0x20485500 scsi0 : Adaptec AIC7XXX EISA/VLB/PCI SCSI HBA DRIVER, Rev 6.2.35
<Adaptec 2940 Ultra2 SCSI adapter>
aic7890/91: Ultra2 Wide Channel A, SCSI Id=15, 32/253 SCBs

(scsi0:A:0): 980KB/s transfers (0.980MHz, offset 255)
scsi0: target 0 using 8bit transfers (scsi0:A:0): 3.300MB/s transfers
scsi0: target 0 using asynchronous transfers (scsi0:A:1): 980KB/s transfers (0.980MHz, offset 255)
scsi0: target 1 using 8bit transfers (scsi0:A:1): 3.300MB/s transfers
scsi0: target 1 using asynchronous transfers

[...]

(scsi0:A:14): 980KB/s transfers (0.980MHz, offset 255)
scsi0: target 14 using 8bit transfers (scsi0:A:14): 3.300MB/s transfers
scsi0: target 14 using asynchronous transfers
scsi0: target 15 using 8bit transfers
scsi0: target 15 using asynchronous transfers
scsi0: target 0 using 8bit transfers
scsi0: target 0 using asynchronous transfers
scsi0: target 1 using 8bit transfers
scsi0: target 1 using asynchronous transfers

[...]

scsi0: target 12 using 8bit transfers
scsi0: target 12 using asynchronous transfers
scsi0: target 13 using 8bit transfers
scsi0: target 13 using asynchronous transfers
scsi0:0:0:0: Attempting to queue an ABORT message
CDB: 0x12 0x0 0x0 0x0 0xff 0x0
ahc_intr: HOST_MSG_LOOP bad phase 0x0
scsi0: At time of recovery, card was paused

scsi0: Dumping Card State while idle, at SEQADDR 0x45
Card was paused
ACCUM = 0xa0, SINDEX = 0x61, DINDEX = 0xe4, ARG_2 = 0x1
HCNT = 0x0 SCBPTR = 0x0
SCSISIGI[0x0] ERROR[0x0] SCSIBUSL[0x0] LASTPHASE[0x1]:(P_BUSFREE)
SCSISEQ[0x12]:(ENAUTOATNP|ENRSELI) SBLKCTL[0xa]:(SELWIDE|SELBUSB)
SCSIRATE[0x0] SEQCTL[0x10]:(FASTMODE) SEQ_FLAGS[0x40]:(NO_CDB_SENT)
SSTAT0[0x0] SSTAT1[0x0] SSTAT2[0x0] SSTAT3[0x0] SIMODE0[0x8]:(ENSWRAP) SIMODE1[0xa4]:(ENSCSIPERR|ENSCSIRST|ENSELTIMO) SXFRCTL0[0x88]:(SPIOEN|DFON)
DFCNTRL[0x0] DFSTATUS[0x89]:(FIFOEMP|HDONE|PRELOAD_AVAIL)
STACK: 0x3 0xe3 0x0 0x0
SCB count = 5
Kernel NEXTQSCB = 3
Card NEXTQSCB = 4
QINFIFO entries: 4
Waiting Queue entries:
Disconnected Queue entries:
QOUTFIFO entries:
Sequencer Free SCB List: 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 3 Sequencer SCB Info:
0 SCB_CONTROL[0x50]:(MK_MESSAGE|DISCENB) SCB_SCSIID[0xf]:(OID)
SCB_LUN[0x0] SCB_TAG[0xff]
1 SCB_CONTROL[0x0] SCB_SCSIID[0xff]:(TWIN_CHNLB|OID|TWIN_TID)
SCB_LUN[0xff]:(SCB_XFERLEN_ODD|LID) SCB_TAG[0xff]
2 SCB_CONTROL[0x0] SCB_SCSIID[0xff]:(TWIN_CHNLB|OID|TWIN_TID)
SCB_LUN[0xff]:(SCB_XFERLEN_ODD|LID) SCB_TAG[0xff]
3 SCB_CONTROL[0x0] SCB_SCSIID[0xff]:(TWIN_CHNLB|OID|TWIN_TID)
SCB_LUN[0xff]:(SCB_XFERLEN_ODD|LID) SCB_TAG[0xff]
4 SCB_CONTROL[0x0] SCB_SCSIID[0xff]:(TWIN_CHNLB|OID|TWIN_TID)
SCB_LUN[0xff]:(SCB_XFERLEN_ODD|LID) SCB_TAG[0xff]
5 SCB_CONTROL[0x0] SCB_SCSIID[0xff]:(TWIN_CHNLB|OID|TWIN_TID)
SCB_LUN[0xff]:(SCB_XFERLEN_ODD|LID) SCB_TAG[0xff]
6 SCB_CONTROL[0x0] SCB_SCSIID[0xff]:(TWIN_CHNLB|OID|TWIN_TID)
SCB_LUN[0xff]:(SCB_XFERLEN_ODD|LID) SCB_TAG[0xff]
7 SCB_CONTROL[0x0] SCB_SCSIID[0xff]:(TWIN_CHNLB|OID|TWIN_TID)
SCB_LUN[0xff]:(SCB_XFERLEN_ODD|LID) SCB_TAG[0xff]
8 SCB_CONTROL[0x0] SCB_SCSIID[0xff]:(TWIN_CHNLB|OID|TWIN_TID)
SCB_LUN[0xff]:(SCB_XFERLEN_ODD|LID) SCB_TAG[0xff]
9 SCB_CONTROL[0x0] SCB_SCSIID[0xff]:(TWIN_CHNLB|OID|TWIN_TID)
SCB_LUN[0xff]:(SCB_XFERLEN_ODD|LID) SCB_TAG[0xff]
10 SCB_CONTROL[0x0] SCB_SCSIID[0xff]:(TWIN_CHNLB|OID|TWIN_TID)
SCB_LUN[0xff]:(SCB_XFERLEN_ODD|LID) SCB_TAG[0xff]
11 SCB_CONTROL[0x0] SCB_SCSIID[0xff]:(TWIN_CHNLB|OID|TWIN_TID)
SCB_LUN[0xff]:(SCB_XFERLEN_ODD|LID) SCB_TAG[0xff]
12 SCB_CONTROL[0x0] SCB_SCSIID[0xff]:(TWIN_CHNLB|OID|TWIN_TID)
SCB_LUN[0xff]:(SCB_XFERLEN_ODD|LID) SCB_TAG[0xff]
13 SCB_CONTROL[0x0] SCB_SCSIID[0xff]:(TWIN_CHNLB|OID|TWIN_TID)
SCB_LUN[0xff]:(SCB_XFERLEN_ODD|LID) SCB_TAG[0xff]
14 SCB_CONTROL[0x0] SCB_SCSIID[0xff]:(TWIN_CHNLB|OID|TWIN_TID)
SCB_LUN[0xff]:(SCB_XFERLEN_ODD|LID) SCB_TAG[0xff]
15 SCB_CONTROL[0x0] SCB_SCSIID[0xff]:(TWIN_CHNLB|OID|TWIN_TID)
SCB_LUN[0xff]:(SCB_XFERLEN_ODD|LID) SCB_TAG[0xff]
16 SCB_CONTROL[0x0] SCB_SCSIID[0xff]:(TWIN_CHNLB|OID|TWIN_TID)
SCB_LUN[0xff]:(SCB_XFERLEN_ODD|LID) SCB_TAG[0xff]
17 SCB_CONTROL[0x0] SCB_SCSIID[0xff]:(TWIN_CHNLB|OID|TWIN_TID)
SCB_LUN[0xff]:(SCB_XFERLEN_ODD|LID) SCB_TAG[0xff]
18 SCB_CONTROL[0x0] SCB_SCSIID[0xff]:(TWIN_CHNLB|OID|TWIN_TID)
SCB_LUN[0xff]:(SCB_XFERLEN_ODD|LID) SCB_TAG[0xff]
19 SCB_CONTROL[0x0] SCB_SCSIID[0xff]:(TWIN_CHNLB|OID|TWIN_TID)
SCB_LUN[0xff]:(SCB_XFERLEN_ODD|LID) SCB_TAG[0xff]
20 SCB_CONTROL[0x0] SCB_SCSIID[0xff]:(TWIN_CHNLB|OID|TWIN_TID)
SCB_LUN[0xff]:(SCB_XFERLEN_ODD|LID) SCB_TAG[0xff]
21 SCB_CONTROL[0x0] SCB_SCSIID[0xff]:(TWIN_CHNLB|OID|TWIN_TID)
SCB_LUN[0xff]:(SCB_XFERLEN_ODD|LID) SCB_TAG[0xff]
22 SCB_CONTROL[0x0] SCB_SCSIID[0xff]:(TWIN_CHNLB|OID|TWIN_TID)
SCB_LUN[0xff]:(SCB_XFERLEN_ODD|LID) SCB_TAG[0xff]
23 SCB_CONTROL[0x0] SCB_SCSIID[0xff]:(TWIN_CHNLB|OID|TWIN_TID)
SCB_LUN[0xff]:(SCB_XFERLEN_ODD|LID) SCB_TAG[0xff]
24 SCB_CONTROL[0x0] SCB_SCSIID[0xff]:(TWIN_CHNLB|OID|TWIN_TID)
SCB_LUN[0xff]:(SCB_XFERLEN_ODD|LID) SCB_TAG[0xff]
25 SCB_CONTROL[0x0] SCB_SCSIID[0xff]:(TWIN_CHNLB|OID|TWIN_TID)
SCB_LUN[0xff]:(SCB_XFERLEN_ODD|LID) SCB_TAG[0xff]
26 SCB_CONTROL[0x0] SCB_SCSIID[0xff]:(TWIN_CHNLB|OID|TWIN_TID)
SCB_LUN[0xff]:(SCB_XFERLEN_ODD|LID) SCB_TAG[0xff]
27 SCB_CONTROL[0x0] SCB_SCSIID[0xff]:(TWIN_CHNLB|OID|TWIN_TID)
SCB_LUN[0xff]:(SCB_XFERLEN_ODD|LID) SCB_TAG[0xff]
28 SCB_CONTROL[0x0] SCB_SCSIID[0xff]:(TWIN_CHNLB|OID|TWIN_TID)
SCB_LUN[0xff]:(SCB_XFERLEN_ODD|LID) SCB_TAG[0xff]
29 SCB_CONTROL[0x0] SCB_SCSIID[0xff]:(TWIN_CHNLB|OID|TWIN_TID)
SCB_LUN[0xff]:(SCB_XFERLEN_ODD|LID) SCB_TAG[0xff]
30 SCB_CONTROL[0x0] SCB_SCSIID[0xff]:(TWIN_CHNLB|OID|TWIN_TID)
SCB_LUN[0xff]:(SCB_XFERLEN_ODD|LID) SCB_TAG[0xff]
31 SCB_CONTROL[0x0] SCB_SCSIID[0xff]:(TWIN_CHNLB|OID|TWIN_TID)
SCB_LUN[0xff]:(SCB_XFERLEN_ODD|LID) SCB_TAG[0xff]
Pending list:
4 SCB_CONTROL[0x40]:(DISCENB) SCB_SCSIID[0xf]:(OID) SCB_LUN[0x0]
Kernel Free SCB list: 2 1 0
Untagged Q(0): 4
DevQ(0:0:0): 0 waiting

<<<<<<<<<<<<<<<<< Dump Card State Ends >>>>>>>>>>>>>>>>>> scsi0:0:0:0: Cmd aborted from QINFIFO aic7xxx_abort returns 0x2002
scsi0: target 14 using 8bit transfers
scsi0: target 14 using asynchronous transfers
====================================================================

Any ideas to fix ?

Daniel Podlejski <[email protected]>
   ... 'Cause yesterday's got nothin' for me
   Old pictures that I'll always see ...

Daniel Podlejski wrote:
[...]
: I have Adaptec SCSI controler, which with 2.4.20-ac2 boots ok:
: <<<<<<<<<<<<<<<<< Dump Card State Ends >>>>>>>>>>>>>>>>>> : scsi0:0:0:0: Cmd aborted from QINFIFO
: aic7xxx_abort returns 0x2002
: scsi0: target 14 using 8bit transfers
: scsi0: target 14 using asynchronous transfers
: ==================================================================== :
: Any ideas to fix ?

After switch off APIC support works fine.

Daniel Podlejski <[email protected]>
   ... You can check out any time you like
   But you can never leave ...

<...>

Hmmm that makes quite a difference ! I didn't understand what happened between these two outputs. Also, did you try with Justin's latest version of the driver:

http://people.freebsd.org/~gibbs/linux/SRC/

It fixed many problems for several of us.

Regards,
Willy

My driver can't fix interrupt routing issues which is what Daniel's problem turned out to be. I'm really tempted to add an interrupt test to the driver attach so that these kinds of problems are clearly flagged and my driver doesn't continue to get blamed for interrupt routing it can't control.

--
Justin

If this is (relatively) easy to do, I really think it could be a valuable diagnostic tool. I'd prefer to get a clear "fix your APIC" or any insult about my hardware config than devices detection dying in endless timeout loops.

This principle may even be generalized to any other driver which can make the device trigger an interrupt.

Cheers,
Willy

Which aspect of interrupt routing is broken so that we at least can have a go at fixing it? I might be missing something here but it looks fine, could you elaborate?

2.4.18

IRQ to pin mappings:
IRQ0 -> 0:2
IRQ1 -> 0:1
IRQ3 -> 0:3
IRQ4 -> 0:4
IRQ5 -> 0:5
IRQ6 -> 0:6
IRQ7 -> 0:7
IRQ8 -> 0:8
IRQ9 -> 0:9
IRQ10 -> 0:10
IRQ11 -> 0:11
IRQ12 -> 0:12
IRQ13 -> 0:13
IRQ14 -> 0:14
IRQ15 -> 0:15
IRQ16 -> 1:0
IRQ17 -> 1:1
IRQ18 -> 1:2
IRQ19 -> 1:3
IRQ20 -> 1:4
IRQ21 -> 1:5
IRQ22 -> 1:6
IRQ23 -> 1:7
IRQ28 -> 1:12
IRQ29 -> 1:13

CPU0 CPU1 CPU2

  0:    3354580    4108947    4515468    IO-APIC-edge  timer
  1:          2          0          0    IO-APIC-edge  keyboard
  2:          0          0          0          XT-PIC  cascade
  4:        434        467        729    IO-APIC-edge  serial
  8:          1          0          0    IO-APIC-edge  rtc
 19:      73764      78100      80631   IO-APIC-level  eth0
 28:     301389     301350     302498   IO-APIC-level  aic7xxx
 29:      79542      82186      83042   IO-APIC-level  aic7xxx
NMI:   11978872   11978872   11978872 
LOC:   11978887   11978722   11978731 
ERR:          0
MIS:          0

2.5.70

IRQ to pin mappings:
IRQ0 -> 0:2
IRQ1 -> 0:1
IRQ3 -> 0:3
IRQ4 -> 0:4
IRQ5 -> 0:5
IRQ6 -> 0:6
IRQ7 -> 0:7
IRQ8 -> 0:8
IRQ9 -> 0:9
IRQ10 -> 0:10
IRQ11 -> 0:11
IRQ12 -> 0:12
IRQ13 -> 0:13
IRQ14 -> 0:14
IRQ15 -> 0:15
IRQ16 -> 1:0
IRQ17 -> 1:1
IRQ18 -> 1:2
IRQ19 -> 1:3
IRQ20 -> 1:4
IRQ21 -> 1:5
IRQ22 -> 1:6
IRQ23 -> 1:7
IRQ28 -> 1:12
IRQ29 -> 1:13

<no /proc/interrupts because it never makes it to a single user prompt>

function.linuxpower.ca

Daniel is comparing 2.4.20-ac2 with 2.4.21-rc6. In 2.4.20-ac2, APIC routing is disabled by default and his kernel works. In 2.4.21-rc6, APIC routing is enabled by default and interrupts are not properly routed to his SCSI controller. If he boots with noapic, everything works fine. You'll have to ask Daniel for more details on his system if you want to figure out why interrupts are not being delivered. All I know is, from the output and his testing, it is pretty obvious that interrupts are not being delivered.

--
Justin

Ok i'll ask him about the details, but i've posted on a number of occasions about aic7xxx oopsing unless i boot with noapic. Interrupts do get delivered otherwise it wouldn't even get to mounting root. I can't give you a 2.5.70 boot because raid is horked there too. If you want me to fish out the emails again i can do that.

Zwane

function.linuxpower.ca