Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.

Bug 156261

Summary: 8139cp stopped working
Product: [Fedora] Fedora Reporter: Tomas Edwardsson <tommi>
Component: kernelAssignee: John W. Linville <linville>
Status: CLOSED UPSTREAM QA Contact: Brian Brock <bbrock>
Severity: high Docs Contact:
Priority: medium    
Version: 4CC: davej, eroux, mefoster, wtogami
Target Milestone: ---   
Target Release: ---   
Hardware: i386   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2005-06-08 13:37:15 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
Attachments:
Description Flags
jwltest-tpm-fixes.patch none

Description Tomas Edwardsson 2005-04-28 15:05:41 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.7) Gecko/20050416 Fedora/1.0.3-2 Firefox/1.0.3

Description of problem:
After upgrading to FC4T2 my network card stopped working. I have tried the
following kernels, not function correctly:

kernel-2.6.11-1.1226_FC4
kernel-2.6.11-1.1258_FC4
kernel-2.6.11-1.1261_FC4

The following is the lspci line relevant:
02:01.0 Ethernet controller: Realtek Semiconductor Co., Ltd.
RTL-8139/8139C/8139C+ (rev 20)

The 8139cp loads correctly, but limited traffic gets through. I rarely get
DHCP leases, if I staticly set the IP I get a package through now and
then, every other minute or so.

What I see in the messages log is the following:

Apr 27 14:33:44 uber kernel: NETDEV WATCHDOG: eth0: transmit timed out
Apr 27 14:33:44 uber kernel: eth0: link up, 100Mbps, full-duplex, lpa 0x45E1
Apr 27 14:33:56 uber kernel: NETDEV WATCHDOG: eth0: transmit timed out
Apr 27 14:33:56 uber kernel: eth0: link up, 100Mbps, full-duplex, 1pa 0x45E1
...

If I boot the machine in rescue mode with a Fedora Core 3 CD I can
activate the network and it works.


Version-Release number of selected component (if applicable):
2.6.11-1.1226_FC4, 2.6.11-1.1258_FC4, 2.6.11-1.1261_FC4

How reproducible:
Always

Steps to Reproduce:
1.Try a realtek card and 8139cp

Additional info:

The 8139cp loads correctly, but limited traffic gets through. I rarely get
DHCP leases, if I staticly set the IP I get a package through now and
then, every other minute or so.

What I see in the messages log is the following:

Apr 27 14:33:44 uber kernel: NETDEV WATCHDOG: eth0: transmit timed out
Apr 27 14:33:44 uber kernel: eth0: link up, 100Mbps, full-duplex, lpa 0x45E1
Apr 27 14:33:56 uber kernel: NETDEV WATCHDOG: eth0: transmit timed out
Apr 27 14:33:56 uber kernel: eth0: link up, 100Mbps, full-duplex, 1pa 0x45E1
...

If I boot the machine in rescue mode with a Fedora Core 3 CD I can
activate the network and it works.

Comment 1 Tomas Edwardsson 2005-04-29 10:53:22 UTC
Tried the latest kernel update and the problem still exists.
2.6.11-1.1275_FC4.

Comment 2 John W. Linville 2005-04-29 13:05:57 UTC
Does this device work w/ the 8139too driver?

# ifdown eth0
# modprobe -r 8139cp
# vi /etc/modprobe.conf # change 8139cp to 8139too
# ifup eth0

Comment 3 Tomas Edwardsson 2005-04-30 19:10:42 UTC
I've actually tried that also. Same result.

Comment 4 Mary Ellen Foster 2005-05-02 12:09:34 UTC
This sounds somewhat similar to the symptoms I'm experiencing with my b44
Ethernet card:

https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=154512

Comment 5 Tomas Edwardsson 2005-05-02 18:42:53 UTC
Finally found out what was causing the problem, and hopefully you guys can fix
it, all I have is a workaround...

I found out that if I booted linux with "init=/bin/bash" and started networking,
it worked.

So I hacked for a while through rc.sysinit until I found that when tpm_atmel was
loaded, 8139cp stopped working.

My workaround was adding "tpm_atmel" to /etc/hotplug/blacklist, hope this helps.

Comment 6 Tomas Edwardsson 2005-05-04 10:27:02 UTC
More problems emerge. Now tpm_nsc loads on boot with the same negative effect on
my network adapter. Now I have both tpm_atmel and tpm_nsc in /etc/hotplub/blacklist.

Comment 7 John W. Linville 2005-05-10 17:49:12 UTC
There has been some recent activity with the tpm driver.  I've included those 
patches in the kernels here: 
 
   http://people.redhat.com/linville/kernels/fc4/ 
 
Please give them a try and post the results.  Go ahead and remove the 
tpm-related modules from /etc/hotplug/blacklist before testing.  Thanks! 

Comment 8 Tomas Edwardsson 2005-05-18 18:30:57 UTC
Same result with your kernel 2.6.11-1.1288.2.1_FC4.jwltest.1. Have not tested
the most recent ones.

Comment 9 John W. Linville 2005-05-24 19:55:14 UTC
Please try ...jwltest.3 (or later) from the same location as in comment 7.  I 
have been in contact w/ the tpm driver maintainer, and those kernels include 
some changes suggested by her. 
 
Please post the results of testing those kernels.  Thanks! 

Comment 10 John W. Linville 2005-05-25 15:04:49 UTC
*** Bug 158291 has been marked as a duplicate of this bug. ***

Comment 11 John W. Linville 2005-05-25 15:09:15 UTC
Created attachment 114829 [details]
jwltest-tpm-fixes.patch

This patch appears to fix the problem for (at least some) users...

Comment 13 Tomas Edwardsson 2005-06-07 10:49:22 UTC
tpm drivers do not load anymore by default so this has been worked out some
other way. I will try the jwltest kernel later today.

Comment 14 John W. Linville 2005-06-07 13:54:05 UTC
The tpm drivers aren't currently being built.  However, we'd like to be able 
to include them if we can fix them so that they don't cause problems for you.  
I appreciate your help! 

Comment 15 Tomas Edwardsson 2005-06-07 23:41:27 UTC
2.6.11-1.1363.2.1_FC4.jwltest.5 confirmed working. I transfered a few gigabytes
via NFS without a problem.

# lsmod | grep tpm
tpm_atmel  5569 0
tpm       12385 1 tpm_atmel



Comment 16 John W. Linville 2005-06-08 13:37:15 UTC
I'm going to close this for now...either tpm will remain disabled, or it will 
get re-enabled along w/ this patch (or an equivalent update from upstream)... 
 
Thanks for the testing!