* aic7xxx problem.
@ 2002-11-05 22:34 Emmanuel Fuste
2002-11-06 1:24 ` Philippe Troin
0 siblings, 1 reply; 11+ messages in thread
From: Emmanuel Fuste @ 2002-11-05 22:34 UTC (permalink / raw)
To: linux-kernel
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.
^ permalink raw reply [flat|nested] 11+ messages in thread* Re: aic7xxx problem.
2002-11-05 22:34 aic7xxx problem Emmanuel Fuste
@ 2002-11-06 1:24 ` Philippe Troin
2002-11-06 9:57 ` aic7xxx problem. (PCI related ?) Emmanuel FUSTE
0 siblings, 1 reply; 11+ messages in thread
From: Philippe Troin @ 2002-11-06 1:24 UTC (permalink / raw)
To: Emmanuel Fuste; +Cc: linux-kernel
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.
^ permalink raw reply [flat|nested] 11+ messages in thread* Re: aic7xxx problem. (PCI related ?)
2002-11-06 1:24 ` Philippe Troin
@ 2002-11-06 9:57 ` Emmanuel FUSTE
0 siblings, 0 replies; 11+ messages in thread
From: Emmanuel FUSTE @ 2002-11-06 9:57 UTC (permalink / raw)
To: phil; +Cc: linux-kernel
> 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.
Thanks Phil, unfortunately, this doesnt solve my problem.
The 5.x driver never worked for me on the 2940u2w, it lock the computer.
I could even trigger the kernel message with no devices attached to the scsi bus.
With the two adapters in the computer, when I issue a scsiadd -s 1, I've got the
errors but whithout the hard lock.
For reference:
http://marc.theaimsgroup.com/?l=linux-kernel&m=99295558926036&w=2
http://marc.theaimsgroup.com/?l=linux-kernel&m=100852862320948&w=2
Is someone knew something about my pblm with the pci latency timer set to 0 ?
Emmanuel.
^ permalink raw reply [flat|nested] 11+ messages in thread
* AIC7xxx problem
@ 2003-05-31 16:59 Daniel Podlejski
2003-06-01 8:19 ` Daniel Podlejski
2003-06-01 8:36 ` Willy Tarreau
0 siblings, 2 replies; 11+ messages in thread
From: Daniel Podlejski @ 2003-05-31 16:59 UTC (permalink / raw)
To: linux-kernel
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 ...
^ permalink raw reply [flat|nested] 11+ messages in thread* Re: AIC7xxx problem
2003-05-31 16:59 AIC7xxx problem Daniel Podlejski
@ 2003-06-01 8:19 ` Daniel Podlejski
2003-06-01 8:36 ` Willy Tarreau
1 sibling, 0 replies; 11+ messages in thread
From: Daniel Podlejski @ 2003-06-01 8:19 UTC (permalink / raw)
To: linux-kernel
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 ...
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: AIC7xxx problem
2003-05-31 16:59 AIC7xxx problem Daniel Podlejski
2003-06-01 8:19 ` Daniel Podlejski
@ 2003-06-01 8:36 ` Willy Tarreau
2003-06-01 20:34 ` Justin T. Gibbs
1 sibling, 1 reply; 11+ messages in thread
From: Willy Tarreau @ 2003-06-01 8:36 UTC (permalink / raw)
To: Daniel Podlejski; +Cc: linux-kernel
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
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: AIC7xxx problem
2003-06-01 8:36 ` Willy Tarreau
@ 2003-06-01 20:34 ` Justin T. Gibbs
2003-06-01 20:45 ` Willy Tarreau
2003-06-01 20:56 ` Zwane Mwaikambo
0 siblings, 2 replies; 11+ messages in thread
From: Justin T. Gibbs @ 2003-06-01 20:34 UTC (permalink / raw)
To: Willy Tarreau, Daniel Podlejski; +Cc: linux-kernel
> 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
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: AIC7xxx problem
2003-06-01 20:34 ` Justin T. Gibbs
@ 2003-06-01 20:45 ` Willy Tarreau
2003-06-01 20:56 ` Zwane Mwaikambo
1 sibling, 0 replies; 11+ messages in thread
From: Willy Tarreau @ 2003-06-01 20:45 UTC (permalink / raw)
To: Justin T. Gibbs; +Cc: Willy Tarreau, Daniel Podlejski, linux-kernel
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
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: AIC7xxx problem
2003-06-01 20:34 ` Justin T. Gibbs
2003-06-01 20:45 ` Willy Tarreau
@ 2003-06-01 20:56 ` Zwane Mwaikambo
2003-06-01 21:37 ` Justin T. Gibbs
1 sibling, 1 reply; 11+ messages in thread
From: Zwane Mwaikambo @ 2003-06-01 20:56 UTC (permalink / raw)
To: Justin T. Gibbs; +Cc: Willy Tarreau, Daniel Podlejski, linux-kernel
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
^ permalink raw reply [flat|nested] 11+ messages in thread* Re: AIC7xxx problem
2003-06-01 20:56 ` Zwane Mwaikambo
@ 2003-06-01 21:37 ` Justin T. Gibbs
2003-06-01 21:38 ` Zwane Mwaikambo
0 siblings, 1 reply; 11+ messages in thread
From: Justin T. Gibbs @ 2003-06-01 21:37 UTC (permalink / raw)
To: Zwane Mwaikambo; +Cc: Willy Tarreau, Daniel Podlejski, linux-kernel
>> 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
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: AIC7xxx problem
2003-06-01 21:37 ` Justin T. Gibbs
@ 2003-06-01 21:38 ` Zwane Mwaikambo
0 siblings, 0 replies; 11+ messages in thread
From: Zwane Mwaikambo @ 2003-06-01 21:38 UTC (permalink / raw)
To: Justin T. Gibbs; +Cc: Willy Tarreau, Daniel Podlejski, linux-kernel
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
^ permalink raw reply [flat|nested] 11+ messages in thread
end of thread, other threads:[~2003-06-01 21:35 UTC | newest]
Thread overview: 11+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2002-11-05 22:34 aic7xxx problem Emmanuel Fuste
2002-11-06 1:24 ` Philippe Troin
2002-11-06 9:57 ` aic7xxx problem. (PCI related ?) Emmanuel FUSTE
-- strict thread matches above, loose matches on Subject: below --
2003-05-31 16:59 AIC7xxx problem Daniel Podlejski
2003-06-01 8:19 ` Daniel Podlejski
2003-06-01 8:36 ` Willy Tarreau
2003-06-01 20:34 ` Justin T. Gibbs
2003-06-01 20:45 ` Willy Tarreau
2003-06-01 20:56 ` Zwane Mwaikambo
2003-06-01 21:37 ` Justin T. Gibbs
2003-06-01 21:38 ` Zwane Mwaikambo
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox