ahc(4) reports PCI parity error interrupt
Wilko Bulte
I'm looking for comments on the following:
ahc0: PCI error Interrupt at seqaddr = 0x8
ahc0: Data Parity Error Detected during address or write data phase
ahc0: PCI error Interrupt at seqaddr = 0x9
ahc0: Data Parity Error Detected during address or write data phase
ahc0: PCI error Interrupt at seqaddr = 0x9
ahc0: Data Parity Error Detected during address or write data phase
ahc0: PCI error Interrupt at seqaddr = 0x8
ahc0: Data Parity Error Detected during address or write data phase
ahc0: PCI error Interrupt at seqaddr = 0x8
I've also experienced system lockups & panics.
This happens exclusively while doing:
- considerable disk I/O (buildworld) via ahc0
- watching TV via fxtv on a WinTV Primio
It feels like the datastream of the WinTV into the framebuffer (Matrox
G200 AGP) gets in the way with the data from/to the Adaptec 29160.
I ran the same systemdisk & all expansion cards in a PII-266 with Intel
chipset without any issue. The K7V is rock stable as long as I keep my
fingers from fxtv.
Suggestions on how to analyse/workaround this issue are most welcome.
Anything in the BIOS setup maybe?
Wilko
======= background data ==============
FreeBSD freebie.xs4all.nl 4.4-STABLE FreeBSD 4.4-STABLE #0: Thu Nov 1 23:47:04 CET 2001 ro...@freebie.xs4all.nl:/usr/src/sys/compile/FREEBIE i386
Mainboard: Asus K7V (VIA based, brandnew) with Athlon 700
Also occured on a VIA based Abit KA7
(I got the Asus as the Abit died on me)
SCSI:
freebie# camcontrol devlist
<SEAGATE ST39103LC 0002> at scbus0 target 0 lun 0 (pass0,da0)
<TOSHIBA DVD-ROM SD-M1201 1R08> at scbus0 target 3 lun 0 (pass1,cd0)
dmesg:
FreeBSD 4.4-STABLE #0: Thu Nov 1 23:47:04 CET 2001
ro...@freebie.xs4all.nl:/usr/src/sys/compile/FREEBIE
Timecounter "i8254" frequency 1193182 Hz
Timecounter "TSC" frequency 700029024 Hz
CPU: AMD Athlon(tm) Processor (700.03-MHz 686-class CPU)
Origin = "AuthenticAMD" Id = 0x621 Stepping = 1
Features=0x183f9ff<FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,SEP,MTRR,PGE,MCA,CMOV,PA
T,PSE36,MMX,FXSR>
AMD Features=0xc0400000<AMIE,DSP,3DNow!>
real memory = 268353536 (262064K bytes)
avail memory = 257622016 (251584K bytes)
Preloaded elf kernel "kernel" at 0xc038f000.
Preloaded elf module "agp.ko" at 0xc038f09c.
Pentium Pro MTRR support enabled
Using $PIR table, 8 entries at 0xc00f15e0
npx0: <math processor> on motherboard
npx0: INT 16 interface
pcib0: <Host to PCI bridge> on motherboard
pci0: <PCI bus> on pcib0
agp0: <VIA 82C691 (Apollo Pro) host to PCI bridge> mem 0xe4000000-0xe7ffffff
at
device 0.0 on pci0
pcib2: <VIA 82C598MVP (Apollo MVP3) PCI-PCI (AGP) bridge> at device 1.0 on
pci0
pci1: <PCI bus> on pcib2
pci1: <Matrox MGA G200 AGP graphics accelerator> at 0.0 irq 11
isab0: <VIA 82C686 PCI-ISA bridge> at device 4.0 on pci0
isa0: <ISA bus> on isab0
atapci0: <VIA 82C686 ATA66 controller> port 0xd800-0xd80f at device 4.1 on
pci0
ata0: at 0x1f0 irq 14 on atapci0
uhci0: <VIA 83C572 USB controller> port 0xd400-0xd41f irq 5 at device 4.2 on
pci
0
usb0: <VIA 83C572 USB controller> on uhci0
usb0: USB revision 1.0
uhub0: VIA UHCI root hub, class 9/0, rev 1.00/1.00, addr 1
uhub0: 2 ports with 2 removable, self powered
uhci1: <VIA 83C572 USB controller> port 0xd000-0xd01f irq 5 at device 4.3 on
pci
0
usb1: <VIA 83C572 USB controller> on uhci1
usb1: USB revision 1.0
uhub1: VIA UHCI root hub, class 9/0, rev 1.00/1.00, addr 1
uhub1: 2 ports with 2 removable, self powered
xl0: <3Com 3c905-TX Fast Etherlink XL> port 0xa400-0xa43f irq 5 at device
9.0 on
pci0
xl0: Ethernet address: 00:60:08:09:b7:41
miibus0: <MII bus> on xl0
nsphy0: <DP83840 10/100 media interface> on miibus0
nsphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto
pcm0: <ESS Solo-1E> port
0x8800-0x8803,0x9000-0x9003,0x9400-0x940f,0x9800-0x980f
,0xa000-0xa03f irq 15 at device 10.0 on pci0
ahc0: <Adaptec 29160 Ultra160 SCSI adapter> port 0x8400-0x84ff mem
0xe0000000-0x
e0000fff irq 10 at device 11.0 on pci0
aic7892: Ultra160 Wide Channel A, SCSI Id=7, 32/255 SCBs
ahc1: <Adaptec 2940 Ultra SCSI adapter> port 0x8000-0x80ff mem
0xdf800000-0xdf80
0fff irq 11 at device 12.0 on pci0
aic7880: Ultra Wide Channel A, SCSI Id=7, 16/255 SCBs
bktr0: <BrookTree 878> mem 0xe2000000-0xe2000fff irq 5 at device 13.0 on
pci0
iicbb0: <I2C generic bit-banging driver> on bti2c0
iicbus0: <Philips I2C bus> on iicbb0 master-only
iicsmb0: <I2C to SMB bridge> on iicbus0
smbus0: <System Management Bus> on iicsmb0
smb0: <SMBus general purpose I/O> on smbus0
smbus1: <System Management Bus> on bti2c0
smb1: <SMBus general purpose I/O> on smbus1
bktr0: Hauppauge Model 61204 AMA
bktr0: Hauppauge WinCast/TV, Philips PAL I tuner.
pci0: <unknown card> (vendor=0x109e, dev=0x0878) at 13.1 irq 5
pcib1: <Host to PCI bridge> on motherboard
pci2: <PCI bus> on pcib1
orm0: <Option ROMs> at iomem 0xc0000-0xc7fff,0xc8000-0xcbfff,0xd4000-0xd47ff
on
isa0
fdc0: <NEC 72065B or clone> at port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on isa0
fdc0: FIFO enabled, 8 bytes threshold
fd0: <1440-KB 3.5" drive> on fdc0 drive 0
atkbdc0: <Keyboard controller (i8042)> at port 0x60,0x64 on isa0
atkbd0: <AT Keyboard> irq 1 on atkbdc0
psm0: <PS/2 Mouse> irq 12 on atkbdc0
psm0: model Generic PS/2 mouse, device ID 0
vga0: <Generic ISA VGA> at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0
sc0: <System console> on isa0
sc0: VGA <16 virtual consoles, flags=0x200>
sio0 at port 0x3f8-0x3ff irq 4 on isa0
sio0: type 16550A
sio1 at port 0x2f8-0x2ff irq 3 on isa0
sio1: type 16550A
ppc0: <Parallel port> at port 0x378-0x37f irq 5 flags 0x20 on isa0
ppc0: Generic chipset (EPP/NIBBLE) in COMPATIBLE mode
lpt0: <Printer> on ppbus0
lpt0: Polled port
unknown: <PNP0400> can't assign resources
unknown: <PNP0501> can't assign resources
unknown: <PNP0501> can't assign resources
unknown: <PNP0700> can't assign resources
unknown: <PNP0f13> can't assign resources
unknown: <PNP0c01> can't assign resources
unknown: <PNP0000> can't assign resources
unknown: <PNP0303> can't assign resources
ad0: 29188MB <ST330630A> [59303/16/63] at ata0-master UDMA66
Waiting 3 seconds for SCSI devices to settle
Mounting root from ufs:/dev/da0s2a
da0 at ahc0 bus 0 target 0 lun 0
da0: <SEAGATE ST39103LC 0002> Fixed Direct Access SCSI-2 device
da0: 40.000MB/s transfers (20.000MHz, offset 15, 16bit), Tagged Queueing
Enabled
da0: 8683MB (17783240 512 byte sectors: 255H 63S/T 1106C)
cd0 at ahc0 bus 0 target 3 lun 0
cd0: <TOSHIBA DVD-ROM SD-M1201 1R08> Removable CD-ROM SCSI-2 device
cd0: 20.000MB/s transfers (20.000MHz, offset 16)
cd0: Attempt to query device size failed: NOT READY, Medium not present
--
| / o / /_ _ email: wi...@FreeBSD.org
|/|/ / / /( (_) Bulte Arnhem, The Netherlands
To Unsubscribe: send mail to majo...@FreeBSD.org
with "unsubscribe freebsd-scsi" in the body of the message
Wilko Bulte
I forgot to mention that I had the same config running fine
on the same Abit MB using 4.3-stable.
And that PII-266 is a VIA chipset of some sort, not an Intel like I
write below
Wilko
--
Wilko Bulte
> >On Fri, Nov 02, 2001 at 12:21:22AM +0100, Wilko Bulte wrote:
> >
> >I forgot to mention that I had the same config running fine
> >on the same Abit MB using 4.3-stable.
>
Eh.. somehow this worries me :-/ I have not experienced data corruption
that I know of.
Would an experiment with a 2940 iso a 29160 be worthwhile?
W/
Gary Jennejohn
[snip problem description]
> I ran the same systemdisk & all expansion cards in a PII-266
> with Intel chipset without any issue. The K7V is rock stable
> as long as I keep my fingers from fxtv.
>
> Suggestions on how to analyse/workaround this issue are most
> welcome. Anything in the BIOS setup maybe?
>
Sorry, no idea how to fix this, but I saw a very similar problem
under Linux while writing a driver for a data-acquisition board.
On a K7M (AMD chipset) I couldn't access the on-board memory
reliably, but using an INTEL chipset and CPU everything worked
just fine. Your report makes me think that there's a generic bug
in the Athlon and not a problem in the chipsets, which is what I
originally suspected.
--
Gary Jennejohn ga...@jennejohn.org g...@freebsd.org
Wilko Bulte
> On Friday 02 November 2001 00:21, Wilko Bulte wrote:
> [snip problem description]
> > with Intel chipset without any issue. The K7V is rock stable
> > as long as I keep my fingers from fxtv.
> >
> > Suggestions on how to analyse/workaround this issue are most
> > welcome. Anything in the BIOS setup maybe?
> >
>
> under Linux while writing a driver for a data-acquisition board.
> On a K7M (AMD chipset) I couldn't access the on-board memory
> reliably, but using an INTEL chipset and CPU everything worked
> just fine. Your report makes me think that there's a generic bug
> in the Athlon and not a problem in the chipsets, which is what I
> originally suspected.
It appears things are more complicated than that. I have swapped
the Adaptec 29160 for a 2940UW. I am now running continous buildworlds,
a 'dd' of the SCSI disk and fxtv in parallel.
This appears to work like a charm until now. I'll let it run and
see what develops
Wilko
Justin T. Gibbs
>the Adaptec 29160 for a 2940UW. I am now running continous buildworlds,
>a 'dd' of the SCSI disk and fxtv in parallel.
>
>This appears to work like a charm until now. I'll let it run and
>see what develops
I bet you the aic7892 on the 29160 does larger bursts than the 7880
on the 2940UW. This isn't quite an apples to apples comparison.
--
Justin
Wilko Bulte
> >It appears things are more complicated than that. I have swapped
> >the Adaptec 29160 for a 2940UW. I am now running continous buildworlds,
> >a 'dd' of the SCSI disk and fxtv in parallel.
> >
> >This appears to work like a charm until now. I'll let it run and
> >see what develops
>
> on the 2940UW. This isn't quite an apples to apples comparison.
Oh, I was not claiming it is a comparison. It is just an attempt to
understand what is going on.
Mike Silbersack
On Fri, 2 Nov 2001, Wilko Bulte wrote:
> On Fri, Nov 02, 2001 at 12:21:22AM +0100, Wilko Bulte wrote:
>
> I forgot to mention that I had the same config running fine
> on the same Abit MB using 4.3-stable.
>
> And that PII-266 is a VIA chipset of some sort, not an Intel like I
> write below
>
> Wilko
Hm, I'm not sure if the Via pci-bad-settings patch to the ata driver was
mfc'd yet. Perhaps more than onboard IDE and SB Lives are affected?
Mike "Silby" Silbersack
Joerg Wunsch
> Hm, I'm not sure if the Via pci-bad-settings patch to the ata driver
> was mfc'd yet. Perhaps more than onboard IDE and SB Lives are
> affected?
Now that you mention it: definately they affect more than just IDE and
SB. It's only that the error probability for anything else appears to
be much smaller. We've seen a VIA-based SCSI-only (and no SB, it's a
19" server :) crashing due to this bug and due to the corrupted files
resulting from it. Similar to Wilko's scenario, it only happened once
the machine has got heavy load. A FreeBSD machine on the same
hardware so far survived "make world", but we eventually RMAed the
mainboards after seeing the Linux crashing.
--
cheers, J"org .-.-. --... ...-- -.. . DL8DTL
http://www.sax.de/~joerg/ NIC: JW11-RIPE
Never trust an operating system you don't have sources for. ;-)
Wilko Bulte
> On Fri, Nov 02, 2001 at 09:52:28AM +0100, Gary Jennejohn wrote:
> > On Friday 02 November 2001 00:21, Wilko Bulte wrote:
> > [snip problem description]
> > > with Intel chipset without any issue. The K7V is rock stable
> > > as long as I keep my fingers from fxtv.
> > >
> > > Suggestions on how to analyse/workaround this issue are most
> > > welcome. Anything in the BIOS setup maybe?
> > >
> >
> > under Linux while writing a driver for a data-acquisition board.
> > On a K7M (AMD chipset) I couldn't access the on-board memory
> > reliably, but using an INTEL chipset and CPU everything worked
> > just fine. Your report makes me think that there's a generic bug
> > in the Athlon and not a problem in the chipsets, which is what I
> > originally suspected.
>
> the Adaptec 29160 for a 2940UW. I am now running continous buildworlds,
> a 'dd' of the SCSI disk and fxtv in parallel.
>
> This appears to work like a charm until now. I'll let it run and
> see what develops
It takes a while, but then it fails: fxtv looses the picture and
cc (from the buildworld) started sig11-ing. [No, this is not then
RAM, it only happens when fxtv runs]
Seems I better loose the TVcard :-/
Matthew N. Dodd
> Hm, I'm not sure if the Via pci-bad-settings patch to the ata driver
> was mfc'd yet. Perhaps more than onboard IDE and SB Lives are
> affected?
Yes. Download the latest BIOS for your VIA 82c686 based K7 board.
This fixed the problems I was observing of a similar nature.
--
| Matthew N. Dodd | '78 Datsun 280Z | '75 Volvo 164E | FreeBSD/NetBSD |
| win...@jurai.net | 2 x '84 Volvo 245DL | ix86,sparc,pmax |
| http://www.jurai.net/~winter | For Great Justice! | ISO8802.5 4ever |
Wilko Bulte
> On Fri, 2 Nov 2001, Mike Silbersack wrote:
> > Hm, I'm not sure if the Via pci-bad-settings patch to the ata driver
> > was mfc'd yet. Perhaps more than onboard IDE and SB Lives are
> > affected?
>
>
> This fixed the problems I was observing of a similar nature.
Well, I am at the latest rev Asus has up for ftp (rev 1007).
--
| / o / /_ _ email: wi...@FreeBSD.org
|/|/ / / /( (_) Bulte Arnhem, The Netherlands
To Unsubscribe: send mail to majo...@FreeBSD.org
Mike Silbersack
On Sat, 3 Nov 2001, Wilko Bulte wrote:
> On Sat, Nov 03, 2001 at 06:40:28AM -0500, Matthew N. Dodd wrote:
> > On Fri, 2 Nov 2001, Mike Silbersack wrote:
> > > Hm, I'm not sure if the Via pci-bad-settings patch to the ata driver
> > > was mfc'd yet. Perhaps more than onboard IDE and SB Lives are
> > > affected?
> >
> > Yes. Download the latest BIOS for your VIA 82c686 based K7 board.
> >
> > This fixed the problems I was observing of a similar nature.
>
> Well, I am at the latest rev Asus has up for ftp (rev 1007).
>
> --
> | / o / /_ _ email: wi...@FreeBSD.org
> |/|/ / / /( (_) Bulte Arnhem, The Netherlands
Soren has said in the past that some companies only apply the patch if a
SB Live is detected. You may wish to try pulling in the patch from
ata-pci.c (look for "VIA '686b southbridge fix applied\n") and see if it
helps you at all.
Mike "Silby" Silbersack
Wilko Bulte
>
> On Sat, 3 Nov 2001, Wilko Bulte wrote:
>
> > > On Fri, 2 Nov 2001, Mike Silbersack wrote:
> > > > Hm, I'm not sure if the Via pci-bad-settings patch to the ata driver
> > > > was mfc'd yet. Perhaps more than onboard IDE and SB Lives are
> > > > affected?
> > >
> > > Yes. Download the latest BIOS for your VIA 82c686 based K7 board.
> > >
> > > This fixed the problems I was observing of a similar nature.
> >
> > Well, I am at the latest rev Asus has up for ftp (rev 1007).
> >
> > --
> > | / o / /_ _ email: wi...@FreeBSD.org
> > |/|/ / / /( (_) Bulte Arnhem, The Netherlands
>
> SB Live is detected. You may wish to try pulling in the patch from
> ata-pci.c (look for "VIA '686b southbridge fix applied\n") and see if it
> helps you at all.
I have not yet tried this yet. But I tried something else
(my EE genes made me try this):
- I moved the Brooktree TV card from the slot furthest from the AGP
video card to the PCI slot closest to it.
Interestingly enough this made all the PCI errors go away, I ran continous
buildworlds overnight, in parallel with continuous 'dd's of da0 and ad0,
in parallel with fxtv.
All of this ran without a hitch. Interesting..
W/
Mike Silbersack
On Mon, 5 Nov 2001, Wilko Bulte wrote:
> > Soren has said in the past that some companies only apply the patch if a
> > SB Live is detected. You may wish to try pulling in the patch from
> > ata-pci.c (look for "VIA '686b southbridge fix applied\n") and see if it
> > helps you at all.
>
> I have not yet tried this yet. But I tried something else
> (my EE genes made me try this):
>
> - I moved the Brooktree TV card from the slot furthest from the AGP
> video card to the PCI slot closest to it.
>
> Interestingly enough this made all the PCI errors go away, I ran continous
> buildworlds overnight, in parallel with continuous 'dd's of da0 and ad0,
> in parallel with fxtv.
>
> All of this ran without a hitch. Interesting..
>
> W/
> --
> | / o / /_ _ email: wi...@FreeBSD.org
> |/|/ / / /( (_) Bulte Arnhem, The Netherlands
Hm... I was at a talk once where an HP EE mentioned that pci slots should
be filled in order due to capacitance and timing issues. I didn't pay
much attention to that, perhaps I should follow that layout in the future.
I really don't like putting cards near the overly warm AGP video card
though... oh well.
Mike "Silby" Silbersack
Matthew Dillon
:> I have not yet tried this yet. But I tried something else
:> (my EE genes made me try this):
:>
:> - I moved the Brooktree TV card from the slot furthest from the AGP
:> video card to the PCI slot closest to it.
:>
:> Interestingly enough this made all the PCI errors go away, I ran continous
:> buildworlds overnight, in parallel with continuous 'dd's of da0 and ad0,
:> in parallel with fxtv.
:>
:> All of this ran without a hitch. Interesting..
:>
:> W/
:> --
:> | / o / /_ _ email: wi...@FreeBSD.org
:> |/|/ / / /( (_) Bulte Arnhem, The Netherlands
:
:Hm... I was at a talk once where an HP EE mentioned that pci slots should
:be filled in order due to capacitance and timing issues. I didn't pay
:much attention to that, perhaps I should follow that layout in the future.
:I really don't like putting cards near the overly warm AGP video card
:though... oh well.
:
:Mike "Silby" Silbersack
I'll bet what's really happening is that the brooktree TV card
is generating a lot of noise on the power busses, and moving it
simply moved it closer to larger caps on the motherboard or
perhaps better caps on the AGP card.
-Matt
Wilko Bulte
>
> On Mon, 5 Nov 2001, Wilko Bulte wrote:
>
> > > Soren has said in the past that some companies only apply the patch if a
> > > SB Live is detected. You may wish to try pulling in the patch from
> > > ata-pci.c (look for "VIA '686b southbridge fix applied\n") and see if it
> > > helps you at all.
> >
> > I have not yet tried this yet. But I tried something else
> > (my EE genes made me try this):
> >
> > - I moved the Brooktree TV card from the slot furthest from the AGP
> > video card to the PCI slot closest to it.
> >
> > Interestingly enough this made all the PCI errors go away, I ran continous
> > buildworlds overnight, in parallel with continuous 'dd's of da0 and ad0,
> > in parallel with fxtv.
> >
> > All of this ran without a hitch. Interesting..
> >
> > W/
> > --
> > | / o / /_ _ email: wi...@FreeBSD.org
> > |/|/ / / /( (_) Bulte Arnhem, The Netherlands
>
> be filled in order due to capacitance and timing issues. I didn't pay
> much attention to that, perhaps I should follow that layout in the future.
> I really don't like putting cards near the overly warm AGP video card
> though... oh well.
Well, all my PCI slots are filled ;). The VGA is a Matrox G200 which
is not a house heater.
Wilko
Wilko Bulte
> :...
> :> I have not yet tried this yet. But I tried something else
> :> (my EE genes made me try this):
> :>
> :> - I moved the Brooktree TV card from the slot furthest from the AGP
> :> video card to the PCI slot closest to it.
> :>
> :> Interestingly enough this made all the PCI errors go away, I ran continous
> :> buildworlds overnight, in parallel with continuous 'dd's of da0 and ad0,
> :> in parallel with fxtv.
> :>
> :> All of this ran without a hitch. Interesting..
> :Hm... I was at a talk once where an HP EE mentioned that pci slots should
> :be filled in order due to capacitance and timing issues. I didn't pay
> :much attention to that, perhaps I should follow that layout in the future.
> :I really don't like putting cards near the overly warm AGP video card
> :though... oh well.
> :
> :Mike "Silby" Silbersack
>
> I'll bet what's really happening is that the brooktree TV card
> is generating a lot of noise on the power busses, and moving it
> simply moved it closer to larger caps on the motherboard or
> perhaps better caps on the AGP card.
Hmm. Interesting theory. Difficult to verify though. I did have this problem
on 2 different mainboards, but that does not mean both boards could not have
had the same power grid decoupling / bulk cap. issue of course.
Well.. it works now.
--
| / o / /_ _ email: wi...@FreeBSD.org
|/|/ / / /( (_) Bulte Arnhem, The Netherlands
To Unsubscribe: send mail to majo...@FreeBSD.org