Re: tg3 NIC driver bug in 3.14.x under Xen [and 3 more messages]

[Prashant <prashant@broadcom.com>]

On 4/15/2015 3:54 AM, Ian Jackson wrote:
> 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
>> trace to confirm the problem. Is it feasible to capture at your end ?
>
> In private correspondence with Prashant we have established that
> Prashant was using a different kernel configuration.  Prashant
> provided me with their kernel and module binaries, which work in my
> environment.
>
> I have also established that I can reproduce the problem with 3.14.37
> (`iommu=soft swiotlb=force' baremetal => all rx wholly corrupted).
>
> The kernel config I was using is here:
>    http://logs.test-lab.xenproject.org/osstest/logs/50387/build-i386-pvops/build/config
>
> As far as I am aware no-one at Broadcom has attempted a build and test
> using my kernel config.
>

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 buffer 
contents to the host but once the driver tries to read this DMA area, it 
is seeing all zero's which is the reason of the corruption. This is only 
for the RX data buffer, the RX descriptor and status block update DMA 
regions are having valid contents.

This is unlikely to be a chip or driver issue, as the chip is doing the 
correct DMA but the corruption occurs before driver reads it. Would 
request iommu experts to take a look and suggest what can be done next.

We are more than willing to try any changes in the driver, I have added 
few more team members who will work with you if needed. Thanks.