From: "Nick Warne" <nick@ukfsn.org>
To: linux-kernel@vger.kernel.org
Subject: 2.6.3 - 8139too timeout debug info
Date: Fri, 27 Feb 2004 17:31:27 -0000 [thread overview]
Message-ID: <403F7EEF.4124.2432E62F@localhost> (raw)
Firstly, I am starting a fresh thread here, as I have subscribed to
the lkml now so I can reply in a timely manner, and also the other
thread was broke as I was replying 'off-list' - sorry about that.
OK, to recap. With 2.6.3 I get timeouts with 8139too under network
load (any load). I have never had any problems with these _same_ two
cards under any other kernel version over the last 3 years.
If I use the 8139too.c from 2.6.2, and build 2.6.3 with it, all works
fine (I am running this version right now).
Here is the debuggered output (using #define RTL8139_NDEBUG 1):
#> /var/log/messages
Feb 27 17:12:27 Linux233 kernel: NETDEV WATCHDOG: eth0: transmit
timed out
Feb 27 17:12:39 Linux233 kernel: NETDEV WATCHDOG: eth0: transmit
timed out
Feb 27 17:12:42 Linux233 kernel: nfs: server 486Linux not responding,
still trying
Feb 27 17:12:43 Linux233 kernel: nfs: server 486Linux not responding,
still trying
Feb 27 17:12:51 Linux233 kernel: NETDEV WATCHDOG: eth0: transmit
timed out
Feb 27 17:12:51 Linux233 kernel: nfs: server 486Linux OK
Feb 27 17:12:51 Linux233 kernel: nfs: server 486Linux OK
Feb 27 17:13:03 Linux233 kernel: nfs: server 486Linux not responding,
still trying
Feb 27 17:13:03 Linux233 kernel: NETDEV WATCHDOG: eth0: transmit
timed out
Feb 27 17:13:03 Linux233 kernel: nfs: server 486Linux OK
#> dmesg
NETDEV WATCHDOG: eth0: transmit timed out
eth0: Tx queue start entry 1314 dirty entry 1310.
eth0: Tx descriptor 0 is 00002000.
eth0: Tx descriptor 1 is 00002000.
eth0: Tx descriptor 2 is 00002000. (queue head)
eth0: Tx descriptor 3 is 00002000.
NETDEV WATCHDOG: eth0: transmit timed out
eth0: Tx queue start entry 1392 dirty entry 1388.
eth0: Tx descriptor 0 is 00002000. (queue head)
eth0: Tx descriptor 1 is 00002000.
eth0: Tx descriptor 2 is 00002000.
eth0: Tx descriptor 3 is 00002000.
nfs: server 486Linux not responding, still trying
nfs: server 486Linux not responding, still trying
NETDEV WATCHDOG: eth0: transmit timed out
eth0: Tx queue start entry 363 dirty entry 359.
eth0: Tx descriptor 0 is 00002000.
eth0: Tx descriptor 1 is 00002000.
eth0: Tx descriptor 2 is 00002000.
eth0: Tx descriptor 3 is 00002000. (queue head)
nfs: server 486Linux OK
nfs: server 486Linux OK
nfs: server 486Linux not responding, still trying
NETDEV WATCHDOG: eth0: transmit timed out
eth0: Tx queue start entry 3441 dirty entry 3437.
eth0: Tx descriptor 0 is 00002000.
eth0: Tx descriptor 1 is 00002000. (queue head)
eth0: Tx descriptor 2 is 00002000.
eth0: Tx descriptor 3 is 00002000.
nfs: server 486Linux OK
#> lspci
00:00.0 Host bridge: VIA Technologies, Inc. VT82C585VP [Apollo
VP1/VPX] (rev 23)
00:07.0 ISA bridge: VIA Technologies, Inc. VT82C586/A/B PCI-to-ISA
[Apollo VP] (rev 27)
00:07.1 IDE interface: VIA Technologies, Inc. Bus Master IDE (rev 06)
00:07.2 USB Controller: VIA Technologies, Inc. UHCI USB (rev 02)
00:09.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8139
(rev 10)
00:0a.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8139
(rev 10)
00:0b.0 VGA compatible controller: Matrox Graphics, Inc. MGA 2164W
[Millennium II]
Built with:
# CONFIG_8139CP is not set
CONFIG_8139TOO=y
# CONFIG_8139TOO_PIO is not set
# CONFIG_8139TOO_TUNE_TWISTER is not set
# CONFIG_8139TOO_8129 is not set
# CONFIG_8139_OLD_RX_RESET is not set
CONFIG_8139_RXBUF_IDX=2
Any more info required?
TIA,
Nick
--
"When you're chewing on life's gristle,
Don't grumble, Give a whistle
And this'll help things turn out for the best."
next reply other threads:[~2004-02-27 17:31 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-02-27 17:31 Nick Warne [this message]
2004-02-27 17:40 ` 2.6.3 - 8139too timeout debug info Matt H.
2004-02-27 17:50 ` Nick Warne
2004-02-28 17:41 ` OGAWA Hirofumi
2004-02-28 18:47 ` Nick Warne
2004-02-29 7:58 ` OGAWA Hirofumi
2004-02-29 8:09 ` OGAWA Hirofumi
2004-02-29 11:09 ` Nick Warne
[not found] <4041BAA6.28283.2CEC419B@localhost>
[not found] ` <87fzcut9ua.fsf@devron.myhome.or.jp>
2004-02-29 11:57 ` Nick Warne
2004-02-29 12:38 ` OGAWA Hirofumi
2004-02-29 13:05 ` Nick Warne
2004-02-29 18:28 ` OGAWA Hirofumi
2004-03-01 18:29 ` Nick Warne
2004-03-22 21:17 ` Jeff Garzik
2004-03-22 22:51 ` OGAWA Hirofumi
2004-03-31 19:42 ` Christian Gut
2004-04-01 3:56 ` OGAWA Hirofumi
2004-04-04 17:02 ` OGAWA Hirofumi
-- strict thread matches above, loose matches on Subject: below --
2004-03-23 21:07 Nick Warne
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=403F7EEF.4124.2432E62F@localhost \
--to=nick@ukfsn.org \
--cc=linux-kernel@vger.kernel.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.