LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: "Matt Carlson" <mcarlson@broadcom.com>
To: tonyb@cybernetics.com
Cc: "David Miller" <davem@davemloft.net>,
	"Michael Chan" <mchan@broadcom.com>,
	"Matthew Carlson" <mcarlson@broadcom.com>,
	herbert@gondor.apana.org.au, netdev@vger.kernel.org,
	gregkh@suse.de, linux-kernel@vger.kernel.org
Subject: Re: TG3 network data corruption regression 2.6.24/2.6.23.4
Date: Wed, 16 Apr 2008 13:17:59 -0700	[thread overview]
Message-ID: <20080416201759.GB19724@localdomain> (raw)
In-Reply-To: <1551EAE59135BE47B544934E30FC4FC002AABC73@nt-irva-0751.brcm.ad.broadcom.com>

On Wed, Apr 16, 2008 at 08:40:25AM -0700, Michael Chan wrote:
> David Miller wrote:
> 
> > Matt, skb->mac_header is either a pointer or an integer offset
> > depending upon whether we are building 32-bit or 64-bit.
> > 
> > Testing skb->mac_header is therefore wrong, because it's an
> > offset from a pointer in the 64-bit case and therefore it's
> > alignment does not indicate correctly the actual final alignment
> > of skb->head + skb->max_header.
> > 
> > Therefore you should test skb_mac_header(skb) and cast it with
> > (unsigned long).
> 
> Isn't it better to test for skb->data?  That's where we tell
> the hardware to start transmitting.
> 
> > 
> > Please respin this fix with that correction so I can apply it
> > and get this bug fixed, thanks!
> > 
> > 
> 
> We think that this problem is unique in Tony's environment because
> of the PCIE-to-PCI bridge that he is using.  We therefore want to
> test for that bridge and apply the workaround only when it's present.
> We've never seen this problem in the last 6 or 7 years during the
> lifetime of the 5701.
> 
> We'll try to get this done ASAP.
> 
> Thanks.

Tony,

Below is a patch that attempts to limit the workaround to the bridge you
have on your system.  Can you test it and verify that the workaround is
still enabled?


diff --git a/drivers/net/tg3.c b/drivers/net/tg3.c
index 96043c5..52a44c6 100644
--- a/drivers/net/tg3.c
+++ b/drivers/net/tg3.c
@@ -4135,11 +4135,21 @@ static int tigon3_dma_hwbug_workaround(struct tg3 *tp, struct sk_buff *skb,
 				       u32 last_plus_one, u32 *start,
 				       u32 base_flags, u32 mss)
 {
-	struct sk_buff *new_skb = skb_copy(skb, GFP_ATOMIC);
+	struct sk_buff *new_skb;
 	dma_addr_t new_addr = 0;
 	u32 entry = *start;
 	int i, ret = 0;
 
+	if (GET_ASIC_REV(tp->pci_chip_rev_id) != ASIC_REV_5701)
+		new_skb = skb_copy(skb, GFP_ATOMIC);
+	else {
+		int more_headroom = 4 - ((unsigned long)skb->data & 3);
+
+		new_skb = skb_copy_expand(skb,
+					  skb_headroom(skb) + more_headroom,
+					  skb_tailroom(skb), GFP_ATOMIC);
+	}
+
 	if (!new_skb) {
 		ret = -1;
 	} else {
@@ -4462,7 +4472,9 @@ static int tg3_start_xmit_dma_bug(struct sk_buff *skb, struct net_device *dev)
 
 	would_hit_hwbug = 0;
 
-	if (tg3_4g_overflow_test(mapping, len))
+	if (tp->tg3_flags3 & TG3_FLG3_5701_DMA_BUG)
+		would_hit_hwbug = 1;
+	else if (tg3_4g_overflow_test(mapping, len))
 		would_hit_hwbug = 1;
 
 	tg3_set_txd(tp, entry, mapping, len, base_flags,
@@ -11339,6 +11351,41 @@ static int __devinit tg3_get_invariants(struct tg3 *tp)
 		}
 	}
 
+	if ((GET_ASIC_REV(tp->pci_chip_rev_id) == ASIC_REV_5701)) {
+		static struct tg3_dev_id {
+			u32	vendor;
+			u32	device;
+		} bridge_chipsets[] = {
+			{ PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_PXH_0 },
+			{ PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_PXH_1 },
+			{ },
+		};
+		struct tg3_dev_id *pci_id = &bridge_chipsets[0];
+		struct pci_dev *bridge = NULL;
+
+		while (pci_id->vendor != 0 &&
+		       !(tp->tg3_flags3 & TG3_FLG3_5701_DMA_BUG)) {
+			while (1) {
+				bridge = pci_get_device(pci_id->vendor,
+							pci_id->device,
+							bridge);
+				if (!bridge) {
+					pci_id++;
+					break;
+				}
+				if (bridge->subordinate &&
+				    (bridge->subordinate->number <=
+				     tp->pdev->bus->number) &&
+				    (bridge->subordinate->subordinate >=
+				     tp->pdev->bus->number)) {
+					tp->tg3_flags3 |= TG3_FLG3_5701_DMA_BUG;
+					pci_dev_put(bridge);
+					break;
+				}
+			}
+		}
+	}
+
 	/* The EPB bridge inside 5714, 5715, and 5780 cannot support
 	 * DMA addresses > 40-bit. This bridge may have other additional
 	 * 57xx devices behind it in some 4-port NIC designs for example.
diff --git a/drivers/net/tg3.h b/drivers/net/tg3.h
index c1075a7..c688c3a 100644
--- a/drivers/net/tg3.h
+++ b/drivers/net/tg3.h
@@ -2476,6 +2476,7 @@ struct tg3 {
 #define TG3_FLG3_NO_NVRAM_ADDR_TRANS	0x00000001
 #define TG3_FLG3_ENABLE_APE		0x00000002
 #define TG3_FLG3_5761_5784_AX_FIXES	0x00000004
+#define TG3_FLG3_5701_DMA_BUG		0x00000008
 
 	struct timer_list		timer;
 	u16				timer_counter;



  reply	other threads:[~2008-04-16 20:16 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-02-18 22:41 TG3 network data corruption regression 2.6.24/2.6.23.4 Tony Battersby
2008-02-19  0:32 ` Michael Chan
2008-02-19  0:35   ` David Miller
2008-02-19  1:04     ` Michael Chan
2008-02-19 16:16       ` Tony Battersby
2008-02-19 19:11         ` Michael Chan
2008-02-19 19:26           ` Tony Battersby
2008-02-19 22:14           ` Tony Battersby
2008-02-19 23:52             ` Michael Chan
2008-02-20 15:01               ` Tony Battersby
2008-02-20  1:38             ` Matt Carlson
2008-02-20 16:13               ` Tony Battersby
2008-02-20 21:29               ` Tony Battersby
2008-02-20 23:04               ` Tony Battersby
2008-02-20 23:08                 ` David Miller
2008-02-20 23:17                   ` Michael Chan
2008-02-20  3:45             ` Herbert Xu
2008-02-20 15:18               ` Tony Battersby
2008-04-15  0:12                 ` Matt Carlson
2008-04-15 15:39                   ` Tony Battersby
2008-04-16  3:31                     ` David Miller
2008-04-16 15:40                       ` Michael Chan
2008-04-16 20:17                         ` Matt Carlson [this message]
2008-04-16 21:00                           ` Tony Battersby
2008-04-18  6:20                         ` David Miller

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20080416201759.GB19724@localdomain \
    --to=mcarlson@broadcom.com \
    --cc=davem@davemloft.net \
    --cc=gregkh@suse.de \
    --cc=herbert@gondor.apana.org.au \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mchan@broadcom.com \
    --cc=netdev@vger.kernel.org \
    --cc=tonyb@cybernetics.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).