lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Wed, 15 Apr 2015 19:53:16 -0700 From: Prashant <prashant@...adcom.com> To: Ian Jackson <Ian.Jackson@...citrix.com>, Michael Chan <mchan@...adcom.com> CC: Konrad Rzeszutek Wilk <konrad.wilk@...cle.com>, Boris Ostrovsky <boris.ostrovsky@...cle.com>, David Vrabel <david.vrabel@...rix.com>, Thadeu Lima de Souza Cascardo <cascardo@...ux.vnet.ibm.com>, Vlad Yasevich <vyasevich@...il.com>, <xen-devel@...ts.xensource.com>, <netdev@...r.kernel.org>, "Siva Reddy (Siva) Kallam" <siva.kallam@...adcom.com>, Sanjeev Bansal <sanjeevb@...adcom.com> Subject: Re: tg3 NIC driver bug in 3.14.x under Xen [and 3 more messages] 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. -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists