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;
next prev parent 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: linkBe 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).