On Tue, Jul 23, 2013 at 9:27 PM, Benjamin Herrenschmidt <b...@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 _______________________________________________ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
