Bug 156261 - 8139cp stopped working
Summary: 8139cp stopped working
Status: CLOSED UPSTREAM
Alias: None
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
(Show other bugs)
Version: 4
Hardware: i386 Linux
medium
high
Target Milestone: ---
Assignee: John W. Linville
QA Contact: Brian Brock
URL:
Whiteboard:
Keywords:
: 158291 (view as bug list)
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2005-04-28 15:05 UTC by Tomas Edwardsson
Modified: 2007-11-30 22:11 UTC (History)
4 users (show)

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 (Terms of Use)
jwltest-tpm-fixes.patch (21.99 KB, patch)
2005-05-25 15:09 UTC, John W. Linville
no flags Details | Diff

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! 


Note You need to log in before you can comment on or make changes to this bug.