Bug 60258

Summary: plip stops working after down/up
Product: [Retired] Red Hat Linux Reporter: Stas Sergeev <stssppnn>
Component: kernelAssignee: Arjan van de Ven <arjanv>
Status: CLOSED DUPLICATE QA Contact: Brian Brock <bbrock>
Severity: medium Docs Contact:
Priority: medium    
Version: 7.2   
Target Milestone: ---   
Target Release: ---   
Hardware: i386   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2006-02-21 18:48:30 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
ifcfg-plip0 none

Description Stas Sergeev 2002-02-23 01:56:24 UTC 
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...
Comment 1 Stas Sergeev 2002-02-23 01:58:01 UTC 
Created attachment 46480 [details]
ifcfg-plip0
Comment 2 Phil Knirsch 2002-02-27 10:56:49 UTC 
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
Comment 3 Stas Sergeev 2002-02-27 22:36:28 UTC 
> 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.
Comment 4 Stas Sergeev 2002-02-27 23:34:34 UTC 
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.
Comment 5 Arjan van de Ven 2002-08-19 14:45:49 UTC 
is the parport interrupt shared by chance?
Comment 6 Stas Sergeev 2002-08-23 17:37:49 UTC 
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.
Comment 7 Phil Knirsch 2003-05-23 08:15:29 UTC 
Reassigning to kernel (as it is not a net-tools bug).

Read ya, Phil
Comment 8 Alan Cox 2003-06-09 12:29:32 UTC 

*** This bug has been marked as a duplicate of 64186 ***
Comment 9 Red Hat Bugzilla 2006-02-21 18:48:30 UTC 
Changed to 'CLOSED' state since 'RESOLVED' has been deprecated.