Comment 5 for bug 754711

This failure is due to the lack of a sufficiently large virtual address range available in the vmalloc area to satisfy what the driver is asking for at suspend to store GPU objects. A quick Google search shows a lot of reports of nouveau being a vmalloc hog for normal operation, neglecting suspend, so it may be doing itself in here. Or there could other drivers contributing to heavy vmalloc usage. I don't know if there are any tools to analyze how the kernel vmalloc space is being used; I'll look to see if I can find any.

Realistically the only options are probably to either reduce vmalloc usage or increase vmalloc size. The simple solution is to follow the advice of the kernel and pass vmalloc=<size> on the command-line (maybe start with 128M and go from there). Another (much more complicated) potential solution would be to see if it's possible to unmap the driver mmio space at suspend and remap it at resume.

Running a 64-bit kernel should also take care of the problem.