[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1307063914.3656.22.camel@x201>
Date: Thu, 02 Jun 2011 19:18:34 -0600
From: Alex Williamson <alex.williamson@...hat.com>
To: Matt Carlson <mcarlson@...adcom.com>
Cc: "davem@...emloft.net" <davem@...emloft.net>,
"netdev@...r.kernel.org" <netdev@...r.kernel.org>
Subject: Re: [net-next,02/13] tg3: Cleanup transmit error path
On Thu, 2011-06-02 at 16:01 -0700, Matt Carlson wrote:
> On Thu, Jun 02, 2011 at 03:18:35PM -0700, Alex Williamson wrote:
> > On Thu, 2011-05-19 at 12:12 +0000, Matt Carlson wrote:
> > > This patch consolidates the skb cleanup code into a function named
> > > tg3_skb_error_unmap(). The modification addresses a long-standing bug
> > > where pci_unmap_single() was incorrectly being called instead of
> > > pci_unmap_page() in tigon3_dma_hwbug_workaround().
> >
> > This patch doesn't behave well when an iommu (VT-d) is involved.
> > Booting an X58 chipset based system with intel_iommu=on with 3.0.0-rc1
> > results in the warning below. Looks like the driver is trying to unmap
> > 0x0. Eventually something worse happens and the system reports a few
> > iommu faults from the device before panicing. Neither problem is
> > observed if 432aa7ed is reverted. tg3 device in use is a BCM5755.
> > Thanks,
> >
> > Alex
> >
> > WARNING: at drivers/pci/intel-iommu.c:2888 intel_unmap_page+0x15c/0x180()
> > Hardware name: 4157CTO
> > Driver unmaps unmatched page at PFN 0
> > Modules linked in: nfs lockd auth_rpcgss nfs_acl ipt_MASQUERADE iptable_nat nf_nat iptable_mangle tun autofs4 sunrpc cpufreq_ondemand acpi_cpufreq freq_table mperf bridge stp llc ipv6 dm_mirror dm_region_hash dm_log kvm_intel kvm sg microcode serio_raw wmi i2c_i801 i2c_core iTCO_wdt iTCO_vendor_support tg3 ext4 mbcache jbd2 raid1 raid456 async_pq async_xor xor async_memcpy async_raid6_recov raid6_pq async_tx sr_mod cdrom sd_mod crc_t10dif floppy dm_mod [last unloaded: scsi_wait_scan]
> > Pid: 2604, comm: libvirtd Not tainted 3.0.0-rc1+ #184
> > Call Trace:
> > [<ffffffff8105c7df>] warn_slowpath_common+0x7f/0xc0
> > [<ffffffff8105c8d6>] warn_slowpath_fmt+0x46/0x50
> > [<ffffffff81245b8b>] ? find_iova+0x5b/0xa0
> > [<ffffffff8124a60c>] intel_unmap_page+0x15c/0x180
> > [<ffffffffa0128d48>] tg3_skb_error_unmap+0xb8/0x130 [tg3]
> Does this patch fix the problem?
Yes it does, probably explains the subsequent iommu faults if that off
by one unmapping sometimes finds a non-zero address to unmap. Thanks,
Alex
Tested-by: Alex Williamson <alex.williamson@...hat.com>
> Subject: [PATCH] tg3: Fix tg3_skb_error_unmap()
>
> This function attempts to free one fragment beyond the number of
> fragments that were actually mapped. This patch brings back the limit
> to the correct spot.
>
> Signed-off-by: Matt Carlson <mcarlson@...adcom.com>
> ---
> drivers/net/tg3.c | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/net/tg3.c b/drivers/net/tg3.c
> index 8ece39b..3d239ab 100644
> --- a/drivers/net/tg3.c
> +++ b/drivers/net/tg3.c
> @@ -5771,7 +5771,7 @@ static void tg3_skb_error_unmap(struct tg3_napi *tnapi,
> dma_unmap_addr(txb, mapping),
> skb_headlen(skb),
> PCI_DMA_TODEVICE);
> - for (i = 0; i <= last; i++) {
> + for (i = 0; i < last; i++) {
> skb_frag_t *frag = &skb_shinfo(skb)->frags[i];
>
> entry = NEXT_TX(entry);
> --
> 1.7.3.4
>
>
--
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