From: Jeff Garzik <jgarzik@mandrakesoft.com>
To: David Ford <david@linux.com>
Cc: LKML <linux-kernel@vger.kernel.org>,
Matti Aarnio <matti.aarnio@zmailer.org>
Subject: Re: NETDEV timeout on tulips [was: Re: 2.4.1-test10]
Date: Tue, 23 Jan 2001 12:57:45 -0500 [thread overview]
Message-ID: <3A6DC619.64019749@mandrakesoft.com> (raw)
In-Reply-To: <Pine.LNX.4.10.10101221711560.1309-100000@penguin.transmeta.com> <3A6CF5B7.57DEDA11@linux.com> <3A6D2D54.619AFA7E@mandrakesoft.com> <3A6D616F.63EB34A6@linux.com>
David Ford wrote:
>
> > > Do the tulip driver updates address the increasingly common NETDEV timeout
> > > repots?
> >
> > In general you can answer this yourself by reading
> > drivers/net/tulip/ChangeLog.
> >
> > I don't see increasingly common timeout reports.. with which hardware?
> > They are likely on the newer LinkSys 4.1 cards, and there are still
> > problesm with PNIC. Outside of that, other cards should be ok.
>
> I have four machines now that exhibit this problem. Three have in them the
> Linksys card family, similar PCI cards, one is my laptop which I have three
> different cardbus cards but they all use the tulip driver.
>
> In the PCI situation, not all machines using these cards act the same way.
> I got a 10 pack of LNE100TX cards and so far only two out of the batch are doing
> this, they are all the same revision, identical in every way that I've found.
>
> The three cardbus cards are slightly different in numerous ways. For them they
> normally fault with an APM event, an eject/insert cycle via software will reset
> them and a link down/up won't fix it. For the PCI cards most times a link
> down/up cycle will fix them. It's a 2.4 v.s. 2.2 issue, the 2.2 kernels aren't
> exhibiting this error.
Sounds like the PCI PM state is getting mangled. Can you provide a
"lspci -vvv", as root, for each of the three cardbus cards? Make sure
to run lspci when the cards are up and active and working.
> The PCI cards are hard to get into this state, sometimes they'll run millions of
> packets for months on end before they'll burp. Sometimes it'll happen three
> times a night. The amount of traffic doesn't seem to matter, nor does the type
> of traffic.
>
> 00:0a.0 Ethernet controller: Lite-On Communications Inc LNE100TX (rev 20)
> Subsystem: Netgear FA310TX
If the link is getting lost (which may explain the randomness of the
error), the following patch might help:
http://sourceforge.net/patch/?func=detailpatch&patch_id=103294&group_id=13004
There are still some media fixes that need to be integrated from the
Becker driver, and tested, too.
Also, downloading tulip-diag.c and capturing the register state before
and after the breakage is useful. A useful command line is "tulip-diag
-mmmaaavvveef".
Jeff
--
Jeff Garzik | "You see, in this world there's two kinds of
Building 1024 | people, my friend: Those with loaded guns
MandrakeSoft | and those who dig. You dig." --Blondie
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
next prev parent reply other threads:[~2001-01-23 17:58 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-01-23 1:13 2.4.1-test10 Linus Torvalds
2001-01-23 3:08 ` 2.4.1-test10 David Ford
2001-01-23 5:04 ` 2.4.1-test10 Derek Wildstar
2001-01-23 7:05 ` 2.4.1-test10 Jeff Garzik
2001-01-23 10:42 ` 2.4.1-test10 Ben Ford
2001-01-23 10:48 ` NETDEV timeout on tulips [was: Re: 2.4.1-test10] David Ford
2001-01-23 10:56 ` Matti Aarnio
2001-01-23 11:13 ` David Ford
2001-01-23 12:25 ` Matti Aarnio
2001-01-23 12:36 ` David Ford
2001-01-23 17:57 ` Jeff Garzik [this message]
2001-01-23 4:37 ` 2.4.1-test10 Marcelo Tosatti
2001-01-23 19:03 ` 2.4.1-test10 Linus Torvalds
2001-01-23 19:27 ` 2.4.1-test10 Andre Hedrick
2001-01-23 17:48 ` 2.4.1-test10 Marcelo Tosatti
2001-01-23 19:38 ` Under 2.4.0 I can mount same partition twice Dan Graham
2001-01-23 20:13 ` Andreas Dilger
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=3A6DC619.64019749@mandrakesoft.com \
--to=jgarzik@mandrakesoft.com \
--cc=david@linux.com \
--cc=linux-kernel@vger.kernel.org \
--cc=matti.aarnio@zmailer.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.