I've been trying to get an old 486 laptop and my Pentium III to
communicate over PLIP. I've got it successfully working with a 2.4.2
kernel on the PIII and a 2.0.3 kernel on the laptop. The laptop kernel
had PLIP statically linked and lp removed so there weren't any conflicts.
This works fine, and I can ping the laptop from the PIII, getting about 6
ms reply time; flood ping gives a few dropped packets initially (about 6)
then no more; I can do 'ping -i 0.01 <host>' from the PIII and it
doesn't drop any packets. The PLIP code in the laptop is from a kernel
before the parallel port sharing code was introduced as far as I can tell.
HOWEVER, I'd like to run a more recent kernel on the laptop. I have tried
2.2.19 and 2.4.5 (both from Slackware 8.0) and found that I could no
longer compile the PLIP support statically into the kernel as it couldn't
find the IRQ to use etc. So I separated them out as modules. The kernels
had module support enabled, plip enabled, parport and parport_pc
enabled. The kernels boot, and I do
insmod parport_pc.o io=0x378 irq=7
ifconfig plip0 192.168.0.2 pointopoint 192.168.0.1 up
route add -net 192.168.0.0 netmask 255.255.255.0 dev plip0
on the laptop. Now, the connection *seems* ok, since I can do a normal
"ping <otherhost>", but I get about 20 ms this time, rather than 6 ms as
before with the non parport-sharing code. However, when I do a flood ping
or try ping -i 0.01, I get a zillion lost packets. NFS barely works at
all, whereas before it worked perfectly and gave me about 30 k/s I think.
My guess is that the parport sharing code is causing some sort of
bottleneck which is only showing up on the slow 486. When the laptop is
using the 2.0.3 PLIP code (no parport sharing), it communicates fine with
the PIII which is using the more modern PLIP (sharing) code.
Additonal information: The kernels compiled for the 486 are extremely
minimal; everything I can get away with has been disabled. PCI is
disabled, but I'm not sure this is relevent. This laptop is curious
because it will hang on kernel boot if you use the newer IDE drivers; I
had to tell the kernel to use the older ones for it to boot properly.
Any ideas? If this fails I may have to resort to PPP over the serial
port; something I do not relish the thought of!
-- Ian Hinder email@example.com
-- To unsubscribe, send mail to: firstname.lastname@example.org -- -- with the single word "unsubscribe" in the body of the message. --
This archive was generated by hypermail 2b29 : Thu Aug 23 2001 - 14:29:06 EDT