rivers use the DMA API, however if
> > > compiled under 32-bit an very important part of the DMA API can
> > > be ommitted leading to the drivers not working at all
> > > (especially if used with 'swiotlb=force iommu=soft').
...
> > > As such enable this eve
Prashant Sreedharan writes ("Re: tg3 NIC driver bug in 3.14.x under Xen [and 3
more messages]"):
> Ok this is what is causing the problem, the driver uses
> DEFINE_DMA_UNMAP_ADDR(), dma_unmap_addr_set() to keep a copy of the dma
> "mapping" and dma_unmap_addr() to get the "mapping" value. On most
Michael Chan writes ("Re: tg3 NIC driver bug in 3.14.x under Xen [and 3 more
messages]"):
> On Thu, 2015-04-16 at 09:24 -0300, casca...@linux.vnet.ibm.com wrote:
> > Yes, this looks like the driver is not syncing the DMA buffers. Unmap is
> > supposed to synchronize as well.
>
> For small rx pac
Prashant writes ("Re: tg3 NIC driver bug in 3.14.x under Xen [and 3 more
messages]"):
> Ian, using your config we are able to recreate the problem that you are
> seeing. The driver finds the RX data buffer to be all zero, with a
> analyzer trace we are seeing the chip is DMA'ing valid RX data bu
Prashant writes ("Re: tg3 NIC driver bug in 3.14.x under Xen [and 3 more
messages]"):
> I tried to reproduce the problem on 32 bit 3.14.34 stable kernel
> baremetal, with iommu=soft swiotlb=force but no luck, no drops or
> errors. I did not try with Xen 64 bit yet. Btw I need a pcie analyzer
>
