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 77520

Summary: [tulip pnic] auto-negotiation with netgear hub causes -> kernel: NETDEV WATCHDOG: eth0: transmit timed out
Product: [Retired] Red Hat Linux Reporter: Ryan O'Reilly <newzletterz>
Component: kernelAssignee: Jeff Garzik <jgarzik>
Status: CLOSED CURRENTRELEASE QA Contact: Brian Brock <bbrock>
Severity: medium Docs Contact:
Priority: medium    
Version: 8.0CC: peterm
Target Milestone: ---   
Target Release: ---   
Hardware: i586   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2004-09-30 15:40:10 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:

Description Ryan O'Reilly 2002-11-08 13:55:32 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20020830

Description of problem:
I moved the location of my PC to a different lan segment, and there were no
problems prior to this move. After moving the PC, there was only a brief amount
of time where it could access the network until the connection would hang.
Performing "ifconfig eth0 down" and "ifconfig eth0 up" and "route ..." the PC
would be able to access the network again for a brief while (a few minutes)
until the problem would resurface. Running a ping in one terminal, while running
ifconfig in another terminal, indicates that even though the interface is up and
that the routing was accurate, that the TX counters were not increasing.

One thing that was interesting is that you could ping all day and not find the
problem. Also HTTP or FTP traffic will start sucessfully but will soon cause the
problem to appear.






Version-Release number of selected component (if applicable):


How reproducible:
Always

Steps to Reproduce:
1. Use netgear model DS 104 hub

2. Use Lite-On Communications Inc LNE100TX (rev 32) nic

3. Static or DHCP configuration makes no difference, just try some large HTTP or
FTP transfers for the problem to happen quickly

4. Try again without the netgear hub with the same configuration and observe
that the problem goes away.


Actual Results:  Ifconfig indicates that even though routing was correct, the
interface was up, and there is a ping running for the PC's gateway, that there
was no TX packets sent.

Expected Results:  eth0 should have been transmitting packets

Additional info:

--------------------------
Nic in use (also netgear):
--------------------------
  Bus  0, device  15, function  0:
    Ethernet controller: Lite-On Communications Inc LNE100TX (rev 32).
      IRQ 11.
      Master Capable.  Latency=32.
      I/O at 0xe400 [0xe4ff].
      Non-prefetchable 32 bit memory at 0xe7000000 [0xe70000ff].

-------------------------
/var/log/messages has lots of:
-------------------------

Nov  8 04:45:42 dhcp-33-30 kernel: eth0: Setting half-duplex based on MII#1 link
partner capability of 0021.
Nov  8 04:45:45 dhcp-33-30 kernel: NETDEV WATCHDOG: eth0: transmit timed out

Comment 1 Ryan O'Reilly 2002-11-10 23:14:43 UTC
The problem also happens when connecting to a Linksys NH108 model hub. The
problem does NOT appear when connecting to a Linksys BEFSR81 "Broadband DSL
router." I also found that pinging with the defaul packet size the problem would
not cause the problem to appear, but pinging with 1508 byte packets causes the
problem to manifest fairly quickly.

Comment 2 Bugzilla owner 2004-09-30 15:40:10 UTC
Thanks for the bug report. However, Red Hat no longer maintains this version of
the product. Please upgrade to the latest version and open a new bug if the problem
persists.

The Fedora Legacy project (http://fedoralegacy.org/) maintains some older releases, 
and if you believe this bug is interesting to them, please report the problem in
the bug tracker at: http://bugzilla.fedora.us/