From nobody@FreeBSD.ORG Thu Aug  5 16:51:39 1999
Return-Path: <nobody@FreeBSD.ORG>
Received: by hub.freebsd.org (Postfix, from userid 32767)
	id A10F215639; Thu,  5 Aug 1999 16:51:39 -0700 (PDT)
Message-Id: <19990805235139.A10F215639@hub.freebsd.org>
Date: Thu,  5 Aug 1999 16:51:39 -0700 (PDT)
From: phillip@www4.au.freebsd.org
Sender: nobody@FreeBSD.ORG
To: freebsd-gnats-submit@freebsd.org
Subject: "ahc0: Data Parity Error Detected during address or write data phase" kernel message
X-Send-Pr-Version: www-1.0

>Number:         12993
>Category:       i386
>Synopsis:       "ahc0: Data Parity Error Detected during address or write data phase" kernel message
>Confidential:   no
>Severity:       non-critical
>Priority:       medium
>Responsible:    gibbs
>State:          closed
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Thu Aug  5 17:00:00 PDT 1999
>Closed-Date:    Tue Oct 25 13:48:24 GMT 2005
>Last-Modified:  Tue Oct 25 13:48:24 GMT 2005
>Originator:     Phillip Musumeci
>Release:        FreeBSD 3.2 RELEASE
>Organization:
RMIT University
>Environment:
FreeBSD josephine.net.at.home 3.2-RELEASE FreeBSD 3.2-RELEASE #0: Sat Jul 24 23:54:55 EST 1999     phillip@josephine.net.at.home:/usr/src/sys/compile/barton  i386

>Description:
I was getting errors messages from the ahc driver, for a card that was
probed as

ahc0: <Adaptec 2940 Ultra SCSI adapter> rev 0x00 int a irq 11 on pci0.8.0
ahc0: aic7880 Wide Channel A, SCSI Id=7, 16/255 SCBs

(adaptec 2940UW) and with a Seagate SCSI UW disk probed as

da0: <SEAGATE ST36530W 1487> Fixed Direct Access SCSI-2 device 
da0: 40.000MB/s transfers (20.000MHz, offset 8, 16bit), Tagged Queueing Enabled
da0: 6208MB (12715920 512 byte sectors: 255H 63S/T 791C)

I found that these warning messages could be stopped by making sure
that the PC BIOS allocated a unique interrupt to the PCI SCSI adaptec
card.  Previously, the BIOS was allocating the same interrupt to the
apdaptec card as was being allocated to some other PCI cards.

>How-To-Repeat:
With the adaptec 2940UW card sharing an IRQ with other cards: the kernel
warning messages appear.

>Fix:
Configure your PC's BIOS to have at least two IRQs allocated to the PCI
bus if you have a 2940UW and other PCI cards needing an IRQ.  In my
case, my FIC VA503+ motherboard's bios will then allocate an IRQ for 
sole use by the 2940UW card and all is fine.

Hope this helps others.



>Release-Note:
>Audit-Trail:
Responsible-Changed-From-To: freebsd-bugs->gibbs 
Responsible-Changed-By: ken 
Responsible-Changed-When: Wed Aug 11 12:03:37 PDT 1999 
Responsible-Changed-Why:  
Justin wrote the Adaptec driver, and will probably want to look at this. 
State-Changed-From-To: open->feedback 
State-Changed-By: gibbs 
State-Changed-When: Sat Feb 24 12:10:09 PST 2001 
State-Changed-Why:  
I don't know why sharing interrupts would have any effect on parity errors. 
Is this problem still reproduceable with newer revs of the driver? 

http://www.freebsd.org/cgi/query-pr.cgi?pr=12993 

