Re: Wait for console to become available, v3.2

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Tue, 21 Apr 2009, David VomLehn wrote:

> The current patch already uses a waitqueue and wakes up as soon as a console
> is registered, so that's the same. I agree that the other piece is determining
> when all USB devices at boot time have been probed. For this suggestion to
> work, two conditions must be met:
> 1.	The USB hub driver becoming idle must indicate that every device has
> 	been probed.

That's not exactly right.  When a new hub is registered, the hub driver 
doesn't become idle until after all the devices plugged into that hub 
have been initialized and probed.

So the hub driver becoming idle indicates that every device attached to
any registered USB host controller has been probed, but there may still
be some unregistered controllers.  This won't be an issue if you first
wait for all the new async probing stuff to end; by then all the PCI 
devices (including USB host controllers) should be registered.

> 2.	The USB driver must become idle after every USB device has been
> 	probed.

Under normal conditions it will.  There are some abnormal conditions
which cause the hub driver never to become idle, such as a faulty
device that continually connects and disconnects itself electrically
to/from the USB bus.  (Each connection event will create more work for
the hub driver.)  I have seen reports of this sort of thing.

I guess a better criterion would be for the hub driver to maintain a
count of registered but unscanned hubs.  That wouldn't be subject to
quite the same starvation issue.  Although there is another issue which
occasionally comes up with buggy devices: The hub driver's
device-initialization procedure has so many retries and timeouts that
it can take several minutes before the driver gives up on a bad device.

> If both conditions are met, this is a superior to a timeout for determining
> that the console will not show up. It would surprise me a bit if the first
> condition was true.

Why?  Doesn't it make sense that the hub driver would remain running as 
long as there was still work for it do to?

>  Still, if it is true that the USB hub driver will be
> idle for some interval I, where I is greater than the timeout we would
> otherwise use, it is still a better approach.
> 
> There is one other possible gotcha to this approach. The code as I wrote it is
> bus-agnostic, i.e. it has no idea where the console is located. As far as
> I know, the long time to probe possible console devices only arises with
> USB. If this is not tree, we need to handle any other cases that can arise.

That is a very good objection.  For this sort of approach to work,
ultimately it would have to be implemented for every hotpluggable bus
of interest.

> > >  But a bigger
> > > drawback is that you lose the ability to chose appropriate intervals for
> > > different classes of devices.
> > 
> > Why do you need to choose any intervals at all?  Just keep waiting
> > until you know there's no point waiting any longer.  If you stop 
> > waiting before then, you run the risk of missing a device that could 
> > have worked.
> 
> The question about appropriate intervals is that I need to wait for some
> devices, like consoles and network devices, but not all devices, like printers
> and cameras. There is no telling whether any two devices require the same
> interval when I am tuning it for my particular system. And if I have a USB
> console and no USB Ethernet device, I only want to wait for the console
> probe interval.

I still don't understand.  Let's say you want the console init code to
wait for the preferred console device to be registered, and that device
could potentially be either a USB serial or a USB network device.  And
let's say that your system has a USB serial device but no USB network
devices.

The console delay routine will then wait until the USB serial device is
discovered and registered, at which point its job is done.  It won't
continue to wait until all the USB devices present at boot time have
been probed, since there's no reason to wait after the first console
device is discovered.

So not only would you not need to tune two different delay times, you 
wouldn't even need to tune one!  You wouldn't need to specify any delay 
times at all.

> I'm kinda flexible about whether all possible consoles show up; the patch
> presently only waits for a console to be identified as the "preferred" console.
> This gets the system going as soon as you have some place to write output,
> but I won't argue with anyone who says we need to wait for all possible
> consoles.

Which essentially means waiting until _all_ the devices present at boot 
time (both USB and non-USB) have been probed.  Right?  And it 
explicitly means ruling out waiting for new devices which the user 
might plug in after the system has booted, since a new console device 
could be plugged in at any time.

> > Now the only drawback I can see would crop up if some device takes a
> > very long time to probe (perhaps because of errors and retries).  If
> > there's no other console device, it could slow down the boot procedure
> > quite a lot.  But there doesn't appear to be any logical alternative,
> > given your goals as stated above.
> 
> If there is a way to guarantee that we are done with the probing, I'm
> all for using that. Will waiting for the USB hub driver to be idle do this?

I'm pretty sure something like it can be made to work, subject to the 
delays caused by bad devices.

Alan Stern

--
To unsubscribe from this list: send the line "unsubscribe linux-embedded" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Index of Archives]     [Gstreamer Embedded]     [Linux MMC Devel]     [U-Boot V2]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux ARM Kernel]     [Linux OMAP]     [Linux SCSI]

  Powered by Linux