Comment 17 for bug 36944

This last one that comes back immediately is easy:

  swsusp: Need to copy 47008 pages
  swsusp: Not enough free memory

Matthew, I've forgotten, is that a shortage of swap, or a shortage of RAM to bounce pages around in? But we can ignore this one.

However, the bigger problem is the one that *fails* on unhibernate and leads to a kernel backtrace:

swsusp: Reading pagedir (125 pages)
busybox: page allocation failure. order:0, mode:0x8020
 [__alloc_pages+494/736] __alloc_pages+0x1ee/0x2e0
 [get_zeroed_page+34/80] get_zeroed_page+0x22/0x50
 [alloc_data_pages+55/208] alloc_data_pages+0x37/0xd0
 [read_suspend_image+155/192] read_suspend_image+0x9b/0xc0
 [swsusp_read+21/64] swsusp_read+0x15/0x40
 [software_resume+119/224] software_resume+0x77/0xe0
 [resume_store+161/164] resume_store+0xa1/0xa4
 [flush_write_buffer+39/48] flush_write_buffer+0x27/0x30
 [sysfs_write_file+63/96] sysfs_write_file+0x3f/0x60
 [vfs_write+150/336] vfs_write+0x96/0x150
 [sys_write+56/128] sys_write+0x38/0x80
 [syscall_call+7/11] syscall_call+0x7/0xb

Is this race to do with processes (eg. the busybox that initiated the unhibernate) continueing to run and no longer being able to access resources because they have, or are in the process of being, overwritten?