Hrm... the joy if swsusp putting your disk to sleep just to wake it up
right away... I need to check if I can differenciate suspend-to-disk
from suspend-to-ram here to just not put the drive in STANDBY mode
on suspend-to-disk (just freeze the queues)
> Writing data to swap (2273 pages): .<3>bad: scheduling while atomic!
Here's the real one. However, it doesn't look related to my sleep code,
though I cannot guarantee this for sure right now, it _seems_ it's
a swsusp bug you are hitting.
> Call Trace:
> [<c011d958>] schedule+0x40/0x388
> [<c011eb02>] io_schedule+0xe/0x18
> [<c01384d5>] wait_on_page_bit_wq+0xc9/0xe4
> [<c011f320>] autoremove_wake_function+0x0/0x3c
> [<c011f320>] autoremove_wake_function+0x0/0x3c
> [<c01384fa>] wait_on_page_bit+0xa/0x10
> [<c014cc34>] rw_swap_page_sync+0x98/0xc6
> [<c0136afd>] write_suspend_image+0xf1/0x324
> [<c0246bdf>] device_resume+0x7f/0x88
> [<c01370e1>] drivers_unsuspend+0x11/0x18
> [<c013735e>] suspend_save_image+0x12/0x1c
> [<c013753f>] do_magic_suspend_2+0x17/0xa8
> [<c011ba9d>] do_magic+0x4d/0x130
> [<c013763b>] do_software_suspend+0x6b/0x90
> [<c0137695>] software_suspend+0x35/0x3c
> [<c012ba97>] sys_reboot+0x2df/0x36c
> [<c0143830>] unmap_page_range+0x38/0x5c
> [<c0143959>] unmap_vmas+0x105/0x208
> [<c01656e4>] dput+0x1c/0x204
> [<c01656e4>] dput+0x1c/0x204
> [<c015d367>] path_release+0xf/0x30
> [<c014fe69>] sys_chdir+0x5d/0x68
> [<c010af17>] syscall_call+0x7/0xb
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/