Re: 2.4.x, smp, eepro100

java programmer (javadesigner@yahoo.com)
Tue, 9 Oct 2001 09:58:06 -0700 (PDT)


> OS: Slackware 8.0
> Kernel: 2.4.5_nosmp, 2.4.5, and 2.4.10
> NIC: eepro100
>
> Anyway, installed Slackware with the default scsi
> kernel. Everything worked
> fine. I re-compiled 2.4.5 to enable smp support.
> After re-compiling
> everything is stable until a few hundred megs gets
> uploaded to the box.
> After a few hundred megs get upped to the box
> (through ftp), eth0 just dies.

I too have the *exact* same problem. I am running
slackware 8.0, SMP 2.4.5 kernel on dual PII-Xeon,
2 intel cards with the default eepro100 drivers.

I even downloaded and tried the intel linux
drivers (different from the default kernel ones)
and still had the same problem. The default driver
*does* give me a "lockup workaround enabled" message
during startup, but after transferring a couple of
gigs of data, both ethernet cards seem to randomly
hang up after a couple of days. I even wrote a test
script that constantly ftp'ed files (get/put) and
that worked fine to about 10 Gigs before I got bored
and gave up. A day or two later, the cards hung again.
As far as I can tell, doing google searches on related
keywords, this problem might have something to do
with speed autonegotiation between the cards and
the switch. I am using a Nortel baystack but this
problem seems to also occur with 3com switches. Both
are autonegotiating-only switches with no way
to manually set the speed of any port. If the problem
continues, I am thinking of getting a pricier intel
switch that does allow for manual port speed setting
to 10 or 100 Mbit/sec. My cards do connect at
100Mbit/s
initially with the current Nortel, so the initial
autonegotiation is OK, but maybe there are subsequent
autonegotiations on a regular basis that fail ?

This problem is quite strange, because a Windows 2000
box, sitting on the same network, showed the same
symptom once. That box was also connected to the
same baystack switch. It may or may not have been
a related problem, it only happened once, while the
linux problem seems to happen more frequently. And
it really is quite random.

*Once* it happens though, there is no way to
regain network control of the box - except by
logging in via the console and rebooting the linux
box. That's kind of a drag, because I am sitting
on the U.S East coast while the box is colocated in
Denver.

Best regards,

javadesigner@yahoo.com

__________________________________________________
Do You Yahoo!?
NEW from Yahoo! GeoCities - quick and easy web site hosting, just $8.95/month.
http://geocities.yahoo.com/ps/info1
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/