Bug 436563

Summary:	tg3 - Broadcom BCM5787M Ethernet controller has almost total packet loss with a MTU above 1320
Product:	Red Hat Enterprise Linux 5	Reporter:	Chris Croome <chris>
Component:	kernel	Assignee:	Andy Gospodarek <agospoda>
Status:	CLOSED INSUFFICIENT_DATA	QA Contact:	Red Hat Kernel QE team <kernel-qe>
Severity:	medium	Docs Contact:
Priority:	low
Version:	5.1	CC:	benlu, ccms0420, dzickus, mcarlson, peterm
Target Milestone:	rc
Target Release:	---
Hardware:	x86_64
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2010-05-12 18:31:06 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Chris Croome 2008-03-07 22:19:01 UTC

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-GB; rv:1.8.1.12) Gecko/20080201 Firefox/2.0.0.12

Description of problem:
I have a new Lenovo Thinkpad R61 which has a Broadcom Corporation NetLink BCM5787M Gigabit Ethernet PCI Express (rev 02) Ethernet controller and when the MTU on my router is set to a value above about 1320 there is almost a total loss of packets with protocols such as http or ftp or nnpt, however ssh still works. It doesn't appear to matter what I set the MTU to on the laptop. I have looked at what is heppening with wireshark and there are nots of corrupted packets, if it would help I could document this.

I currently have CentOS 5.1 installed on it with the latest kernel from Don Zickus that I found a link to from the TG3 bug here: https://bugzilla.redhat.com/show_bug.cgi?id=330181#c24 previously I had CentOS kernels on the machine and the initial install I did was with Fedora 8 and this had the same problem.


Version-Release number of selected component (if applicable):
2.6.18-84.el5

How reproducible:
Always


Steps to Reproduce:
1. Set the MTU on my router to a value greater than 1320



Actual Results:
Such massive packet loss / corruption that almost no protocols work, except ssh, however shall things do work like HTTP 302 headers or HTTP authentication prompts but no substantial about of data. 

Expected Results:
There shouldn't be a massive packet loss / corruption.

Additional info:

Comment 1 Andy Gospodarek 2008-04-15 18:05:02 UTC

What's the latest kernel you've tried?  I'm guessing you've tried 2.6.18-89, but
I want to be sure.  

You can get a version based on that from Don Zickus' page or you can always use
one of my test net-driver test kernels here:

http://people.redhat.com/agospoda/#rhel5

If you've already tried 2.6.18-89 from Don's page there isn't any point in
trying one of my kernels though. 

Are you getting any messages like this:

tg3_abort_hw timed out

or anything else that relates to tg3 in dmesg?

One interesting data point would be to turn off TSO and see if that makes a
difference.  If there is any way you can attach a capture that might be helpful
as well.

Comment 2 Andy Gospodarek 2010-05-12 18:31:06 UTC

I has been 2 years since I requested more information and no response.  I can only presume this is not a problem anymore.