Re: Firmware class breaks udev

[Hannes Reinecke <hare@suse.de>]

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
- 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.

Cheers,

Hannes
-- 
Dr. Hannes Reinecke			hare@suse.de
SuSE Linux AG				S390 & zSeries
Maxfeldstraße 5				+49 911 74053 688
90409 Nürnberg				http://www.suse.de


-------------------------------------------------------
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Ãk
_______________________________________________
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