http://bugzilla.suse.com/show_bug.cgi?id=1051059 http://bugzilla.suse.com/show_bug.cgi?id=1051059#c16 --- Comment #16 from Takashi Iwai <tiwai@suse.com> --- (In reply to Joey Lee from comment #14)

(In reply to Matwey Kornilov from comment #13)

...

(In reply to Joey Lee from comment #12)

...

(In reply to Matwey Kornilov from comment #8)

...

Every other time the resuming just hard-freezes the whole system when showing screen-locker. I think it is related to 1051060. When the system survives resuming I see BUG:

So, the hibernation is success even you saw the "BUG:" stack dump?

Yes, I see this stack after successful resuming.

...

Base on the code in ___might_sleep(), it should not blocks hibernation. It just print out the "BUG" message.

So, then we probably can just ignore them, but they look scary enough.

I agree.

I am thinking to create a new system state like SYSTEM_SLEEPING to avoid the checking logic in ___might_sleep(). I still need to check the scope and it may not accept by upstream.

I'm not sure whether it's safe to assume that. Basically you're calling some sleepable functions like mutex or kmalloc with GFP_KERNEL inside the local irq-disabled context. This may not work. I guess the problem is only in the crypto shash allocation and initialization. If so, a better option would be to move it before the actual swsusp_arch_suspend() call. Maybe we can define swsusp_arch_suspend_prepare() and call it in kernel/power/hibernate.c:create_image() before disabling irq. And call the counter-part swsusp_arch_suspend_post() at the end. Make weak-link dummy functions for these, so that the arch-specific code can be bound as opt-in. -- You are receiving this mail because: You are on the CC list for the bug.