Re: Firmware class breaks udev

[Greg KH <greg@kroah.com>]

On Tue, Mar 15, 2005 at 02:09:17PM +0100, Hannes Reinecke wrote:
> Kay Sievers wrote:
> > On Tue, 2005-03-15 at 09:25 +0100, Hannes Reinecke wrote:
> > 
> [ .. ]
> >>
> >>If you have a look at the firmware class you'll see exactly what happens:
> >>The class insists on sending their own firmware events during
> >>initialisation. This code is typically executed during device probing,
> >>so the modprobe for this device will still be running when the firmware
> >>event is triggered.
> > 
> > But as soon as modprobe finishes, which should happen in the same
> > second, the class/firmware event should be started. How can this happen?
> > We have usually 10 seconds to upload firmware.
> > 
> This is not what happens.
> modprobe will return _after_ device initialisation finished, ie after
> the firmware is loaded (or not, as the case might be).
> The firmware event is triggered when modprobe is still running, so udev
> thinks the device is still initialising and waits until modprobe returns
> before executing that event.
> As no firmware is loaded (the firmware event is still in the exec queue
> waiting for modprobe to return), firmware class eventually timeouts.
> Then modprobe returns, causing the firmware event to be executed.
> But by then the timeout has already been triggered and the upload will fail.
> 
> Increasing the timeout to '0' will only cause udev to wait forever.
> 
> >>Which is also why you're seeing this only when using the events
> >>themselves, as when executing modprobe directly udev is only started for
> >> the firmware event, which will succeed as no physical device event is
> >>in the queue.
> >>
> >>For now I'll be putting in a quick exit for firmware events (ie not wait
> >>for the devices initialisation to finish) but this is nevertheless _nasty_.
> > 
> > The time I stumbled across a similar problem with the firmware class, I
> > thought about adding a TIMEOUT= to the hotplug environment which udev
> > can use to prioritize such events. But we should better replace
> > class_firmware.
> > 
> That's what i thought also. (That's why I named the variable 'timeout').
> 
> >>Currently the firmware class is definitely not compliant to the driver
> >>model.
> > 
> > Yes, it is a dirty ugly hack: It suppresses the kobj_add event with a
> > hotplug filter, later switches off the hotplug filter and creates a new
> > event by itself. I have several oopses recorded with the current
> > firmware_class if we still access the data file while the timeout
> > happens. 
> > 
> No wonder.
> 
> >>So either we should fix the firmware class or extend the driver
> >>model to allow for such beasts; Kay, your kobj hotplug extension might
> >>be a way to go.
> > 
> > I stumbled across this while trying a new way of loading userspace data
> > into the kernel. And I wanted control over the hotplug events. The
> > kobject/event split is a direct fallout of that. :)
> > 
> [ .. ]
> > That way we would get a generic way to request any data from userspace
> > and events that belong to a specific driver or device and not some fake
> > device in the firmware_class.
> > 
> 
> The main problem is that firmware downloading does not fit in well with
> the established functionalities:
> 
> - modprobe returns after the device is fully initialised.
>   -> firmware has to be loaded during modprobe, ie events have to
>      be handled during modprobe

That can be changed, modprobe can return before the device is
initialized.  I can change the driver to do this, if you wish.

> - hotplug events are sent when the device registers itself with sysfs
>   -> devices with firmware will then not be fully initialised
>   -> the current hotplug subsystem does not distinguish between
>      states 'device detected' and 'device initialised',
>      so you can't model the firmware behaviour directly onto
>      the linux hotplug subsystem.

Kay has a patch for that, which I will add to the tree in a few hours.

So, with your udev patch, is there still an immediate problem that needs
to be fixed?

thanks,

greg k-h


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_ide95&alloc_id\x14396&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