netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Perolo Silantico" <per.sil@gmx.it>
To: "Stephen Hemminger" <shemminger@osdl.org>, <per.sil@gmx.it>,
	<john.ronciak@intel.com>, <ganesh.venkatesan@intel.com>,
	<scott.feldman@intel.com>
Cc: <netdev@oss.sgi.com>
Subject: AW: [Bug 3440] New: eth0 freezes: "NETDEV WATCHDOG: eth0: transmit timed out "
Date: Wed, 22 Sep 2004 18:45:12 +0200	[thread overview]
Message-ID: <BJEDLIFMBCLIGJJBNCLJGECPCPAA.per.sil@gmx.it> (raw)
In-Reply-To: <20040922092713.18711d2d@dell_ss3.pdx.osdl.net>

Same behaviour for drivers:
  - 8139too (kernel 2.6.8.1 and 2.6.8)
  - e100 (kernel 2.6.8)
  - eepro100 (kernel 2.6.8.1)

I have tried with all these drivers. Therefore it seemed to me, that this is not related to any specific driver. But to be sure, I will grab a 3com 905C from another server and try with that one and will try with the PCNet32 too.

> 
> From: Stephen Hemminger [mailto:shemminger@osdl.org]
> Sent: Mittwoch, 22. September 2004 18:27
> To: per.sil@gmx.it; john.ronciak@intel.com; ganesh.venkatesan@intel.com;
> scott.feldman@intel.com
> Cc: netdev@oss.sgi.com
> Subject: Re: [Bug 3440] New: eth0 freezes: "NETDEV WATCHDOG: eth0:
> transmit timed out "
> 
> 
> This is an ethernet driver related problem.  Which of the 
> ethernet cars (PCNet32 or E100)
> is assigned to eth0?  And which of the two e100 drivers (e100 or 
> eepro100) are you using?
> 
> 
> On Tue, 21 Sep 2004 09:42:06 -0700
> bugme-daemon@osdl.org wrote:
> 
> > http://bugme.osdl.org/show_bug.cgi?id=3440
> > 
> >            Summary: eth0 freezes: "NETDEV WATCHDOG: eth0: 
> transmit timed out
> >                     "
> >     Kernel Version: 2.6.8.1
> >             Status: NEW
> >           Severity: high
> >              Owner: shemminger@osdl.org
> >          Submitter: per.sil@gmx.it
> > 
> > 
> > Hi kernel developers,
> > 
> > There exists a severe problem with a linux box of my own. The 
> problem does not
> > occur when using kernel 2.4.25 on the same machine. I need your help.
> > 
> > Distribution:
> > -------------
> > Gentoo Linux 1.4 (2004.2), recompiled whole system with kernel 
> 2.6 and NPTL.
> > 
> > Hardware Environment:
> > ---------------------
> > - IBM PC Server 325, Dual Pentium Pro 180MHz, 256MB RAM, 
> > - 3ware Controller 6410 with RAID 1+0, 
> > - PCNet32 10MBit on-board card
> > - Intel EtherExpress Pro 100
> > - RTL 8139 Card. 
> > - 2x AVM ISDN B1 active ISA cards (Rev. 2.0 and Rev. 3.0 cards)
> > 
> > Tried with both cards, and tried both manually set to half-duplex or
> > full-duplex. tried same kernel with ISDN cards removed (but 
> modules still
> > compiled in)
> > 
> > I removed one processor using same SMP-enabled kernel on single 
> processor system
> > - problem persists.
> > 
> > The box is connected to a DLink DGS-1008D GigaBit switch and I 
> tried with a
> > D-Link DES 1026G switch.
> > 
> > 
> > The source of the transfer is a HP Netserver Dual Pentium III 
> 600MHz with kernel
> > 2.4.23_pre8 SMP and same openSSH version, connected to the same switch.
> > 
> > 
> > Software Environment:
> > ---------------------
> > "vanilla" kernel 2.6.8.1 on Gentoo Linux (see dmesg output and 
> config file)
> > IPv6 compiled in but deactivated with
> >   ifconfig eth1 inet6 del ...
> > 
> > same problem with kernel 2.6.7 and 2.6.8 using same kernel 
> configuration.
> > 
> > gcc-3.3.4
> > glibc-2.3.4.20040808  
> > OpenSSH_3.8.1p1, OpenSSL 0.9.7d 17 Mar 2004
> > 
> > (for installed system utils, see attached file)
> > 
> > Problem Description:
> > ---------------------
> > 
> > When transfering some data (approx. 3 GB in size) from one 
> amchine on the LAN to
> > this box the transmission hangs on the interface after some 
> seconds (20MBs) and
> > a "time out" occures. Then the LAN connection freezes, is 
> terminated and the
> > linux box is not reachable from the network anymore. After some 
> minutes the
> > connection recoveres again.
> > 
> > The network transmission times out and the ethernet driver is 
> not responding to
> > any LAN traffic (not even to any ICMP echo request). kernel log 
> message tells:
> > 
> >    NETDEV WATCHDOG: eth0: transmit timed out
> >    eth0:  Tx descriptor 0 is 0008a072.
> > 
> > (off course: address of descriptor varies)
> > After approx. 4 minutes, the LAN connection of the box recovers 
> and you can
> > connect to the box again. (until next transfer is started)
> > 
> > transfer issued by another host:
> > ................................
> > Usually a transfer host consumes all interface bandwidth 
> available (100 MBit LAN
> > with full-duplex cards on both involved machines gives at least 
> 1.6 MByte/s if
> > SCP overhead is taken into consideration). the connection stays 
> alive if it
> > limited to smaller bandwith with fe. 100 Kbit (~ 12.5 KBytes) 
> "scp -l 100 ...".
> > But using 1000 KBit (~125 KByte) "scp -l 1000 ..." the 
> connection is freezing
> > although maximum bandwidth is not reached. 
> > 
> > transfer issued by host itself:
> > ................................
> > If the box issues a transfer from the internet using 235 
> KBytes/s (~ 2MBits/s)
> > everything works out fine. If the box issues the transfer from 
> the LAN with full
> > bandwith of 1.8 MBytes/s then the LAN connection is freezing too. 
> > 
> > 
> > If I turn of window scaling with "echo 0 >
> > /proc/sys/net/ipv4/tcp_window_scaling" then the time needed to 
> recover the
> > interface seems to decrease. The SCP transfer still freezes but 
> LAN timeout of
> > the box is small enough to keep SSH connection alive.
> > 
> > it did not help to set the following, as suggested by other web pages:
> >   tcp_default_win_scale=0
> >   tcp_moderate_rcvbuf=0
> > 
> > 
> > Steps to reproduce:
> > -------------------
> > start any SCP/SFTP transfer to the linux box with kernel 
> 2.6.8.1 - always
> > reproducable on my box. I do not know about others since this 
> is my first box
> > with kernel 2.6.x
> > 
> > 
> > 
> > If you need more information or testing, please let me know. I 
> will not change
> > the configuration of the box for some time to be able to 
> fullfill your requests,
> > hoping to help solving the problem. 
> > 
> > 
> > Yours
> >   Perolo
> > 
> > PS: Dear maintainer, I am able to grant you access to the 
> computer if this will
> > help you. please contact me if this is vital for solving the problem.
> > 
> > ------- You are receiving this mail because: -------
> > You are the assignee for the bug, or are watching the assignee.
> 

  reply	other threads:[~2004-09-22 16:45 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <200409211642.i8LGg6Uq012224@fire-1.osdl.org>
2004-09-22 16:27 ` [Bug 3440] New: eth0 freezes: "NETDEV WATCHDOG: eth0: transmit timed out " Stephen Hemminger
2004-09-22 16:45   ` Perolo Silantico [this message]
2004-09-22 17:50     ` Don Fry
2004-09-22 20:22     ` Francois Romieu
2004-09-22 21:03   ` Perolo Silantico
2004-09-22 21:19     ` Stephen Hemminger

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=BJEDLIFMBCLIGJJBNCLJGECPCPAA.per.sil@gmx.it \
    --to=per.sil@gmx.it \
    --cc=ganesh.venkatesan@intel.com \
    --cc=john.ronciak@intel.com \
    --cc=netdev@oss.sgi.com \
    --cc=scott.feldman@intel.com \
    --cc=shemminger@osdl.org \
    /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: link
Be 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).