[prev in list] [next in list] [prev in thread] [next in thread] 

List:       linux-scsi
Subject:    Re: Asynchronous scsi scanning, version 9
From:       maximilian attems <maks () sternwelten ! at>
Date:       2006-10-26 19:53:22
Message-ID: 20061026195322.GC12013 () nancy
[Download RAW message or body]

On Thu, 01 Jun 2006, Kay Sievers wrote:

> On Wed, 2006-05-31 at 16:21 -0700, Patrick Mansfield wrote:
> > [adding hotplug-devel ... maybe Marco or Kay can comment]
> > 
> > On Mon, May 29, 2006 at 07:05:15AM -0600, Matthew Wilcox wrote:
> > > On Mon, May 29, 2006 at 10:38:13AM +0200, Stefan Richter wrote:
<snipp unrelated>
> > > 
> > > That's what scsi_complete_async_scans() is for.  If you have a built-in
> > > module, it will wait for the async scans to finish before we get as far
> > > as trying to mount root.  It does change observable behaviour in that
> > > sys_module_init() will return before scans are complete.  However, I
> > > believe most distros userspace copes with this these days.  For example,
> > > Debian has:
> > > 
> > >     # wait for the udevd childs to finish
> > >     log_action_begin_msg "Waiting for /dev to be fully populated"
> > >     while [ -d /dev/.udev/queue/ ]; do
> > >         sleep 1
> > >         udevd_timeout=$(($udevd_timeout - 1))
> > > [...]
> 
> That has replaced by a binary called "udevsettle" which waits for events
> to finish, by comparing the current kernel event sequence number
> exported in sysfs with the latest handled event by udev.

usb-storage is still giving troubles in that area.
in the case of usb-storage udevsettle exists much too early.
the /sys uevent_seqnum is the same as the udev worked on,
while dmesg is saying:
usb-storage: waiting for device to settle before scanning

it would be really helpful if udevsettle would have an uevent
to wait on. [adding gregkh to cc]

 
> > second, and the udev queue becomes empty even though the scsi /sd scan is
> > still in progress.
> 
> Right. For the settle time of usb-storage we watch for the kernel tread
> to go away. :)

bug reports don't comfirm that statement.
nor do i see any code for it in udevsettle.c.
 
-- 
maks
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
[prev in list] [next in list] [prev in thread] [next in thread]