I have a Dell Dimension 3000 desktop computer with an integrated Intel i865 and a VGA LCD monitor. With the Intel graphics, suspends and resume works fine. Add a PCI geforce 6200 in there, with either the nouveau or nvidia driver, and it never resumes from suspend. Screen is black (no signal/monitor stays in low power mode), keyboard numlock LED not responding, machine does not respond to ping or SSH. Therefore, even though I booted with "log_buf_len=1M drm.debug=14 nouveau.reg_debug=0x0200" ... if I can't actually access the logs on resume, it's no good. Attaching dmesg, lspci -vvvv, Xorg.0.log, in the hope this can give some indication on my hardware. Please tell me how to debug this. I'd love to get this machine up and running GNOME3 quickly.
Created attachment 510546 [details] lspci -vvvv
Created attachment 510547 [details] dmesg Under normal operation
Created attachment 510548 [details] Xorg log
I forgot to mention: this bug also occurs when running the kmod-nvidia package...
Can you boot with "nomodeset 3" (which will leave you at a VGA text console), log in, "modprobe -r nouveau nvidia", and then suspend with "echo mem > /sys/power/state". After you resume, can you access the machine with ping and/or ssh? You definitely won't have an image on the screen, that's expected, there should be no driver to attempt to resume.
After doing what you suggested, here are my observations upon resume: - the screen does not turn back on (as you predicted) - the numlock key LED indicator works, and hitting ctrl+alt+delete reboots - ping and SSH work
Interesting. The video driver is definitely to blame in some way then. After doing this, can you login via ssh and "modprobe nouveau modeset=1" successfully?
Yes, doing the same process as in comment 5 and then doing "modprobe nouveau modeset=1" ...through SSH after resuming does light up the screen and display the text console (in full resolution, nothing less!)
Interesting! Booting normally with the "nomodeset" parameter, the computer can suspend/resume fine into GNOME. Haven't tested with the nouveau driver yet, but I suspect it will be the same.
Testing with the nouveau driver, nomodeset does not work (X uses the VESA driver instead of nouveau) and nouveau.modeset=0 or 1 or 2 doesn't work either... but I guess that's expected, nouveau doesn't support UMS and is KMS only as I understand it. Combined with bug 718000, being unable to sleep/resume means I'm stuck on the nvidia proprietary driver for now.
Hmm, how very odd. We can initialise your card from scratch after a suspend/resume, but not resume properly. I'm not certain you'll be very successful here, but unless you have a serial console available it's the best option. Are you able to setup netconsole (make sure you append "no_console_suspend" to your boot options) and attempt to catch some form of output from the kernel on resume? I've made a note to test a GF6/7 card of mine to make sure this isn't a general breakage of those that has gone unnoticed.
Sadly I think using netconsole is a bit beyond my skills and my ability to access that machine (now that it has found an owner, I can't experiment on it for days on end). Have you had time to test with similar cards? Does the fact that it's a PCI card (not PCI-E) change anything? The video card in question is http://ncix.com/products/?sku=36679
Ben, any news on this? Have you managed to test with your hardware? With latest updates, it now seems the proprietary nvidia driver with nomodeset doesn't work with suspend either (the screen turns on but stays black). I'm pretty much stuck with a computer that won't wake up from suspend no matter what the driver is.
Can you give this kernel a try: http://koji.fedoraproject.org/koji/buildinfo?buildID=261186 It's a worry that it doesn't even work with the binary driver now though, it seems likely something else is busting resume too, which might make it difficult to see if this fix helps!!
Hi Ben, I applied all the latest updates in Fedora including the kernel update to 2.6.40.4-5.fc15.i686, and suspend/resume is still broken with the binary driver. Tried installing the rpm file you linked to in comment 14 afterwards, but packagekit says it's the same version as the one I have installed.
(In reply to comment #15) > Hi Ben, I applied all the latest updates in Fedora including the kernel update > to 2.6.40.4-5.fc15.i686, and suspend/resume is still broken with the binary > driver. And what about with nouveau? There's not much we can do to fix the binary driver. > > Tried installing the rpm file you linked to in comment 14 afterwards, but > packagekit says it's the same version as the one I have installed.
This message is a notice that Fedora 15 is now at end of life. Fedora has stopped maintaining and issuing updates for Fedora 15. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At this time, all open bugs with a Fedora 'version' of '15' have been closed as WONTFIX. (Please note: Our normal process is to give advanced warning of this occurring, but we forgot to do that. A thousand apologies.) Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, feel free to reopen this bug and simply change the 'version' to a later Fedora version. Bug Reporter: Thank you for reporting this issue and we are sorry that we were unable to fix it before Fedora 15 reached end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged to click on "Clone This Bug" (top right of this page) and open it against that version of Fedora. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping