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.
>
next prev parent 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).