On Wed, 2015-04-29 at 13:34 -0400, Toan Pham wrote:
> Prashant,
>
> Unfortunately, I ran the same test 3 times with the new patch and all
> of them failed.
> Attached file is the dmesg log, after the Watchdog had timed out, and
> tried to restart the NIC.
> Feel free to let me know if you would li
On Tue, 2015-04-28 at 16:06 -0400, Toan Pham wrote:
> > We were able to reproduce this issue internally only with iommu enabled.
>
> My last test to collect lspci-info took about 5 hours over a gigabit
> network for the bug to show up. My setup was running 3 tx scp
> sessions, each transferring a
e able to
reproduce the problem ? This patch will restrict all DMA address given
to the chip to 31 bits.
Toan, thanks for bringing this to our notice, also please cc maintainers
so that mails are not missed.
>From 488fd699985f73d361d04d4788de48833c6442ca Mon Sep 17 00:00:00 2001
From: Prashant Sreed
+ /* We needn't recover from permanent error */
> + if (state == pci_channel_io_frozen)
> + tp->pcierr_recovery = true;
>
> /* We probably don't have netdev yet */
> if (!netdev || !netif_running(netdev))
Acked-by: Prashant Sreedharan
--
To un
orking at all (especially if used with
> > 'swiotlb=force iommu=soft').
> >
> > As Prashant Sreedharan explains it: "the driver [tg3] uses
> > DEFINE_DMA_UNMAP_ADDR(), dma_unmap_addr_set() to keep a copy of the dma
> > "mapping" and dma_unm
On Thu, 2015-04-16 at 18:15 +0100, Ian Jackson wrote:
> 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
