Network trouble with SMP kernel

Cerbere · 05-09-2004, 05:22 AM

I'm having trouble compiling a SMP kernel for an old computer that I have. The box has twin 90 MHz Pentiums (it's so cute!) and a DECchip 21140a NIC which uses the Tulip driver.

I installed Slack 9.0 on it with the bare.i kernel, set up the network by editing /etc/rc.d/rc.inet1 to give it a static IP of 192.168.7.2 so I can ssh into it from my main box (IP 192.168.7.1). Everything was working fine, network-wise; but I was only using one processor. So I tried compiling a 2.4.20 kernel from scratch with SMP support. I like monolithic kernels, so I didn't choose any (M)odule options, just 'yes' or 'no'. Well, the first kernel booted fine, giving me SMP, but the network wouldn't work. When I tried to ssh to/from my main box, all I would get is 'no route to host'. I rebooted to the original bare.i kernel, and could ssh to/from my main box no problem. So I tried recompiling, thinking I had missed a necessary option. The second kernel gave the same problems, so I copied over the config file from the bare.i kernel and ran 'make menuconfig' to choose SMP support and change the processor type to 'Pentium Classic', making no other changes. I compiled the kernel and made and installed the modules this time (let me tell you, that takes a long time when your box is chugging along on one pentium 90). The same problem persists.

While I don't mind compiling a kernel, it's not something I want to make a habit of. So before compiling and recompiling, I checked out dmesg, ifconfig, route; I tried pinging my main box from the little twin 90 box and vice-versa. Everything works just fine with the uniprocessor kernel (except that it only uses one processor). But with the SMP kernel, I can self-ping from the twin 90 box using 'localhost' or '127.0.0.1' or '192.168.7.2' (the static IP I assigned it), but I get no reply when I try to ping to or from my main box. Likewise, I can ssh to localhost, etc. but not to/from my main box, I always get the error 'no route to host'.

Below is the output of 'route':

Code:

Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
localnet        *               255.255.255.0   U     0      0        0 eth0
loopback        *               255.0.0.0       U     0      0        0 lo
default         192.168.7.1     0.0.0.0         UG    1      0        0 eth0

And the output of 'ifconfig':

Code:

eth0      Link encap:Ethernet  HWaddr 00:00:94:A1:99:D5  
          inet addr:192.168.7.2  Bcast:192.168.7.255  Mask:255.255.255.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:100 
          RX bytes:0 (0.0 b)  TX bytes:0 (0.0 b)
          Interrupt:11 Base address:0x6100 

lo        Link encap:Local Loopback  
          inet addr:127.0.0.1  Mask:255.0.0.0
          UP LOOPBACK RUNNING  MTU:16436  Metric:1
          RX packets:4 errors:0 dropped:0 overruns:0 frame:0
          TX packets:4 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0 
          RX bytes:336 (336.0 b)  TX bytes:336 (336.0 b)

The output of these is the same for either kernel, except that the TX errors count goes up each time I try to ping or ssh with the SMP kernel.

I've tried using 'netconfig' to set up the network, but it does no better. I've also tried editing /etc/rc.d/rc.syslog, changing the sleep statement on line 11 (this used to be a part of rc.inet2 in older versions of slack) to avoid the 'syslogd/klogd race condition'. I've googled and found a few reports to the kernel mailing-lists of similar problems, and one suggested booting with the option 'pci=noacpi', but this didn't help either.

Has anyone experienced, or more to the point, resolved this problem?

Enjoy!
--- Cerbere

allend · 05-09-2004, 10:52 AM

I am definitely NOT an expert in this area, but sometimes it is the blindingly obvious that is overlooked.
Have you you checked your /etc/resolv.conf?

shilo · 05-09-2004, 11:16 AM

Have you tried a more recent kernel. Isn't the 2.4.xx seires at like 26 now? Or there's the 2.6.xx kernel. Maybe it's been ironed out on the newer kernels.

Cerbere · 05-10-2004, 12:49 AM

Well, I sorted out the problem. While reading throught the SMP HowTo, I found a mention of the 'noapic' option being passed to the kernel (for a seemingly unrelated problem). So, just on the off chance that the author of the post I read was referring to this option, I gave it a try. Bingo! Problem solved. So for anyone who finds this post as a result of a search, the solution is to add the following line to your /etc/lilo.conf:

append="noapic"

And shilo, I'm staying with the 2.4 kernel for now because I'm setting this machine up for an LFS build, and in the current version (5.0) the 2.4.22 kernel is recommended.

Thanks for giving me your thoughts on this, guys.

Enjoy!
--- Cerbere