Hello everyone,
I've been having major troubles with a machine here. Here's my setup:
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.
The same thing happened in 2.4.9 and now also happens in 2.4.10. There's
some odd messages coming from dmesg:
eth0: 8 0000a022.
eth0: 9 0000a020.
eth0: 10 0000a020.
eth0: 11 0000a020.
eth0: 12 0000a022.
eth0: 13 0000a022.
eth0: 14 0000a020.
eth0: 15 0000a020.
eth0: 16 0000a020.
eth0: 17 00000001.
eth0: 18 00000001.
I have no idea why this is happening. My ethernet card uses the eepro100
module. When I re-compile the kernel, I use the default config file for
slackware (so it should be like the default Slackware scsi kernel). The
only thing I do is add SMP support.
Any ideas anyone?
Thanks,
Tyler Longren
>
> Hello everyone,
>
> I've been having major troubles with a machine here. Here's my setup:
>
> 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.
> The same thing happened in 2.4.9 and now also happens in 2.4.10. There's
> some odd messages coming from dmesg:
> eth0: 8 0000a022.
> eth0: 9 0000a020.
> eth0: 10 0000a020.
> eth0: 11 0000a020.
> eth0: 12 0000a022.
> eth0: 13 0000a022.
> eth0: 14 0000a020.
> eth0: 15 0000a020.
> eth0: 16 0000a020.
> eth0: 17 00000001.
> eth0: 18 00000001.
>
> I have no idea why this is happening. My ethernet card uses the eepro100
> module. When I re-compile the kernel, I use the default config file for
> slackware (so it should be like the default Slackware scsi kernel). The
> only thing I do is add SMP support.
>
> Any ideas anyone?
Is the eepro a loadable module? I'll almost bet that it is.
You are most likely using the UP version of the module.
This can happen because the kernel parameters modified will build everything
properly, BUT, you have to remember that the default name in the build
is UP rather than SMP.
What I do is:
1. change the EXTRAVERSION in the makefile to "-SMP"
2. build/install the kernel (don't boot yet)
3. build/install modules.
When the EXTRAVERSION different than the default, a new module directory
gets created (/lib/modules/2.2.19-SMP) to hold the new modules.
This also allows me to boot uniprocessor if something happens. Otherwise
you suddenly have a mix of some uniprocessor modules and SMP modules. If
the kernel is 2.2.19 (like mine), you will get network failures in SMP.
If you build the network modules, you now get network failures in UP.
If I'm going to be working in both, then I'll first copy the UP distribution
(cp -rp 2.2.19 2.2.19-SMP), and then change the Makefile in the SMP tree.
Keeps things separate, and works.
-------------------------------------------------------------------------
Jesse I Pollard, II
Email: [email protected]
Any opinions expressed are solely my own.
> 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,
[email protected]
__________________________________________________
Do You Yahoo!?
NEW from Yahoo! GeoCities - quick and easy web site hosting, just $8.95/month.
http://geocities.yahoo.com/ps/info1