Red Hat Bugzilla – Bug 60258
plip stops working after down/up
Last modified: 2007-04-18 12:40:34 EDT
From Bugzilla Helper:
User-Agent: Mozilla/4.78 [en] (X11; U; Linux 2.4.17 i686)
Description of problem:
I have configured plip between two RH7.2 boxes and it works fine after bootup,
but if I do `ifconfig plip0 down` and then `ifconfig plip0 up` (or the same
with ifdown/ifup), plip works no longer (ping packets are transmitted, received
by remote, and replies transmitted back but not received here).
*remote* side logs errors: plip0: transmit timeout(1,87)
The machine where ifdown/ifup was executed, logs no errors!
After I reboot the machine where I made ifdown/ifup, everything works
I tried this with ethernet interfaces and there were no problems, so this
is a plip-specific.
Version-Release number of selected component (if applicable):
net-tools-1.60-3 (but I am not sure if it is a net-tools problem actually...)
Steps to Reproduce:
1.configure plip connection at plip0
2.ifconfig plip0 down
3.ifconfig plip0 up
4.try to ping
Actual Results: packets transmitted but not received anymore
Expected Results: ping works again as soon as interface is up
I have verified the routing table and the ifconfig output line-by-line,
there is no difference before and after down/up, so it is unclear where
the problem is.
I understand that the provided info is not enough and only hoping that
you will be able to reproduce this problem. And if not, I'll try to do
some investigations, but right now I've no idea of what can be done:(
I'll attach my ifcfg-plip0, that is all I can do for now...
Created attachment 46480 [details]
As we don't have any PLIP setup here it's hard to reproduce, but i would suspect
it might be a kernel driver problem rather than a userspace problem.
Have you tried updating to the latest errata kernel? Just a thought. Also maybe
using the updated initscripts might be an idea.
Read ya, Phil
> As we don't have any PLIP setup here
You are kidding, arent you? :) I have to look at a price list to see how much
parallel port cable costs, but I guess not too much:)
> but i would suspect
> it might be a kernel driver problem rather than a userspace problem.
That could be but I have just tried it on 2.2.20 and 2.4.17 with the same bad
as on 2.4.7-10 RH:(
But on 2.4.18 it behaves absolutely differently: it doesn't work at all! No way
to get it
working on 2.4.18 - the same timeouts, but even without a down/up magic.
> Have you tried updating to the latest errata kernel?
No, but I have tried several vanilla kernels. Downloading the whole kernel is a
big pain for me so I prefer to use sources and incremental patches.
But if you still feel that RH kernel have some special fixes that can help, I'll
> Also maybe
> using the updated initscripts might be an idea.
This doesn't help either.
I think I have to fiddle with plip_close() a bit to see if it is really a kernel
Huh, definitely a kernel bug.
Removing a "DISABLE(dev->irq);" from plip_close() (plip.c:1180) fixes the
Is it OK, or something else must be done?
I am not a kernel hacker so my question is: why plip disables a parallel port
I may use parport not only with plip so disabling an irq doesn't seem to be a
responsibility at all.
is the parport interrupt shared by chance?
Arjan, I have resubmitted this bugreport already, see Bug 64186
> is the parport interrupt shared by chance?
It doesn't seem to be. My parport uses IRQ7 and nobody else seems
to be using it. /proc/interrupts confirms this.
Actually it turns out that replacing "DISABLE(dev->irq)"
with "disable_parport_interrupts(dev)" also fixes the problem, but
please see the Bug #64186
Reassigning to kernel (as it is not a net-tools bug).
Read ya, Phil
*** This bug has been marked as a duplicate of 64186 ***
Changed to 'CLOSED' state since 'RESOLVED' has been deprecated.