linux-hotplug.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Adrien Beau <adrien.beau@free.fr>
To: linux-hotplug@vger.kernel.org
Subject: Hotplug bug in Linux 2.4.21?
Date: Fri, 20 Jun 2003 17:25:59 +0000	[thread overview]
Message-ID: <marc-linux-hotplug-105613022514760@msgid-missing> (raw)

Hello,

This is my first post on this mailing list. I registered to
discuss some uncritical issues I had with hotplug scripting, but
have encountered a problem today that I feel is more important.
However, I think it will be better if I explain my overall
situation in some details. If you're really busy, there's just
one thing you need to know and investigate: it seems that Linux
2.4.21 fires every event *three* times instead of one; this
breaks scripts.

My hotplugging needs are limited to one peripheral, the SpeedTouch
USB DSL modem. Due to some mysterious factors, it is disconnected
at the USB level several times per day, and so I saw a good
hotplug script as a fine solution to this behavior.

This modem is purely driven in userland. A kernel driver is in the
works, but not on par to the userland driver yet. When the modem is
connected, "modem_run" is launched to upload the firmware, handle
the initial DSL connection and then monitor the state of the line
in the background. "pppd" is then launched, and communicates with
the modem through the "pppoa3" helper program, which handles PPP
over ATM.

My uncritical issue was a coldplug issue. modem_run runs for around
25 seconds before it returns to its caller. However, upon bootup, it
seems that after seven seconds, some component in the hotplug or usb
subsystems times out and fires a new event. Since my hotplug script
kills existing instances of pppd and modem_run before relaunching them,
this was a problem, which I solved by implementing a locking mechanism
in my script: if the lockfile exists *and* isn't too old, the script
exits. This worked fine (but still with a few dangling issues I was
intending to ask about here), until I upgraded to Linux 2.4.21.

When I booted my new kernel, I almost immediately noticed that my
DSL line wasn't up as expected, and so I looked into my logs (my
hotplug script does a fair amount of logging) and noticed two weird
things: the first one, is that *three* connection events were fired
when the modem was detected (plus another one after the seven seconds
timeout). When I disconnected it, my remover was launched *three*
times, simultaneously.

My only diagnostic is that there's something quite broken in the new
kernel. I haven't had time to investigate the source however, and
you might know it much better than me (well, I've never looked at the
hotplug source). So, any idea, any help, is welcome. I can put the
hotplug script and the log on a website if you want to have a look
at them.

But wait, it's not over... I bet some of you (most of you?) have
already wondered "But he has a locking mechanism, so what's the deal?".
Well, the "deal" is that for reasons I can't even begin to speculate
on, when three instances of my hotplug script are run in parallel
(all three launched in the same second), a very simple "if" test fails
to work (it works fine when two instances are run at a few seconds
interval). Considering the simplicity of the code, I'd call that
"impossible", but it happens indeed. ¹

Well, I'd much rather try to solve why three events are fired for one
dis/connection (sounds like a simple bug) that to solve this
impossibility.

Thank you for reading this far, I look forward to discuss this with
you. I'll be out on (perhaps extended) week-end, but I'll try to check
this list once or twice during this period.


¹ Here's the code portion that fails:

MAX_LOCK_AGE`
if expr $currenttime '-' $timestamp '<' $MAX_LOCK_AGE; then
   log "Found a recent lock, exiting"
   exit 0
else
   log "Found a stale lock"
   # go ahead, create a new one
fi

With for example currenttime\x1056107163 and timestamp\x1056107162, I get
"Found a stale lock" on my log (and of course, the lock is removed,
pppd and modem_run are killed, etc.) When only two instances run at a
few more seconds interval, under 2.4.20, I of course get "Found a
recent lock, exiting" and everything works fine. Now, isn't that weird?

-- 
adrien.beau@free.fr - http://adrien.beau.free.fr/



-------------------------------------------------------
This SF.Net email is sponsored by: INetU
Attention Web Developers & Consultants: Become An INetU Hosting Partner.
Refer Dedicated Servers. We Manage Them. You Get 10% Monthly Commission!
INetU Dedicated Managed Hosting http://www.inetu.net/partner/index.php
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

             reply	other threads:[~2003-06-20 17:25 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-06-20 17:25 Adrien Beau [this message]
2003-06-20 17:51 ` Hotplug bug in Linux 2.4.21? Greg KH
2003-06-20 18:15 ` Duncan Sands
2003-06-20 18:44 ` Adrien Beau
2003-06-20 19:18 ` Kevin P. Fleming
2003-06-21 10:12 ` Olaf Hering
2003-06-21 15:56 ` Adrien Beau
2003-06-21 16:11 ` Adrien Beau
2003-06-22  6:31 ` Adrien Beau
2003-06-27 15:15 ` Adrien Beau

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=marc-linux-hotplug-105613022514760@msgid-missing \
    --to=adrien.beau@free.fr \
    --cc=linux-hotplug@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).