The latest kernel 4.0 might be of help, but you may need to rebuild against it extensively as well as X.

Nouveau is not the best driver for Nvidia cards, but oddly there are many bad Nvidia cards with improper timings that hurt things too. Unfortunately sometimes no driver really helps.

Well, for the case of the GeForce Go 7300 (from 2007), it all worked fine (2D, 3D, suspend, hibernate, resume) with Debian Wheezy (but not with Ubuntu 12.04, which also used kernel 3.2). So the functionality was there and now it's gone and getting worse. As things stand, peoples GPUs are locking up even just using a straight-up console without X even running. I can't speak for any of the other NVidia cards. Love it or hate it, the NVidia driver probably works better because it's developed outside of the kernel and can be compiled against a wide variety of supported kernels. Why do we even need nouveau IN the kernel anyway? At the rate stuff is supposedly fixed, more bugs are introduced and never get fixed because the next kernel release is ready. And those seem to come faster and faster nowadays.

Nouveau was supposed to be a Gallium API driver to replace the nv driver that was halted in development for the free drivers, but it's far from perfect. It's development has been aimed at Wayland mostly since everything is trying to transition to EGL as a method of accelerating 2D and 3D across a universal API layer. The problem is Nouveau is developed from data collected via reverse engineering efforts using technical readouts of data passed through the OEM drivers. This often leaves only partial data from older chips as most older drivers aren't ran well on newer xorg-server releases, or not ran at all. At best, you really need a GeForce 8x00 series card or later to use Nouveau really well, but even then it's a gamble.

I realize this thread is now quite old, but it seems this problem is not getting better. Judging by the large number of complaints regarding nouveau and suspend/hibernate issues with other distributions, and that this thread seemed to still get more views, I thought I would update this a bit.

I was able to work around this issue in BLFS by re-compiling kernel 3.2 (LTS, supported at kernel.org). I should add, however, that nouveau will not show up in menuconfig as is. You will also need the Debian patches located at https://packages.debian.org/source/wheezy/linux. Untar this archive and only apply the patches in the folder debian/patches/features/all/drm in the order that they are listed (and no other patches if you wish to stay close to upstream). Whatever magic juice is in these patches actually works, and now I have more than sufficient 3D effects with reliable suspend/hibernate with the nouveau driver.

This means that these problems are with the kernel driver, namely nouveau_drm, and not anything dealing with X. I should add that I did not recompile X or anything else, and just "dropped in" the 3.2 kernel into an existing BLFS setup. (The only artifact is that iptables complains of not having the module XT_LOG, as according to cateee.net this was added in kernel 3.4.)

Now, actually fixing the issue in more recent kernels is a whole other animal. In my case, about 1 in 3 times I cannot even boot the latest System Rescue CD into X without getting a locked up, garbled mess. At this point the only way out is to use an earlier kernel or the unthinkable, replacing the graphics card.

I was finally able to get a similar laptop recently to test a GeForce Go 7350 (an OEM minor variation of the 7300) and got similar results to my 9800GT and Go 6150, so unfortunately I can not reduplicate your problem Ordeal.

I have build the following packages using book 7.8 and development books:

xf86-video-nouveau-1.0.11
libdrm-2.4.65
linux-4.2.4
mesa-11.0.3
xorg-xserver-1.17.2
llvm-3.7.0

I can boot with complete KMS support, full hardware acceleration.

Not to ask, but have you tried testing another OS against the video card? If you have to revert to those kernels and such it could be possibly some underlying hardware issue.

My apologies for the delay. Having been ill this week I didn't get to do too much in detail. Today I got a minimal Devuan install going. This is a bare-bones setup from the latest netinstall image and updated to whatever is current as of last night. All I did was run "sudo apt-get install xinit glxgears pm-utils". The goal is to have something 3D enabled at the time suspend/hibernate is invoked - this would be basically the same as having a full desktop environment with e.g. compiz or kwin running. Running "glxgears && pm-hibernate" should suffice but I can't even get that far. For about 1 in 4 attempts I cannot successfully start X as all I get is a purple/white garbled mess. I never get anything useful in the logs because apparently the whole system hangs. I have to do a hard reset and fsck runs automatically each time.

For the other attempts, I can start X but glxgears seems to hang after a second or two. Pressing CTRL+C does not work. I have to switch to another tty and kill X (killing glxgears does nothing). I tested a similar Devuan setup under QEMU on BLFS and glxgears worked fine, so I can rule out a faulty program. Again nothing out of the ordinary appears in the logs. Now I'm installing antiX (based on Devuan but uses kernel 4.0, I believe).

Have you ruled out hardware failure? Getting a garbled screen, crashes, etc. is a tell-tale sign something is wrong, and really wrong that software won't be fixing.

Well, I suppose anything's possible. But I never have these problems when I'm not using the nouveau driver after kernel 3.2 or the NVIDIA driver with any kernel (except 3.14, which didn't play nice with the particular NVIDIA driver version that I tested). Otherwise I can routinely suspend/hibernate/resume for literally 100+ days without any issues until something goes bad, typically a file system wanting checked, etc., but never anything display related. I haven't tested kernels 3.3-3.6 yet but I would wager that a nouveau rewrite circa kernel 3.7 has much to do with this.