All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Michael S. Zick" <lkml@morethan.org>
To: Chris Pringle <chris.pringle@oxtel.com>
Cc: linux-kernel@vger.kernel.org
Subject: Re: PowerPC PCI DMA issues (prefetch/coherency?)
Date: Tue, 16 Jun 2009 09:16:25 -0500	[thread overview]
Message-ID: <200906160916.28430.lkml@morethan.org> (raw)
In-Reply-To: <4A37A503.3030209@oxtel.com>

On Tue June 16 2009, Chris Pringle wrote:
> Hello All,
> 
> We're developing on a Freescale MPC8272 and are having some nasty 
> problems with PCI bus mastering and data corruption.
> 
> We have some custom hardware that is bus mastering, reading data from 
> the CPUs memory for it's own use. Most of the time, the data is correct, 
> however occasionally we are seeing data that appears to be from 
> somewhere else in memory (usually memory that has already been read by 
> the PCI device). The problem looks like stale data on the PCI bridge 
> prefetch buffers or a cache coherency problem, but we've been unable to 
> come up with a solution to our problem. It is my understanding that it 
> shouldn't be a cache coherency problem as the CPU cache should be 
> snooped as the data is read from memory. Even if it were an issue, the 
> pci_map_sg* functions should have sorted out any cache coherency issues 
> before the DMA operation started.
> 
> I've not been able to find anything on the Freescale data sheet that 
> provides any way of flushing the prefetch cache on the PCI bridge. We've 
> done a bit of experimenting, and found that turning off prefetch appears 
> to solve (or possibly mask?) the problem (at the expensive of massive 
> performance problems). I've also tried DMA'ing two adjacent userspace 
> buffers in memory (from the same page), and see corruption on the second 
> buffer. If I populate both buffers, then DMA them both, the data is 
> fine. If I populate the first, DMA the first, then populate the second 
> and DMA the second, corruption occurs at the start of the second buffer. 
> If I add 8-32 bytes of padding between the buffers, the problem goes away.
> 
> The PCI spec says that the PCI bridge is supposed to flush any data from 
> it's prefetch buffers that are not read by the bus master, so 
> technically, this isn't supposed to happen.
> 
> I've tried making sure that buffers are cache line (and page) aligned, 
> and are multiples of cache lines, but it's made no difference. PIO mode 
> works fine, and I've checked the data with the CPU just before, and 
> immediately after the DMA and the driver sees no data integrity issues. 
> There are memory write barriers just before the DMA start, so all the 
> registers should be correct before the DMA starts.
> 
> For background info, the device doing the bus mastering is a Xilinx 
> Virtex 5 FPGA. We've monitored the data as it comes off the PCI bus 
> using ChipScope - so the firmware should not be manipulating the data in 
> any way.
> 
> We have some hardware/firmware/drivers that has a lot of common code 
> that runs on an x86 platform (as opposed to powerpc), and that works 
> without any issues whatsoever.
> 
> Has anyone got any ideas what this might be? Does anyone of know issues 
> with PCI bridges on the PowerPC platform? Is there extra things that 
> need to be done from the driver when DMAing on PowerPC (I've looked at 
> other drivers and there's nothing obvious). The chip errata doesn't have 
> anything on it that looks like it could cause this.
> 
> I'm really hoping this is something that we're doing wrong in the driver 
> or the firmware, but we've been through both the firmware and drivers 
> countless times and are unable to see anything wrong.
> 
> Any thoughts/ideas would be much appreciated!
> 

Did you actually check the load image for proper alignment?
Like in:

gen2-32 compressed # objdump -x vmlinux.bin
- - - - -
Sections:
Idx Name          Size      VMA       LMA       File off  Algn
- - - - -
 21 .data.page_aligned 00001800  c068a000  0068a000  0058b000  2**12
                  CONTENTS, ALLOC, LOAD, DATA
 22 .data.cacheline_aligned 000026c0  c068b800  0068b800  0058c800  2**6
                  CONTENTS, ALLOC, LOAD, DATA
 23 .data.read_mostly 00001e98  c068dec0  0068dec0  0058eec0  2**6
                  CONTENTS, ALLOC, LOAD, DATA

= = = =

I had to make this change to the x86 loader script to get alignment for VIA:

diff --git a/arch/x86/kernel/vmlinux_32.lds.S b/arch/x86/kernel/vmlinux_32.lds.S
index 62ad500..26f68a5 100644
--- a/arch/x86/kernel/vmlinux_32.lds.S
+++ b/arch/x86/kernel/vmlinux_32.lds.S
@@ -82,7 +82,7 @@ SECTIONS
        *(.data.idt)
   }

-  . = ALIGN(32);
+  . = ALIGN(L1_CACHE_BYTES);
   .data.cacheline_aligned : AT(ADDR(.data.cacheline_aligned) - LOAD_OFFSET) {
        *(.data.cacheline_aligned)
   }

= = = =

Eyeball your loader script if you haven't already done so.

Mike
> Regards,
> Chris
> 



  reply	other threads:[~2009-06-16 14:16 UTC|newest]

Thread overview: 36+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-06-16 13:58 PowerPC PCI DMA issues (prefetch/coherency?) Chris Pringle
2009-06-16 14:16 ` Michael S. Zick [this message]
2009-06-16 14:59 ` Hu Gang
2009-06-16 16:21 ` Scott Wood
2009-06-16 16:34   ` Chris Pringle
2009-06-16 16:46     ` Scott Wood
2009-06-16 16:46       ` Scott Wood
2009-06-16 16:57       ` Chris Pringle
2009-06-16 16:57         ` Chris Pringle
2009-06-16 17:03         ` Scott Wood
2009-06-16 17:03           ` Scott Wood
2009-06-16 17:43           ` Arnd Bergmann
2009-06-16 17:49             ` Scott Wood
2009-06-16 17:49               ` Scott Wood
2009-06-16 18:02               ` Arnd Bergmann
2009-06-16 18:02                 ` Arnd Bergmann
2009-06-17  0:18                 ` Benjamin Herrenschmidt
2009-06-17  0:37                   ` FUJITA Tomonori
2009-06-17  0:37                     ` FUJITA Tomonori
2009-06-17  0:56                     ` Leon Woestenberg
2009-06-17  0:56                       ` Leon Woestenberg
2009-06-17  1:08                       ` Benjamin Herrenschmidt
2009-06-17  1:08                         ` Benjamin Herrenschmidt
2009-06-17  1:13                         ` Leon Woestenberg
2009-06-17  1:13                           ` Leon Woestenberg
2009-06-17  1:07                     ` Benjamin Herrenschmidt
2009-06-17  1:07                       ` Benjamin Herrenschmidt
2009-06-17  7:58           ` Chris Pringle
2009-06-17  7:58             ` Chris Pringle
2009-06-17 13:18             ` Chris Pringle
2009-06-18 11:24               ` Chris Pringle
2009-06-22 14:31                 ` AW: " Sergej.Stepanov
2009-06-22 14:31                   ` Sergej.Stepanov
2009-06-29  8:11                   ` Chris Pringle
  -- strict thread matches above, loose matches on Subject: below --
2009-06-16 14:08 Chris Pringle
2009-06-16 15:48 ` Roderick Colenbrander

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=200906160916.28430.lkml@morethan.org \
    --to=lkml@morethan.org \
    --cc=chris.pringle@oxtel.com \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.