From mboxrd@z Thu Jan 1 00:00:00 1970 From: Patrick Mansfield Date: Sun, 20 Nov 2005 17:25:29 +0000 Subject: Re: waiting for an unknown set of udev /dev entries to complete Message-Id: <20051120172529.GA3969@us.ibm.com> List-Id: References: <20051118223045.GA28401@us.ibm.com> In-Reply-To: <20051118223045.GA28401@us.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: linux-hotplug@vger.kernel.org Hi Kay ... On Sun, Nov 20, 2005 at 07:03:57AM +0100, Kay Sievers wrote: > On Fri, Nov 18, 2005 at 02:30:45PM -0800, Patrick Mansfield wrote: > > That is, if I load a module or otherwise generate an unknown number of > > hotplug events for a single action or event - like a modprobe of a scsi > > HBA or even modprobe sd_mod - how can I tell when all hotplug events have > > been handled and /dev entries created? > > You should be able to look for /dev/.udev/queue/*block*, and see if > there are events still running. OK, (I think) I need this for current fc devel, udev 075, so I'll use the method to wait for all /dev/sd's to show up. If udev logging is off, I might not even hit this problem. For slow devices (perhaps iSCSI for a congested network and a slow responding target/disk), it could still be a problem. > > 1) (I'm looking for scsi block devices) Waiting for an equal number of > > /dev/sd* nodes to show up as is found under /sys/block/sd* and > > /sys/block/sd*/sd*. Is specific, and failure modes are kind of ugly (a > > timeout could be used, but if hotplug is really slow and is making > > progress you don't want to stop waiting). > > > > 2) Waiting for all hotplug processes to finish. This is more general > > purpose (not scsi or block specific, but doesn't handle children of > > kernel.hotplug that are not named the same (at least my script below has > > this problem). > > You may not detach from the event process for short living programs, > that will leave the event in the queue. If you need to do really complicated > things, you may need to synchronize the events yourself at a higher level. You mean you can't wait for a particular process to finish? Otherwise, I don't understand how the "event queue" relates to the problem. I see udev has a list of msg's. It forks udev_event_process, it will exec multiple run programs. When udev_event_process, reap_sigchilds() calls udev_done() and it removes the msg. > There is no "kernel.hotplug" that runs anything. Usually it's "udevsend", > which just passes the event to the udev daemon. On SUSE it's disabled > completely for a long time. OK, I should have remembered that (even though I'm not running SUSE) ... > The udev daemon listens to netlink and /sbin/hotplug does almost nothing > on all recent systems. It is only used for the "input" system which lacked > driver core support until 2.6.15. > > Module loads should check this during boot and install, but I haven't > > found such checks (so far, I see some stuff in suse network code but that > > is for networks). Most cases will just work for a small number of disks > > and a sufficient interval between module load and mounting (for boot) or > > use (for an install) of the intended device. > > What do you mean with: "Module loads should check this" in this case? After you load a module, like a SCSI HBA driver or even sd_mod, you should really wait for the devices to show up before you try and use them. For initrd, this means you should wait for the root /dev to show up (if it has a /sys/block/XX entry); for installs, this means wait for all /dev entries to show up. People have asked about this for general hotplug (plugging in a device, loading a module, then immediately trying to access the /dev/XXX node), but I haven't seen reports of problem for this on normal boot (initrd root mounting) or for installs, maybe iSCSI makes hitting this more likely. > > With current FC rawhide/devel, I am working on iscsi install, and had udev > > "error" logging enabled on a medium speed dual processor system. So the > > scripts are very slow, and the partition setup code is being run right > > after iscsi scan (really discovery/login and then scan) and it does not > > see all the devices (and I probably have some bugs still). > > Hmm, care to explain that better, I don't really understand... Just that udev /dev creation is slow with udev_log="err", so after a login to an iSCSI target completes (iSCSI tools issue a scan of the target via user space), the /dev entries are not available for about 60 seconds. So if immediately after the iSCSI login, if we look for or try to use /dev block install targets, we can have problems. > > It takes over a second per scsi sd, and I have about 60 of them. > > But these are not serialized, are they? Right. I can see multiple processes running. I don't know why they are _so_ slow. With udev_log=info, they run fairly fast (i.e. I don't think there is a problem), but with udev_log=err, it's really slow, so I guess all that the logging is the bottleneck (maybe some fsync in syslog?). How can I change the udev_log level without rebooting? -- Patrick Mansfield ------------------------------------------------------- This SF.Net email is sponsored by the JBoss Inc. Get Certified Today Register for a JBoss Training Course. Free Certification Exam for All Training Attendees Through End of 2005. For more info visit: http://ads.osdn.com/?ad_idv28&alloc_id845&op=click _______________________________________________ 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