Inbound PCI and Memory Corruption

[Peter LaDow]

On Tue, Jul 23, 2013 at 9:27 PM, Benjamin Herrenschmidt
<benh at kernel.crashing.org> wrote:
> CONFIG_NOT_COHERENT_CACHE will do it for you (in
> arch/powerpc/kernel/dma.c) provided the driver does the right things vs.
> the DMA accessors but afaik e1000 does.

Well, when I went to make the changes I noted a few things.  First,
the e1000 driver does a dma_unmap_single() prior to processing the
descriptor.  So it would seem that the dma_sync_single_for_cpu() isn't
necessary in that case.  And when allocating descriptors, it does
dma_map_single() after setting up the descriptor, so
dma_sync_single_for_device() probably isn't necessary either.

But regardless, I put in the dma_sync_single_* calls and we still get
the same behavior.  So, even with CONFIG_NOT_COHERENT_CACHE we are
getting this error.

> If that helps, that might hint at either a missing barrier or some kind
> of HW (or HW configuration) bug with cache coherency.

And unfortunately it didn't help.  We have a few other things we are
trying, but I'm not hopeful that any will change the behavior.

A bit of history that may help.  We were using an e100 (an 82559)
part, but Intel EOL'd that part so we picked up the 82540EP (which
they have also recently EOL'd).  The e100 driver uses a different DMA
model.  It uses pci_map_single/pci_unmap_single along with
pci_dma_sync_single_for* calls (as well as other PCI calls).  The
e1000 driver, however, does not use the pci_* calls.  We have never
had a problem with the e100 parts.  I don't suppose the use of
pci_map_* vs dma_map_* makes a difference does it?

Thanks,
Pete