Bug 12993

Summary: "ahc0: Data Parity Error Detected during address or write data phase" kernel message
Product: Base System Reporter: phillip <phillip>
Component: i386Assignee: Justin T. Gibbs <gibbs>
Status: Closed FIXED    
Severity: Affects Only Me    
Priority: Normal    
Version: Unspecified   
Hardware: Any   
OS: Any   

Description phillip 1999-08-06 01:00:00 UTC 
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.

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.
How-To-Repeat: With the adaptec 2940UW card sharing an IRQ with other cards: the kernel
warning messages appear.
Comment 1 Kenneth D. Merry freebsd_committer freebsd_triage 1999-08-11 20:03:37 UTC 
Responsible Changed
From-To: freebsd-bugs->gibbs

Justin wrote the Adaptec driver, and will probably want to look at this.
Comment 2 Justin T. Gibbs freebsd_committer freebsd_triage 2001-02-24 20:10:09 UTC 
State Changed
From-To: open->feedback

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?
Comment 3 s.moeding 2002-09-20 15:02:49 UTC 
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
Comment 4 Mark Linimon freebsd_committer freebsd_triage 2005-10-23 19:25:54 UTC 
State Changed
From-To: feedback->suspended

Feedback was received long ago.  Mark 'suspended' since nothing seems to 
have been done about this.
Comment 5 Justin T. Gibbs freebsd_committer freebsd_triage 2005-10-25 14:39:38 UTC 
State Changed
From-To: suspended->closed

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.