AIC7xxx problem

AIC7xxx problem

[Daniel Podlejski]

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
>>>>>>>>>>>>>>>>>> Dump Card State Begins <<<<<<<<<<<<<<<<<
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 <underley@underley.eu.org>
   ... 'Cause yesterday's got nothin' for me
   Old pictures that I'll always see ...

Re: AIC7xxx problem

[Daniel Podlejski]

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 <underley@underley.eu.org>
   ... You can check out any time you like
   But you can never leave ...

Re: AIC7xxx problem

[Willy Tarreau]

On Sat, May 31, 2003 at 06:59:45PM +0200, Daniel Podlejski wrote:
 
> (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): 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

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

Re: AIC7xxx problem

[Justin T. Gibbs]

> 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:
> 

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

Re: AIC7xxx problem

[Willy Tarreau]

On Sun, Jun 01, 2003 at 02:34:40PM -0600, Justin T. Gibbs wrote:
> > 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:
> > 
> 
> 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.

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

Re: AIC7xxx problem

[Zwane Mwaikambo]

On Sun, 1 Jun 2003, Justin T. Gibbs wrote:

> > 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:
> > 
> 
> 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.

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

Re: AIC7xxx problem

[Justin T. Gibbs]

>> 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.
> 
> 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?

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

Re: AIC7xxx problem

[Zwane Mwaikambo]

On Sun, 1 Jun 2003, Justin T. Gibbs wrote:

> 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.

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

Re: aic7xxx problem.

[Philippe Troin]

Emmanuel Fuste <e.fuste@wanadoo.fr> writes:

> Hi all,
> 
> I have a problem with an adaptec 2940u2w since ... a long time: I tried
> to get it working since kernel 2.3.9x.
> The board work fine in other computer on Linux.
> When I try on mine (old dual cpu i586 asus board) I got this kind of
> kernel messages at boot and less than five second later, the computer
> lock:
> scsi0: PCI error Interrupt at seqaddr = 0x8
> scsi0: Data Parity Error Detected during address or write data phase
> scsi0: PCI error Interrupt at seqaddr = 0x8
> scsi0: Data Parity Error Detected during address or write data phase
> scsi0: PCI error Interrupt at seqaddr = 0x8
> scsi0: Data Parity Error Detected during address or write data phase
> scsi0: PCI error Interrupt at seqaddr = 0x8
> scsi0: Data Parity Error Detected during address or write data phase
> scsi0: PCI error Interrupt at seqaddr = 0x8
> scsi0: Data Parity Error Detected during address or write data phase
> scsi0: PCI error Interrupt at seqaddr = 0x8
> scsi0: Data Parity Error Detected during address or write data phase
> scsi0: PCI error Interrupt at seqaddr = 0x7
> scsi0: Data Parity Error Detected during address or write data phase
> scsi0: PCI error Interrupt at seqaddr = 0x8
> scsi0: Data Parity Error Detected during address or write data phase
> scsi0: PCI error Interrupt at seqaddr = 0x9
> scsi0: Data Parity Error Detected during address or write data phase
> scsi0: PCI error Interrupt at seqaddr = 0x7
> scsi0: Data Parity Error Detected during address or write data phase
> scsi0: PCI error Interrupt at seqaddr = 0x8
> scsi0: Data Parity Error Detected during address or write data phase

8< snip >8

Which hardware is connected to your SCSI adapter? (hint: cat /proc/scsi/scsi)

I've found out that some IBM hard disks give the above error when too
many tagged commands are queued (firmware bug probably). I definitely
have a DDRS-39130D drive which shows this behavior. The old SCSI
driver (5.x) was not as bold as the 6.x driver which is in 2.4 with
regards to queueing: the 6.x driver use 253 tagged command openings by
default.

For me, passing `aic7xxx=tag_info:{{,,,8}}' to the kernel solved the
problems. The above tells the aic7xxx driver to limit tagged queuing
depth to 8 for the drive at ID 3 on the first aic7xxx adapter, but
YMMV.

Phil.

aic7xxx problem.

[Emmanuel Fuste]

Hi all,

I have a problem with an adaptec 2940u2w since ... a long time: I tried
to get it working since kernel 2.3.9x.
The board work fine in other computer on Linux.
When I try on mine (old dual cpu i586 asus board) I got this kind of
kernel messages at boot and less than five second later, the computer
lock:
scsi0: PCI error Interrupt at seqaddr = 0x8
scsi0: Data Parity Error Detected during address or write data phase
scsi0: PCI error Interrupt at seqaddr = 0x8
scsi0: Data Parity Error Detected during address or write data phase
scsi0: PCI error Interrupt at seqaddr = 0x8
scsi0: Data Parity Error Detected during address or write data phase
scsi0: PCI error Interrupt at seqaddr = 0x8
scsi0: Data Parity Error Detected during address or write data phase
scsi0: PCI error Interrupt at seqaddr = 0x8
scsi0: Data Parity Error Detected during address or write data phase
scsi0: PCI error Interrupt at seqaddr = 0x8
scsi0: Data Parity Error Detected during address or write data phase
scsi0: PCI error Interrupt at seqaddr = 0x7
scsi0: Data Parity Error Detected during address or write data phase
scsi0: PCI error Interrupt at seqaddr = 0x8
scsi0: Data Parity Error Detected during address or write data phase
scsi0: PCI error Interrupt at seqaddr = 0x9
scsi0: Data Parity Error Detected during address or write data phase
scsi0: PCI error Interrupt at seqaddr = 0x7
scsi0: Data Parity Error Detected during address or write data phase
scsi0: PCI error Interrupt at seqaddr = 0x8
scsi0: Data Parity Error Detected during address or write data phase

My computer had always worked with an aic7xxx since 1.3.4x kernels. I
have now an aic7871 (2940uw) and it work well.
But sometimes I have a flood of theses messages in syslog like with the
2940u2w, messages stops and the computer continue to work as if nothing
was appened.
It generaly apened only one time per boot.
My running kernel is 2.4.20-rc1 with alsa 0.9rc5. I already tried all
combinaisons: single CPU mode, noapic, etc...
I think I have a problem with my PCI conf, but I'm not an expert :-(

Output of lspci -v:
00:00.0 Host bridge: Intel Corp. 430HX - 82439HX TXC [Triton II] (rev
03)
        Flags: bus master, medium devsel, latency 32

00:01.0 ISA bridge: Intel Corp. 82371SB PIIX3 ISA [Natoma/Triton II]
(rev 01)
        Flags: bus master, medium devsel, latency 0

00:01.1 IDE interface: Intel Corp. 82371SB PIIX3 IDE [Natoma/Triton II]
(prog-if 80 [Master])
        Flags: bus master, medium devsel, latency 32
        I/O ports at e800 [size=16]

00:01.2 USB Controller: Intel Corp. 82371SB PIIX3 USB [Natoma/Triton II]
(rev 01) (prog-if 00 [UHC
I])
        Flags: bus master, medium devsel, latency 32, IRQ 19
        I/O ports at e400 [size=32]

00:09.0 SCSI storage controller: Adaptec AHA-2940U/UW/D / AIC-7881U
        Flags: bus master, medium devsel, latency 32, IRQ 19
        I/O ports at e000 [disabled] [size=256]
        Memory at e3000000 (32-bit, non-prefetchable) [size=4K]
        Expansion ROM at <unassigned> [disabled] [size=64K]

00:0b.0 VGA compatible controller: Matrox Graphics, Inc. MGA 2164W
[Millennium II] (prog-if 00 [VG
A])
        Subsystem: Matrox Graphics, Inc. MGA-2164W Millennium II
        Flags: bus master, medium devsel, latency 32, IRQ 17
        Memory at e6000000 (32-bit, prefetchable) [size=16M]
        Memory at e2800000 (32-bit, non-prefetchable) [size=16K]
        Memory at e2000000 (32-bit, non-prefetchable) [size=8M]
        Expansion ROM at <unassigned> [disabled] [size=64K]

00:0c.0 VGA compatible controller: Matrox Graphics, Inc. MGA G200 (rev
01) (prog-if 00 [VGA])
        Subsystem: Matrox Graphics, Inc. Millennium G200 SD
        Flags: medium devsel, IRQ 16
        Memory at e4000000 (32-bit, prefetchable) [size=16M]
        Memory at e1800000 (32-bit, non-prefetchable) [size=16K]
        Memory at e1000000 (32-bit, non-prefetchable) [size=8M]
        Expansion ROM at e3ff0000 [disabled] [size=64K]
        Capabilities: [dc] Power Management version 1

00:0d.0 Ethernet controller: Advanced Micro Devices [AMD] 79c970 [PCnet
LANCE] (rev 02)
        Flags: bus master, stepping, medium devsel, latency 0, IRQ 19
        I/O ports at d800 [size=32]

The things that choked me are the latency on the isa bridge and the
PCnet controller.
On the other hand, for the pcnet, I could read these in my syslog:

pcnet32.c:v1.27b 01.10.2002 tsbogend@alpha.franken.de
PCI: Setting latency timer of device 00:0d.0 to 64
pcnet32: PCnet/PCI 79C970 at 0xd800, 10 00 5a 5b 55 97 assigned IRQ 19.
eth0: registered as PCnet/PCI 79C970
pcnet32: 1 cards_found.

Who is true ? lspci or the syslog ? is the driver fail to set latency to
64 or lspci wrong ?

For the ISA bridge, is this harmless or should I try to patch the kernel
with a new quirk ? (if my bios is buggy, there is no support for my
board since a long time).

Please Alan (which like old bizare computer) or other, help me. I will
try a 2.5 kernel which seems to have more advanced PCI setup some time
but it is a long operation to compile a kernel on this computer (and
more now since alsa just crashed leaving one cpu stuck a 100% ;-)))

Emmanuel.

PS: Please CC, I only read lklm via web mail archive.
Thanks.