Bug 60258 - plip stops working after down/up
plip stops working after down/up
Status: CLOSED DUPLICATE of bug 64186
Product: Red Hat Linux
Classification: Retired
Component: kernel (Show other bugs)
7.2
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Arjan van de Ven
Brian Brock
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2002-02-22 20:56 EST by Stas Sergeev
Modified: 2007-04-18 12:40 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2006-02-21 13:48:30 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
ifcfg-plip0 (373 bytes, text/plain)
2002-02-22 20:58 EST, Stas Sergeev
no flags Details

  None (edit)
Description Stas Sergeev 2002-02-22 20:56:24 EST
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-22 20:58:01 EST
Created attachment 46480 [details]
ifcfg-plip0
Comment 2 Phil Knirsch 2002-02-27 05:56:49 EST
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 17:36:28 EST
> 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 18:34:34 EST
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 10:45:49 EDT
is the parport interrupt shared by chance?
Comment 6 Stas Sergeev 2002-08-23 13:37:49 EDT
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 04:15:29 EDT
Reassigning to kernel (as it is not a net-tools bug).

Read ya, Phil
Comment 8 Alan Cox 2003-06-09 08:29:32 EDT

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

Note You need to log in before you can comment on or make changes to this bug.