From: Kay Sievers <kay.sievers@vrfy.org>
To: linux-hotplug@vger.kernel.org
Subject: Re: strange delays in vc class
Date: Fri, 15 Oct 2004 19:18:26 +0000 [thread overview]
Message-ID: <20041015191826.GA6556@vrfy.org> (raw)
In-Reply-To: <20041015000446.GA2796@vrfy.org>
On Fri, Oct 15, 2004 at 11:59:35AM -0700, Greg KH wrote:
> On Fri, Oct 15, 2004 at 08:48:39PM +0200, Kay Sievers wrote:
> > On Fri, Oct 15, 2004 at 11:34:33AM -0700, Greg KH wrote:
> > > On Fri, Oct 15, 2004 at 02:23:53AM +0200, Kay Sievers wrote:
> > > > On Fri, Oct 15, 2004 at 02:04:46AM +0200, Kay Sievers wrote:
> > > > > I've some debug output from a patched wait_for_sysfs. But no idea,
> > > > > what's going wrong here:
> > > >
> > > > Ok, there is a pattern. Seems pretty strange to get _two_ hotplug events
> > > > for the same device. Only the second event will create the "dev" file we're
> > > > looking for. So the first event will spin until the second arrives with the file.
> > >
> > > Is this with the -mm tree? or a "clean" 2.6.9-rc4 kernel?
> >
> > It happens with a 2.6.8 kernel.
>
> Ugh. In looking at the kernel code, I don't see how it could be doing
> this. But the console startup code is a strange beast...
I'm getting closer:
This is the sequence I get on bootup:
SUBSYSTEM=net
DEVPATH=/class/net/sit0
SEQNUM&0
ACTIONd
SUBSYSTEM=vc
DEVPATH=/class/vc/vcs4
SEQNUM&1
ACTIONd
SUBSYSTEM=vc
DEVPATH=/class/vc/vcsa4
SEQNUM&2
ACTIONd
SUBSYSTEM=vc
DEVPATH=/class/vc/vcs4
SEQNUM&3
ACTION=remove
SUBSYSTEM=vc
DEVPATH=/class/vc/vcsa4
SEQNUM&4
ACTION=remove
SUBSYSTEM=vc
DEVPATH=/class/vc/vcs4
SEQNUM&5
ACTIONd
SUBSYSTEM=vc
DEVPATH=/class/vc/vcsa4
SEQNUM&6
ACTIONd
According to the kernel code the vc is created on open() and destroyed
on close() which causes hotplug events. Seems like the bootup opens and
closes a vc two times for every device.
The close will remove the "dev" file and the wait_for_sysfs from the
add-hotplug will spin and fail or at best will recover with the next
hotplug-add. The "remove" event beats the "add"! We have the same event
serializing problem here, we solved with udevd for udev.
Kay
-------------------------------------------------------
This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
Use IT products in your business? Tell us what you think of them. Give us
Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
http://productguide.itmanagersjournal.com/guidepromo.tmpl
_______________________________________________
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
next prev parent reply other threads:[~2004-10-15 19:18 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-10-15 0:04 strange delays in vc class Kay Sievers
2004-10-15 0:23 ` Kay Sievers
2004-10-15 18:34 ` Greg KH
2004-10-15 18:48 ` Kay Sievers
2004-10-15 18:59 ` Greg KH
2004-10-15 19:18 ` Kay Sievers [this message]
2004-10-15 20:09 ` Kay Sievers
2004-10-15 22:12 ` Greg KH
2004-10-15 23:20 ` Greg KH
2004-10-16 0:08 ` Kay Sievers
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=20041015191826.GA6556@vrfy.org \
--to=kay.sievers@vrfy.org \
--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).