From mboxrd@z Thu Jan 1 00:00:00 1970 From: Greg KH Date: Tue, 15 Mar 2005 16:20:52 +0000 Subject: Re: Firmware class breaks udev Message-Id: <20050315162052.GA24796@kroah.com> List-Id: References: <42369BE6.7020807@suse.de> In-Reply-To: <42369BE6.7020807@suse.de> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: linux-hotplug@vger.kernel.org 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_id396&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