From: Stefan Moeding <s.moeding@setuid.de>
To: freebsd-gnats-submit@FreeBSD.org
Cc:  
Subject: Re: i386/12993: "ahc0: Data Parity Error Detected during address or write data phase" kernel message
Date: 20 Sep 2002 16:02:49 +0200

 Hi!
 
 This pr is a bit older, but we are getting the exact message with a
 current setup:
 
 * FreeBSD 4.7-PRERELEASE
 * da0: <FUJITSU MAN3184MP 0109> connected to
   ahc_pci0: <Adaptec 19160B Ultra160 SCSI adapter>
 * ad0: 76319MB <ST380021A> [155061/16/63] at ata0-master UDMA100
   connected to the internal atapci0: <VIA 82C686 ATA100 controller>
 * According to vmstat no interrupts are shared:
 
 ,----[ vmstat -i ]
 | interrupt                   total       rate
 | ata0 irq14                  89674        110
 | fxp0 irq2                     857          1
 | fxp1 irq10                    386          0
 | ahc_pci0 irq11                10314         12
 | fdc0 irq6                       1          0
 | clk irq0                    81219        100
 | rtc irq8                   103986        128
 | Total                      286437        352
 `----
 
 I can trigger the messages instantly by copying data (tar or dump)
 from ad0 to da0.  I *can't* reproduce the messages by using da0 alone
 (e.g. dd if=/dev/zero of=..).  The messages also stopped after
 switching ad0 from DMA to PIO (hw.ata.ata_dma="0" in
 /boot/loader.conf), so it looks as if the ATA controller seems to be
 part of the problem.  The complete dmesg output is attached below.
 
 The machine is connected to the internet and currently not in use, so
 we might be able to supply some debugging support.  Feel free to
 contact me.
 
 Stefan
 
 ==============================================================================
 
 Copyright (c) 1992-2002 The FreeBSD Project.
 Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
 	The Regents of the University of California. All rights reserved.
 FreeBSD 4.7-PRERELEASE #0: Fri Sep 20 15:22:22 CEST 2002
     root@yuma.hostsharing.net:/usr/obj/usr/src/sys/YUMA
 Timecounter "i8254"  frequency 1193182 Hz
 CPU: Pentium III/Pentium III Xeon/Celeron (1130.12-MHz 686-class CPU)
   Origin = "GenuineIntel"  Id = 0x6b1  Stepping = 1
   Features=0x383fbff<FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,MMX,FXSR,SSE>
 real memory  = 1073676288 (1048512K bytes)
 avail memory = 1042223104 (1017796K bytes)
 Programming 24 pins in IOAPIC #0
 IOAPIC #0 intpin 2 -> irq 0
 FreeBSD/SMP: Multiprocessor motherboard
  cpu0 (BSP): apic id:  0, version: 0x00040011, at 0xfee00000
  cpu1 (AP):  apic id:  1, version: 0x00040011, at 0xfee00000
  io0 (APIC): apic id:  2, version: 0x00178011, at 0xfec00000
 Preloaded elf kernel "kernel" at 0xc02d0000.
 Pentium Pro MTRR support enabled
 Using $PIR table, 11 entries at 0xc00fde00
 apm0: <APM BIOS> on motherboard
 apm: found APM BIOS v1.2, connected at v1.2
 npx0: <math processor> on motherboard
 npx0: INT 16 interface
 pcib0: <Host to PCI bridge> on motherboard
 IOAPIC #0 intpin 12 -> irq 2
 pci0: <PCI bus> on pcib0
 pcib1: <VIA 82C598MVP (Apollo MVP3) PCI-PCI (AGP) bridge> at device 1.0 on pci0
 pci1: <PCI bus> on pcib1
 pci0: <ATI Mach64-GR graphics accelerator> at 6.0
 isab0: <VIA 82C686 PCI-ISA bridge> at device 7.0 on pci0
 isa0: <ISA bus> on isab0
 atapci0: <VIA 82C686 ATA100 controller> port 0xd400-0xd40f at device 7.1 on pci0
 ata0: at 0x1f0 irq 14 on atapci0
 ata1: at 0x170 irq 15 on atapci0
 viapropm0: SMBus I/O base at 0x5000
 viapropm0: <VIA VT82C686A Power Management Unit> port 0x5000-0x500f at device 7.4 on pci0
 viapropm0: SMBus revision code 0x40
 smb0: <SMBus general purpose I/O> on smbus0
 fxp0: <Intel Pro 10/100B/100+ Ethernet> port 0xe000-0xe03f mem 0xf6000000-0xf60fffff,0xf6202000-0xf6202fff irq 2 at device 13.0 on pci0
 fxp0: Ethernet address 00:e0:81:22:3b:9c
 inphy0: <i82555 10/100 media interface> on miibus0
 inphy0:  10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto
 fxp1: <Intel Pro 10/100B/100+ Ethernet> port 0xe400-0xe43f mem 0xf6100000-0xf61fffff,0xf6201000-0xf6201fff irq 10 at device 14.0 on pci0
 fxp1: Ethernet address 00:e0:81:22:3b:9d
 inphy1: <i82555 10/100 media interface> on miibus1
 inphy1:  10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto
 ahc_pci0: <Adaptec 19160B Ultra160 SCSI adapter> port 0xe800-0xe8ff mem 0xf6203000-0xf6203fff irq 11 at device 17.0 on pci0
 aic7892: Ultra160 Wide Channel A, SCSI Id=7, 32/253 SCBs
 orm0: <Option ROM> at iomem 0xc0000-0xc7fff on isa0
 atkbdc0: <Keyboard controller (i8042)> at port 0x60,0x64 on isa0
 sc0: <System console> at flags 0x100 on isa0
 sc0: VGA <12 virtual consoles, flags=0x300>
 vga0: <Generic ISA VGA> at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0
 sio0 at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0
 sio0: type 16550A
 sio1 at port 0x2f8-0x2ff irq 3 on isa0
 sio1: type 16550A
 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
 APIC_IO: Testing 8254 interrupt delivery
 APIC_IO: routing 8254 via IOAPIC #0 intpin 2
 IP packet filtering initialized, divert disabled, rule-based forwarding enabled, default to deny, unlimited logging
 SMP: AP CPU #1 Launched!
 ad0: 76319MB <ST380021A> [155061/16/63] at ata0-master UDMA100
 Waiting 2 seconds for SCSI devices to settle
 da0 at ahc0 bus 0 target 15 lun 0
 da0: <FUJITSU MAN3184MP 0109> Fixed Direct Access SCSI-3 device 
 da0: 160.000MB/s transfers (80.000MHz, offset 127, 16bit), Tagged Queueing Enabled
 da0: 17522MB (35885448 512 byte sectors: 255H 63S/T 2233C)
 Mounting root from ufs:/dev/da0s1a
 ahc_pci0: PCI error Interrupt at seqaddr = 0x89
 ahc_pci0: Data Parity Error Detected during address or write data phase
 ahc_pci0: PCI error Interrupt at seqaddr = 0x8
 ahc_pci0: Data Parity Error Detected during address or write data phase
 ahc_pci0: PCI error Interrupt at seqaddr = 0x53
 ahc_pci0: Data Parity Error Detected during address or write data phase
 
State-Changed-From-To: feedback->suspended 
State-Changed-By: linimon 
State-Changed-When: Sun Oct 23 18:25:54 GMT 2005 
State-Changed-Why:  
Feedback was received long ago.  Mark 'suspended' since nothing seems to 
have been done about this. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=12993 
State-Changed-From-To: suspended->closed 
State-Changed-By: gibbs 
State-Changed-When: Tue Oct 25 13:39:38 GMT 2005 
State-Changed-Why:  
These messages are caused by the Adaptec controller noticing incorrect 
parity on the address phase of PCI transactions.  These warnings indicate 
that some other device, often the motherboard chipset, is not following 
the PCI spec.  Recent changes to the driver cause the errors to be 
reported only once when this occurs, so the user is notified, but not 
flooded by messages. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=12993 
>Unformatted:
