From mboxrd@z Thu Jan 1 00:00:00 1970 From: Greg KH Date: Fri, 15 Oct 2004 22:12:44 +0000 Subject: Re: strange delays in vc class Message-Id: <20041015221244.GA27482@kroah.com> List-Id: References: <20041015000446.GA2796@vrfy.org> In-Reply-To: <20041015000446.GA2796@vrfy.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable To: linux-hotplug@vger.kernel.org On Fri, Oct 15, 2004 at 09:18:26PM +0200, Kay Sievers wrote: > 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 id= ea, > > > > > > what's going wrong here: > > > > >=20 > > > > > 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 arrive= s with the file. > > > >=20 > > > > Is this with the -mm tree? or a "clean" 2.6.9-rc4 kernel? > > >=20 > > > It happens with a 2.6.8 kernel. > >=20 > > 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... >=20 > I'm getting closer: > This is the sequence I get on bootup: >=20 > SUBSYSTEM=3Dnet > DEVPATH=3D/class/net/sit0 > SEQNUM&0 > ACTION=ADd >=20 > SUBSYSTEM=3Dvc > DEVPATH=3D/class/vc/vcs4 > SEQNUM&1 > ACTION=ADd >=20 > SUBSYSTEM=3Dvc > DEVPATH=3D/class/vc/vcsa4 > SEQNUM&2 > ACTION=ADd >=20 > SUBSYSTEM=3Dvc > DEVPATH=3D/class/vc/vcs4 > SEQNUM&3 > ACTION=3Dremove >=20 > SUBSYSTEM=3Dvc > DEVPATH=3D/class/vc/vcsa4 > SEQNUM&4 > ACTION=3Dremove >=20 > SUBSYSTEM=3Dvc > DEVPATH=3D/class/vc/vcs4 > SEQNUM&5 > ACTION=ADd >=20 > SUBSYSTEM=3Dvc > DEVPATH=3D/class/vc/vcsa4 > SEQNUM&6 > ACTION=ADd >=20 > 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. Heh, no fun. Ok, I fixed this by watching for the directory to go away from under us. In my booting I couldn't duplicate these messages anymore... thanks, greg k-h ------------------------------------------------------- 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