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 again. 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...) How reproducible: Always 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 Additional info: 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] ifcfg-plip0
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 does a 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 results 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. Strange... > 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 try it, no problems. > 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 problem.
Huh, definitely a kernel bug. Removing a "DISABLE(dev->irq);" from plip_close() (plip.c:1180) fixes the problem. 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 irq? I may use parport not only with plip so disabling an irq doesn't seem to be a plip's responsibility at all.
is the parport interrupt shared by chance?
Arjan, I have resubmitted this bugreport already, see Bug 64186 https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=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 Thanks.
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.