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 like to
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 1GB
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 Sreedharan prash...@broadcom.com
Date: Tue, 28 Apr 2015 11:32:56 -0700
Subject: [PATCH] tg3: Restrict DMA address to 31 bits
;
/* We probably don't have netdev yet */
if (!netdev || !netif_running(netdev))
Acked-by: Prashant Sreedharan prash...@broadcom.com
--
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to majord...@vger.kernel.org
More majordomo info at http
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_unmap_addr() to get the mapping value. On most of
the platforms this is a no-op, but ... with iommu=soft
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 is
