lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Sun, 29 Apr 2012 18:18:35 -0600
From:	Daniel Drake <dsd@...top.org>
To:	"Rafael J. Wysocki" <rjw@...k.pl>
Cc:	Linux PM list <linux-pm@...r.kernel.org>,
	linux-kernel@...r.kernel.org
Subject: Re: Hang while loading firmware when going into suspend

On Sun, Apr 29, 2012 at 3:46 PM, Rafael J. Wysocki <rjw@...k.pl> wrote:
> On Thursday, April 26, 2012, Daniel Drake wrote:
>> Hi,
>>
>> 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.
>
> Is this a new bug or did we do that before too?

It's hard to say. Now that drivers aren't allowed to load firmware
from probe(), we've had to convert libertas to use asynchronous
firmware loading, which has moved things around quite a bit, and we're
only now getting wide testing on the new libertas-async-firmware code.

> OK, so the system suspends eventually?

Yes - exactly two minutes after starting to suspend.

>> Sidenote:
>> There is a driver race in the current libertas code - in the above
>> situation it will attempt to call the driver suspend routine even if
>> probe hasn't finished (i.e. async firmware loading still underway). I
>> have that solved locally in the tests above - the suspend routine will
>> detect that probing/firmware loading is still ongoing and wait for
>> that to complete before asking the hardware to suspend. However, in
>> testing this change, I am facing the above issue with the firmware
>> loader behaving badly when going into suspend.
>
> That looks like a bug in the driver, to be honest.  I'll have a look at it
> in the next few days.

A libertas driver bug, you mean?
Yes, it is definitely a bug that libertas suspend routine will not
wait for any ongoing firmware loading before trying to do
suspend-related  stuff with that device.
However, I have that solved locally. The suspend routine is now hooked
up to behave properly. Now what I'm facing is problems with (described
in the above mail) is what happens when firmware is being loaded and
the system starts to suspend - i.e. a problem on a very generic basis,
as far as I can see.

Thanks,
Daniel
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