Hi,
On Thu, Apr 26, 2012 at 1:15 PM, Daniel Drake <[email protected]> wrote:
> I can easily reproduce a hang related to loading firmware
> (asynchronously) while going into suspend.
>
> This is running on kernel 3.3.3.
>
> I run:
>
> echo mem > /sys/power/state; echo mem > /sys/power/state
>
> i.e. I tell the system to suspend, and when I wake it up it will go
> very quickly into suspend again.
>
> After waking up, it will start to re-detect the libertas SDIO wifi
> card which was completely powered down during suspend.
> This triggers a firmware loading sequence.
> However, the system then immediately goes into suspend, and at this
> point the system becomes unhappy.
We're still suffering from this issue.
As far as I can see there are 2 items in question:
1. If a firmware load is in-progress as the system goes into suspend,
the relevant userspace processes get frozen and then we have to wait
for the timeout - the firmware loader in the kernel doesn't do
anything special on this important event.
2. There are no safety traps for if a new firmware load request
happens while the system is being suspended with userspace processes
already frozen. Then we have to wait for another timeout.
Do you have any suggested approaches to solve this?
I'm wondering if this is appropriate: firmware_class should add a
pm_notifier so that it is notified when the system is going into
suspend. It would set an internal flag noting that the system is
suspending, and then it can call fw_load_abort() on any active
firmware loads, making them fail immediately.
_request_firmware() would check the internal flag when it is called,
immediately returning failure -ENODATA (?) when the system is going
into suspend.
Does this sound reasonable or should I be looking for another approach?
Thanks,
Daniel