== Summary ==
On my computer with an ancient Nvidia chipset (Geforce 7025/nForce 630a), running `sysctl suspend` (or suspending from the Gnome menu) causes the system to start suspending, but it freezes halfway, leaving fans and hard drives spinning. There’s no way to resume from this frozen state apart from forcing a reboot (with a hardware reset button/poweroff).

== Steps to reproduce ==
* boot with modeset enabled
* run `sysctl suspend`

== What I expect to happen ==
For the system to suspend, shutting down all fans and hard drives.

== What happens ==
The system begins to suspend, but freezes halfway, leaving the display on and fans and hard drives spinning, but the keyboard unresponsive.

== Workaround ==
Disable kernel modesetting by adding ”nomodeset” to the kernel commandline.

== Affected kernels ==
Prior to upgrades the system was running HWE kernel 5.15.0, so I tried the 5.15 series, and found that I could now suspend and wake the machine again just as before. I worked my way up the versions:

* 5.15.50: unaffected
* 5.15.165: unaffected
* 5.19.17: unaffected
* 6.4.0: unaffected
* 6.6.0: unaffected
* 6.6.48: unaffected
* 6.7.0: first to fail

I also tried the current newest mainline kernel 6.10.7, and the issue is still present there.

== Background ==
I have an old desktop machine now functioning as a NAS, and yesterday I upgraded it from Ubuntu 20.04 first to 22.04, and then all the way up to 24.04. The upgrade went smoothly, and this is the only issue I’ve come across since.

In the BIOS settings of the affected machine there are three ”suspend mode” alternatives to choose from: ”S1 (POS) only”, ”S3 only” and ”Auto”. I’ve always had it on ”Auto”, but with this issue I also tested both ”S1 only” and ”S3 only”, with no effect.

The issue is also present when booting from the installation media (USB) into a live environment.

I’ve previously upgraded my laptop to 24.04, and there suspending still works as it did before the ugprade, so this is probably hardware-specific; the laptop is a modern one with all-Intel hardware.

Googling around, I could smelled hints of this being once again related to the troublesome Nvidia chipset, so I tried nomodeset with the stock 6.8.0 kernel (6.8.0-41 currently) and voilà! Suspend and wake were working again.

Well, except for the display, which stayed black. But I couldn’t say if this was the way it was before, because the NAS is normally running headless.

The system in question is currently out of use (and reproducing the bug isn’t straightforward), so I’ll let this one expire.

FWIW, based on the above comments and my experience I’d lay at least some of the blame on this on nouveau: I have two setups affected by the Plymouth no-show, both with Nvidia graphics:

01:00.0 VGA compatible controller: NVIDIA Corporation G73 [GeForce 7300 GT] (rev a2) (prog-if 00 [VGA controller])
and
00:0d.0 VGA compatible controller: NVIDIA Corporation C61 [GeForce 7025 / nForce 630a] (rev a2) (prog-if 00 [VGA controller])

At the same time all the other systems I have access to that run Precise on non-Nvidia graphics (some half dozen computers, old and new) don’t manifest it, i.e. they display Plymouth’s boot logo screen just fine on every boot without any workarounds. (The Nvidias need either FRAMEBUFFER=y or plymouth:force-drm.)

Also, on the G73, Grub menu shows at a low resolution without GRUB_GFXMODE specified, but on the C61 it’s ”Out of range”. It shows on both if I specify 1280×1024 (the maximum supported by the connected LCDs) as GRUB_GFXMODE. This too is Nvidia-specific, though I suppose the Grub menu is outside nouveau’s jurisdiction.

Most of the problems (”freezing”) seen by the user would probably fall under Bug #994306, which I’ve now witnessed on this system. The one I reported above is different, and apparently much rarer in occurrence.

This happened after about 30 minutes of watching a flash video in fullscreen (using Firefox): the video froze, leaving just the audio playing, and the display no longer responded to user input until I ssh’d in and killed gnome-session for the user (after which LightDM login came up and things worked again).

According to user this freezing has been occurring daily, sometimes multiple times a day, since upgrading to Precise. It never occurred with Lucid.

We’ve yet to try if using 2D desktop or disabling KMS helps.

(Apport wouldn’t send this report without me lying to it that I was referred here by tech support, but I wasn’t.)

Bug #994203 looks similar, but it’s about NV4e whereas this is an NV4c.

Ah, sorry about that, I thought you wanted both updated logs from Lucid *and* tests with newer versions.

I just gave the current 12.04 Beta a spin and am happy to report that the issue seems to have been fixed there: despite my best efforts I couldn’t make it crash with the gallery site. It did remain somewhat sluggish to browse but the Oops never occurred.

I cannot get X working with the latest Mainline build for Lucid (2.6.35-rc1-lucid [1]) nor with linux-image-generic-lts-backport-maverick (which I figured I’d also try, as it’s also a build of 2.6.35). Both end with ”[drm] failed to open device” and ”No devices detected” in the log (I’ll attach one to this comment).

If I’m interpreting Nouveau Wiki’s Troubleshooting document [2] and the logs correctly, KMS is working (fb0 is there), which means there’s ”a version mismatch between the Nouveau DRM and libdrm”. Any help there would (also) be appreciated.

*[1] http://kernel.ubuntu.com/~kernel-ppa/mainline/v2.6.35-rc1-lucid/
*[2] http://nouveau.freedesktop.org/wiki/TroubleShooting#Xorg_fails_to_start_with_.22.28EE.29_.5Bdrm.5D_failed_to_open_device.22

Timothy, does your harware setup match? You’re using the internal Nvidia graphics and not an add-on card?