Re: cx88 pci_abort messages

2007-10-08 Thread Scott


On Oct 8, 2007, at 3:44 AM, Gerd Hoffmann wrote:


Scott wrote:

On Sat, 2007-10-06 at 12:48 -0600, Robert Hancock wrote:

Oct  2 21:59:32 htpc cx88[0]: irq mpeg  [0x8] pci_abort*
Oct  2 21:59:32 htpc cx88[0]/2-mpeg: general errors: 0x0008000


I assumed it was an interrupt issue based on the 'irq mepg' error,  
not a

DMA issue.


It's a DMA issue.  The chip raised an irq to signal the error  
condition

to the driver, thats why it is printed by the irq handler.  Happened
while streamimg mpeg data.

Havn't looked at the code for years now, but IIRC the 0x80 is the
raw error code from some status register, pci_abort is the error  
bit in

clear text, meaning some PCI DMA transfer was aborted.  No idea why
though ...


I went through and did the basics. Disabled SMP (it's a core 2 duo  
cpu), tried with noapic, nolapic settings, tried with pci=irqroute,  
and tried with acpi=off. Poking through the module code I noticd in  
cx88-mpeg.c the irq_debug option. I think this is the debug switch I  
want so I'll try to gather more info this week. At the very least it  
looks like it will help me walk through the code to get a better idea  
of what's going on.


--
Scott

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: cx88 pci_abort messages

2007-10-08 Thread Gerd Hoffmann
Scott wrote:
> On Sat, 2007-10-06 at 12:48 -0600, Robert Hancock wrote:
 Oct  2 21:59:32 htpc cx88[0]: irq mpeg  [0x8] pci_abort*
 Oct  2 21:59:32 htpc cx88[0]/2-mpeg: general errors: 0x0008000

> I assumed it was an interrupt issue based on the 'irq mepg' error, not a
> DMA issue.

It's a DMA issue.  The chip raised an irq to signal the error condition
to the driver, thats why it is printed by the irq handler.  Happened
while streamimg mpeg data.

Havn't looked at the code for years now, but IIRC the 0x80 is the
raw error code from some status register, pci_abort is the error bit in
clear text, meaning some PCI DMA transfer was aborted.  No idea why
though ...

cheers,
  Gerd
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: cx88 pci_abort messages

2007-10-06 Thread Scott
On Sat, 2007-10-06 at 12:48 -0600, Robert Hancock wrote:
> > On Oct 4, 2007, at 11:52 AM, Scott wrote:
> > 
> >> I'm having what I think is a PCI bus problem.
> >>
> >> I have a ASUS P5B Intel 965 motherboard and a DVICO Fusion HDTV5 RT
> >> adapter on the PCI bus. When this adapter is recording (anything) I see
> >> Oct  2 21:59:12 htpc cx88[0]: irq mpeg  [0x8] pci_abort*
> >> Oct  2 21:59:12 htpc cx88[0]/2-mpeg: general errors: 0x0008
> >> Oct  2 21:59:20 htpc cx88[0]: irq mpeg  [0x8] pci_abort*
> >> Oct  2 21:59:20 htpc cx88[0]/2-mpeg: general errors: 0x0008
> >> Oct  2 21:59:32 htpc cx88[0]: irq mpeg  [0x8] pci_abort*
> >> Oct  2 21:59:32 htpc cx88[0]/2-mpeg: general errors: 0x0008000
> >
> PCI aborts won't have anything to do with interrupts. It's a PCI DMA 
> transfer that either the initiator (here, the TV card) or the target 
> (the chipset host bridge) decided to puke on for some reason. Possibly 
> parity errors?

I assumed it was an interrupt issue based on the 'irq mepg' error, not a
DMA issue. Any suggestions on how to log more information about PCI DMA
events on a system wide basis? 

I've seen this since 2.6.18.

-- 
Scott <[EMAIL PROTECTED]>

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: cx88 pci_abort messages

2007-10-06 Thread Robert Hancock

Scott wrote:


On Oct 4, 2007, at 11:52 AM, Scott wrote:


I'm having what I think is a PCI bus problem.

I have a ASUS P5B Intel 965 motherboard and a DVICO Fusion HDTV5 RT
adapter on the PCI bus. When this adapter is recording (anything) I see
pci_abort messages repeating in the /var/log/messages file. As a result
I see some minor video corruption during playback. I've installed the
adapter into a PCI slot that shares an IRQ with the onboard USB.
However, I've also disabled all USB support in BIOS, so the adapter is
the only thing on the IRQ, and still see the same errors.

Any suggestions for further troubleshooting? Is this a PCI bus quirk on
this motherboard? A copy of my .config is at
http://donpoo.net/kernel_config

Oct  2 21:59:12 htpc cx88[0]: irq mpeg  [0x8] pci_abort*
Oct  2 21:59:12 htpc cx88[0]/2-mpeg: general errors: 0x0008
Oct  2 21:59:20 htpc cx88[0]: irq mpeg  [0x8] pci_abort*
Oct  2 21:59:20 htpc cx88[0]/2-mpeg: general errors: 0x0008
Oct  2 21:59:32 htpc cx88[0]: irq mpeg  [0x8] pci_abort*
Oct  2 21:59:32 htpc cx88[0]/2-mpeg: general errors: 0x0008000


I was poking around the PCI bus with setpci/lspci last night and tried 
adjusting the latency from 64 to 32. This didn't make a difference. I 
also changed my core2duo speedstep governor from ondemand to performance 
to prevent the CPUs from changing speed. I eventualy saw the same 
pci_abort message but I might have seen less of them.


Is there a way to log every device pci device that throws an interrupt? 
I'm thinking if I could find out which pci device was stealing the 
interrupt that I could disable it or look at the code and see what it 
was doing.


PCI aborts won't have anything to do with interrupts. It's a PCI DMA 
transfer that either the initiator (here, the TV card) or the target 
(the chipset host bridge) decided to puke on for some reason. Possibly 
parity errors?


--
Robert Hancock  Saskatoon, SK, Canada
To email, remove "nospam" from [EMAIL PROTECTED]
Home Page: http://www.roberthancock.com/

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: cx88 pci_abort messages

2007-10-05 Thread Scott


On Oct 4, 2007, at 11:52 AM, Scott wrote:


I'm having what I think is a PCI bus problem.

I have a ASUS P5B Intel 965 motherboard and a DVICO Fusion HDTV5 RT
adapter on the PCI bus. When this adapter is recording (anything) I  
see
pci_abort messages repeating in the /var/log/messages file. As a  
result

I see some minor video corruption during playback. I've installed the
adapter into a PCI slot that shares an IRQ with the onboard USB.
However, I've also disabled all USB support in BIOS, so the adapter is
the only thing on the IRQ, and still see the same errors.

Any suggestions for further troubleshooting? Is this a PCI bus  
quirk on

this motherboard? A copy of my .config is at
http://donpoo.net/kernel_config

Oct  2 21:59:12 htpc cx88[0]: irq mpeg  [0x8] pci_abort*
Oct  2 21:59:12 htpc cx88[0]/2-mpeg: general errors: 0x0008
Oct  2 21:59:20 htpc cx88[0]: irq mpeg  [0x8] pci_abort*
Oct  2 21:59:20 htpc cx88[0]/2-mpeg: general errors: 0x0008
Oct  2 21:59:32 htpc cx88[0]: irq mpeg  [0x8] pci_abort*
Oct  2 21:59:32 htpc cx88[0]/2-mpeg: general errors: 0x0008000


I was poking around the PCI bus with setpci/lspci last night and  
tried adjusting the latency from 64 to 32. This didn't make a  
difference. I also changed my core2duo speedstep governor from  
ondemand to performance to prevent the CPUs from changing speed. I  
eventualy saw the same pci_abort message but I might have seen less  
of them.


Is there a way to log every device pci device that throws an  
interrupt? I'm thinking if I could find out which pci device was  
stealing the interrupt that I could disable it or look at the code  
and see what it was doing.


--
Scott 
-

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


cx88 pci_abort messages

2007-10-04 Thread Scott
I'm having what I think is a PCI bus problem.

I have a ASUS P5B Intel 965 motherboard and a DVICO Fusion HDTV5 RT
adapter on the PCI bus. When this adapter is recording (anything) I see
pci_abort messages repeating in the /var/log/messages file. As a result
I see some minor video corruption during playback. I've installed the
adapter into a PCI slot that shares an IRQ with the onboard USB.
However, I've also disabled all USB support in BIOS, so the adapter is
the only thing on the IRQ, and still see the same errors. 

Any suggestions for further troubleshooting? Is this a PCI bus quirk on
this motherboard? A copy of my .config is at
http://donpoo.net/kernel_config

Oct  2 21:59:12 htpc cx88[0]: irq mpeg  [0x8] pci_abort*
Oct  2 21:59:12 htpc cx88[0]/2-mpeg: general errors: 0x0008
Oct  2 21:59:20 htpc cx88[0]: irq mpeg  [0x8] pci_abort*
Oct  2 21:59:20 htpc cx88[0]/2-mpeg: general errors: 0x0008
Oct  2 21:59:32 htpc cx88[0]: irq mpeg  [0x8] pci_abort*
Oct  2 21:59:32 htpc cx88[0]/2-mpeg: general errors: 0x0008

htpc ~ # uname -a
Linux htpc 2.6.22.1 #4 SMP PREEMPT Tue Oct 2 04:15:40 EDT 2007 i686
Intel(R) Core(TM)2 CPU 6600 @ 2.40GHz GenuineIntel GNU/Linux

htpc ~ # lspci -v 
00:00.0 Host bridge: Intel Corporation Memory Controller Hub (rev 02)
Subsystem: ASUSTeK Computer Inc. Unknown device 81ea
Flags: bus master, fast devsel, latency 0
Capabilities: [e0] Vendor Specific Information

00:01.0 PCI bridge: Intel Corporation PCI Express Root Port (rev 02)
(prog-if 00 [Normal decode])
Flags: bus master, fast devsel, latency 0
Bus: primary=00, secondary=01, subordinate=01, sec-latency=0
I/O behind bridge: b000-bfff
Memory behind bridge: f490-f89f
Prefetchable memory behind bridge:
bfe0-dfdf
Capabilities: [88] Subsystem: Intel Corporation Unknown device
277d
Capabilities: [80] Power Management version 3
Capabilities: [90] Message Signalled Interrupts: Mask- 64bit-
Queue=0/0 Enable-
Capabilities: [a0] Express Root Port (Slot+) IRQ 0

00:1a.0 USB Controller: Intel Corporation USB UHCI Controller #4 (rev
02) (prog-if 00 [UHCI])
Subsystem: ASUSTeK Computer Inc. Unknown device 81ec
Flags: bus master, medium devsel, latency 0, IRQ 16
I/O ports at e000 [size=32]

00:1a.1 USB Controller: Intel Corporation USB UHCI Controller #5 (rev
02) (prog-if 00 [UHCI])
Subsystem: ASUSTeK Computer Inc. Unknown device 81ec
Flags: bus master, medium devsel, latency 0, IRQ 21
I/O ports at e080 [size=32]

00:1a.7 USB Controller: Intel Corporation USB2 EHCI Controller #2 (rev
02) (prog-if 20 [EHCI])
Subsystem: ASUSTeK Computer Inc. Unknown device 81ec
Flags: bus master, medium devsel, latency 0, IRQ 18
Memory at febff400 (32-bit, non-prefetchable) [size=1K]
Capabilities: [50] Power Management version 2
Capabilities: [58] Debug port

00:1b.0 Audio device: Intel Corporation HD Audio Controller (rev 02)
Subsystem: ASUSTeK Computer Inc. Unknown device 81ec
Flags: bus master, fast devsel, latency 0, IRQ 20
Memory at febf8000 (64-bit, non-prefetchable) [size=16K]
Capabilities: [50] Power Management version 2
Capabilities: [60] Message Signalled Interrupts: Mask- 64bit+
Queue=0/0 Enable-
Capabilities: [70] Express Unknown type IRQ 0

00:1c.0 PCI bridge: Intel Corporation PCI Express Port 1 (rev 02)
(prog-if 00 [Normal decode])
Flags: bus master, fast devsel, latency 0
Bus: primary=00, secondary=03, subordinate=03, sec-latency=0
Prefetchable memory behind bridge:
dfe0-dfef
Capabilities: [40] Express Root Port (Slot+) IRQ 0
Capabilities: [80] Message Signalled Interrupts: Mask- 64bit-
Queue=0/0 Enable-
Capabilities: [90] Subsystem: ASUSTeK Computer Inc. Unknown
device 81ec
Capabilities: [a0] Power Management version 2

00:1c.3 PCI bridge: Intel Corporation PCI Express Port 4 (rev 02)
(prog-if 00 [Normal decode])
Flags: bus master, fast devsel, latency 0
Bus: primary=00, secondary=02, subordinate=02, sec-latency=0
I/O behind bridge: c000-cfff
Memory behind bridge: f8a0-f8af
Capabilities: [40] Express Root Port (Slot+) IRQ 0
Capabilities: [80] Message Signalled Interrupts: Mask- 64bit-
Queue=0/0 Enable-
Capabilities: [90] Subsystem: ASUSTeK Computer Inc. Unknown
device 81ec
Capabilities: [a0] Power Management version 2

00:1d.0 USB Controller: Intel Corporation USB UHCI Controller #1 (rev
02) (prog-if 00 [UHCI])
Subsystem: ASUSTeK Computer Inc. Unknown device 81ec
Flags: bus master, medium devsel, latency 0, IRQ 19
I/O ports at d800 [size=32]

00:1d.1 USB Controller: Intel Corporation USB UHCI Controller #2 (