* will these methods work with firmware loading? @ 2012-02-19 18:40 Larry Finger 2012-02-20 9:46 ` Johannes Berg 2012-02-20 10:01 ` Arend van Spriel 0 siblings, 2 replies; 6+ messages in thread From: Larry Finger @ 2012-02-19 18:40 UTC (permalink / raw) To: LKML, driverdevel, wireless, linux-hotplug I sent a previous messages to most of these lists, but got no answer, thus a second try. When a driver loads firmware synchronously in the module_init() path using request_firmware(), then there is trouble with timeouts when booting. I know that changing the request_firmware() call to request_firmware_nowait() solves the problem; however, that gives some trouble for driver b43legacy as it loads 3 or 4 firmware files depending on the hardware version. When I launch the 3 or 4 nowait requests, I get an error because the system is trying to start several tasks with the same name. Would it be OK to load the first file with the nowait version, and issue a request_firmware() for the others from the callback routine? I think that would not cause any problems, but I would like to get confirmation from an expert. Similarly, if I were to create a work queue, init and schedule it from module_init(), and then use synchronous loads to get the firmware from the work queue callback, would that get around the boot problem? I know it works as I have trial patches; however, my version of udev is not one affected. This method is very easy to implement, but again I would like confirmation from an expert. Thanks, Larry ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: will these methods work with firmware loading? 2012-02-19 18:40 will these methods work with firmware loading? Larry Finger @ 2012-02-20 9:46 ` Johannes Berg 2012-02-20 10:01 ` Arend van Spriel 1 sibling, 0 replies; 6+ messages in thread From: Johannes Berg @ 2012-02-20 9:46 UTC (permalink / raw) To: Larry Finger; +Cc: LKML, driverdevel, wireless, linux-hotplug Hi Larry, > I know that changing the request_firmware() call to request_firmware_nowait() > solves the problem; however, that gives some trouble for driver b43legacy as it > loads 3 or 4 firmware files depending on the hardware version. When I launch the > 3 or 4 nowait requests, I get an error because the system is trying to start > several tasks with the same name. > > Would it be OK to load the first file with the nowait version, and issue a > request_firmware() for the others from the callback routine? I think that would > not cause any problems, but I would like to get confirmation from an expert. That should work -- I just looked at the firmware code and it spawns a new thread for every "nowait" request (and it calls the callback in that thread's context), so it won't block against itself. > Similarly, if I were to create a work queue, init and schedule it from > module_init(), and then use synchronous loads to get the firmware from the work > queue callback, would that get around the boot problem? I know it works as I > have trial patches; however, my version of udev is not one affected. This method > is very easy to implement, but again I would like confirmation from an expert. We discussed that before, and technically it should work, I'm just a bit worried about udev treating asynchronous and synchronous requests differently and that causing issues, but somebody who knows udev better will have to comment on that. johannes ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: will these methods work with firmware loading? 2012-02-19 18:40 will these methods work with firmware loading? Larry Finger 2012-02-20 9:46 ` Johannes Berg @ 2012-02-20 10:01 ` Arend van Spriel 2012-02-20 10:19 ` Kay Sievers 1 sibling, 1 reply; 6+ messages in thread From: Arend van Spriel @ 2012-02-20 10:01 UTC (permalink / raw) To: Larry Finger; +Cc: LKML, driverdevel, wireless, linux-hotplug, Kay Sievers On 02/19/2012 07:40 PM, Larry Finger wrote: > I sent a previous messages to most of these lists, but got no answer, thus a > second try. > > When a driver loads firmware synchronously in the module_init() path using > request_firmware(), then there is trouble with timeouts when booting. > > I know that changing the request_firmware() call to request_firmware_nowait() > solves the problem; however, that gives some trouble for driver b43legacy as it > loads 3 or 4 firmware files depending on the hardware version. When I launch the > 3 or 4 nowait requests, I get an error because the system is trying to start > several tasks with the same name. Yep, the nowait api just kicks off a kernel thread for the firmware request. > Would it be OK to load the first file with the nowait version, and issue a > request_firmware() for the others from the callback routine? I think that would > not cause any problems, but I would like to get confirmation from an expert. No expert, but that is what I did although the chaining of firmware requests does not feel great. Especially for handling error flows. Johannes Berg and Kay Sievers mentioned need to unbind/rebind the driver upon failed firmware load, but I don't like the idea of building a timer-controlled retry mechanism. > Similarly, if I were to create a work queue, init and schedule it from > module_init(), and then use synchronous loads to get the firmware from the work > queue callback, would that get around the boot problem? I know it works as I > have trial patches; however, my version of udev is not one affected. This method > is very easy to implement, but again I would like confirmation from an expert. What boot problem are you referring to? The blocking modprobe? For that problem I would say yes. Also here the problem of handling error flows exist. If the driver is kicked of during boot with a initramfs missing the firmware, should we retry until the real root is mounted? Gr. AvS ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: will these methods work with firmware loading? 2012-02-20 10:01 ` Arend van Spriel @ 2012-02-20 10:19 ` Kay Sievers 2012-02-20 10:32 ` Arend van Spriel 2012-02-20 20:12 ` Larry Finger 0 siblings, 2 replies; 6+ messages in thread From: Kay Sievers @ 2012-02-20 10:19 UTC (permalink / raw) To: Arend van Spriel; +Cc: Larry Finger, LKML, driverdevel, wireless, linux-hotplug On Mon, Feb 20, 2012 at 11:01, Arend van Spriel <arend@broadcom.com> wrote: > On 02/19/2012 07:40 PM, Larry Finger wrote: >> Similarly, if I were to create a work queue, init and schedule it from >> module_init(), and then use synchronous loads to get the firmware from the >> work >> queue callback, would that get around the boot problem? I know it works as >> I >> have trial patches; however, my version of udev is not one affected. This >> method >> is very easy to implement, but again I would like confirmation from an >> expert. It sounds like it should work, because the modprobe event returns, not waiting for the firmware request. Chaining one firmware request after the other sounds not like a problem, as long as they are chained with the return from the earlier request and not from inside the earlier request, which would have duplicated device name issues in the kernel too. > What boot problem are you referring to? The pci event calls modprobe, the module init for the pci driver creates a child event of the pci device, this child event is queued in udev to be started after the pci event has finished. The pci event does not finish in time because the firmware request blocks itself. The current udev logic limits the timeout to 30 sec, while the firmware request is 60 sec, so it usually works with a logged error, and a 30 second delay. > The blocking modprobe? Yes, blocking in the module init path, will deadlock udev. Linking code into the kernel must not depend on device init or firmware loading. > For that > problem I would say yes. Also here the problem of handling error flows > exist. If the driver is kicked of during boot with a initramfs missing the > firmware, should we retry until the real root is mounted? I don't think so. Drivers are not supposed to know about bootup or initramfs issues. If they want, they can disable the timeout, and wait for userspace to handle the request any time later, but they should not try to be smart here. Currently, firmware requests are cancelled if the firmware isn't found, but that's a userspace issue, and nothing the kernel should try to work around. Kay ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: will these methods work with firmware loading? 2012-02-20 10:19 ` Kay Sievers @ 2012-02-20 10:32 ` Arend van Spriel 2012-02-20 20:12 ` Larry Finger 1 sibling, 0 replies; 6+ messages in thread From: Arend van Spriel @ 2012-02-20 10:32 UTC (permalink / raw) To: Kay Sievers; +Cc: Larry Finger, LKML, driverdevel, wireless, linux-hotplug On 02/20/2012 11:19 AM, Kay Sievers wrote: >> For that >> > problem I would say yes. Also here the problem of handling error flows >> > exist. If the driver is kicked of during boot with a initramfs missing the >> > firmware, should we retry until the real root is mounted? > I don't think so. Drivers are not supposed to know about bootup or > initramfs issues. If they want, they can disable the timeout, and wait > for userspace to handle the request any time later, but they should > not try to be smart here. > > Currently, firmware requests are cancelled if the firmware isn't > found, but that's a userspace issue, and nothing the kernel should try > to work around. I can not agree more. I prefer to keep my driver happily unaware. I will just take the firmware loading away from the module init path and stop worrying about userspace issues ;-) Gr. AvS ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: will these methods work with firmware loading? 2012-02-20 10:19 ` Kay Sievers 2012-02-20 10:32 ` Arend van Spriel @ 2012-02-20 20:12 ` Larry Finger 1 sibling, 0 replies; 6+ messages in thread From: Larry Finger @ 2012-02-20 20:12 UTC (permalink / raw) To: Kay Sievers; +Cc: Arend van Spriel, LKML, driverdevel, wireless, linux-hotplug On 02/20/2012 04:19 AM, Kay Sievers wrote: > On Mon, Feb 20, 2012 at 11:01, Arend van Spriel<arend@broadcom.com> wrote: >> On 02/19/2012 07:40 PM, Larry Finger wrote: > >>> Similarly, if I were to create a work queue, init and schedule it from >>> module_init(), and then use synchronous loads to get the firmware from the >>> work >>> queue callback, would that get around the boot problem? I know it works as >>> I >>> have trial patches; however, my version of udev is not one affected. This >>> method >>> is very easy to implement, but again I would like confirmation from an >>> expert. > > It sounds like it should work, because the modprobe event returns, not > waiting for the firmware request. Chaining one firmware request after > the other sounds not like a problem, as long as they are chained with > the return from the earlier request and not from inside the earlier > request, which would have duplicated device name issues in the kernel > too. > >> What boot problem are you referring to? > > The pci event calls modprobe, the module init for the pci driver > creates a child event of the pci device, this child event is queued in > udev to be started after the pci event has finished. The pci event > does not finish in time because the firmware request blocks itself. > > The current udev logic limits the timeout to 30 sec, while the > firmware request is 60 sec, so it usually works with a logged error, > and a 30 second delay. > >> The blocking modprobe? > > Yes, blocking in the module init path, will deadlock udev. Linking > code into the kernel must not depend on device init or firmware > loading. > >> For that >> problem I would say yes. Also here the problem of handling error flows >> exist. If the driver is kicked of during boot with a initramfs missing the >> firmware, should we retry until the real root is mounted? > > I don't think so. Drivers are not supposed to know about bootup or > initramfs issues. If they want, they can disable the timeout, and wait > for userspace to handle the request any time later, but they should > not try to be smart here. > > Currently, firmware requests are cancelled if the firmware isn't > found, but that's a userspace issue, and nothing the kernel should try > to work around. Kay, Thanks for your very helpful comments. I think I will keep my second method, i.e. start a work queue entry from the probe routine, and then use synchronous firmware loads from that queue's callback routine. In most cases, the firmware loading is already done from a separate routine, thus the flow is not that different from the current code. Larry ^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2012-02-20 20:12 UTC | newest] Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2012-02-19 18:40 will these methods work with firmware loading? Larry Finger 2012-02-20 9:46 ` Johannes Berg 2012-02-20 10:01 ` Arend van Spriel 2012-02-20 10:19 ` Kay Sievers 2012-02-20 10:32 ` Arend van Spriel 2012-02-20 20:12 ` Larry Finger
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).