Bugzilla – Bug 113064
No backlight after suspend-to-disk
Last modified: 2006-04-19 19:00:38 UTC
With beta3 after suspend-to-disk I get a black-screen with the newest nVidia drivers (tested 7167 and 7676). In beta2 this worked. The state of the machine is somehow unclear: I can access it by ssh, but if I press Ctrl+Alt+Del it seems to make a reboot (therefore I guess, that there's no KDE restarted). Nevertheless, the reboot hangs, so that I can onyl hard reset the maschine. It's a Dell Inspiron 8600. Worked very well with 9.3 and OSS 10.0 beta2. Suspend-to-RAM is still not working because of the backlight. Worked once with the 6xxx-nVidia drivers.
Without X powersave -U works fine, even if the nvidia module is loaded. So this might be a problem not related to the nvidia driver. Please see also bug 113059 Nevertheless powersave -u gives me only a black screen back. I will try vbetool here.
Please attach results of nvidia-bug-report.sh.
After login via SSH I see now, that X hangs with 99% CPU killall -9 X makes the machine totally freeze. nvidia-bug-report.sh will follow soon.
Created attachment 47707 [details] nVidia Logfile Bugreprort created after starting the system, just after X failed to start.
Sorry, attachment (id=47707) was meant for bug 113059.
Created attachment 47710 [details] nVidia Logfile Log created via SSH after the screen remained black. ps -ax showed X with 99,9%
This looks indeed like a nvidia driver problem: (II) NVIDIA(0): Setting mode "1680x1050" (WW) NVIDIA(0): WAIT (2, 1, 0x8000, 0x00001258, 0x000012f8, 0) (WW) NVIDIA(0): WAIT (1, 1, 0x8000, 0x00001258, 0x000012f8, 0)
On the other hand, the same driver worked with beta2.
Hmm ... that's correct. The driver hasn't changed between Beta2 and Beta3.
Tried it after adding nvidiafb to the blacklist, but no change :-( In /var/log/messages I found this: Aug 26 10:24:54 linux kernel: NVRM: RmPowerManagement: 4 [...] some tasks are restarted Aug 26 10:25:01 linux kernel: NVRM: Xid: 25, L1 -> L0 Aug 26 10:25:01 linux kernel: NVRM: Xid: 8, Channel 0000000d Aug 26 10:25:25 linux kernel: NVRM: Xid: 25, L0 -> L0 Aug 26 10:25:25 linux kernel: NVRM: Xid: 8, Channel 0000000d Aug 26 10:25:33 linux kernel: NVRM: Xid: 8, Channel 0000000d Aug 26 10:25:41 linux kernel: NVRM: Xid: 8, Channel 0000000d Aug 26 10:25:49 linux kernel: NVRM: Xid: 8, Channel 0000000d Aug 26 10:25:57 linux kernel: NVRM: Xid: 8, Channel 0000000d Aug 26 10:26:05 linux kernel: NVRM: Xid: 8, Channel 0000000d Aug 26 10:26:13 linux kernel: NVRM: Xid: 8, Channel 0000000d Aug 26 10:26:21 linux kernel: NVRM: Xid: 8, Channel 0000000d Aug 26 10:26:29 linux kernel: NVRM: Xid: 8, Channel 0000000d Aug 26 10:26:37 linux sshd[5800]: Accepted keyboard-interactive/pam for root fro m 192.168.1.96 port 20057 ssh2 Aug 26 10:26:37 linux kernel: NVRM: Xid: 8, Channel 0000000d Aug 26 10:26:45 linux kernel: NVRM: Xid: 8, Channel 0000000d Aug 26 10:26:53 linux kernel: NVRM: Xid: 8, Channel 0000000d Aug 26 10:27:01 linux kernel: NVRM: Xid: 8, Channel 0000000d
Looks like you're commenting to the wrong bugreport ...
No :-) As blacklisting the nvidiabf module helped for starting the system, I hoped (yes I realy hoped), that blacklisting resolves also this one. But it didn't. So the /var/log/messages is chatched from after resume, via SSH.
But this was a completely different system with different problems ...
No, it's the same laptop, same beta, same nVidia driver.
Ok. So we see two different problems related to the nvidia driver 1: nvidiafb module loaded (fixed, no longer loaded by default) 2: Suspend to RAM broken Since Suspend to RAM did work with Beta2 with the same nvidia driver it might be a kernel related problem.
1: Yes. 2: The bug is about suspend-to-disk (that's why I marked it as major). Suspend-to-ram doesn't work neighter, but this is a second pair of shoes.
Adjusted severity. You might understand, that it isn't easy for us to investigate problems in proprietary drivers.
If this is a regression between beta2 and beta3, I would start by investigating what power management changes went in between those two milestones. You might also experiment with things such as disabling AGP (are the AGP chipset registers not getting restored properly?), or forcing use of NVAGP rather than AGPGART. NVIDIA's power management is unfortunately not terribly reliable at this time. We hope to improve this in the future.
Current state (RC1): With nVidia Without nVidia Suspend-to-Disk no backlight* OK Suspend-to-RAM no backlight no backlight Standby OK OK * worked with 9.3 and 10.0 beta2. All tests made with driver 7671. I will make some more tests this evening.
Please try again with Kernel of Beta2. So we can see if it's really related to the kernel.
Can you provide me an RPM for download please. I do not have the beta images anymore.
Sorry, I don't have them either. Looks like we removed them :-( Maybe someone on suse-beta-e?
Installed beta2 kernel on RC1 and made some tests. After suspend-to-disk I can see the graphical boot-screen and some console messages, but then the display get's black. Tested nVida drivers 7167 and 7676. Without X it works fine. So the problem seems to be related to X/KDE and not kernel/nvidia. Meanwhile I tested vbetool, too. Works fine but not with nVidia drivers. If I use the vNivia drivers the display lightening comes back, but there are only dark grey, blue and green artefactes on the display (very ugly). I remember to have seen these also, when the display tried to activate some DPMS features. Will make some tests with nvagp instead of agpgart, soon.
Some more tests: Seems, that intel-agp is the bad man. If intel-agp is not loaded, suspend-to-disk works as it should. I also changed the xorg.conf to use nvagp, but I don't think, that this changed anything... To:#18: Do you mean nvidia-agp with Nvagp? I tried to load this module, but it seems not to be used. Unloading agpgart is not possible, as the nvidia module uses agpgart.
You need to reboot to get rid of the intel-agp/agpgart modules, since they need each other (IMHO a bug). Nvagp means that the builtin agp support in the nvidia kernel module is used instead of the kernel agp support. nvidia-agp is for nvidia mainboard chipsets. Use Option "NvAGP" "1" in /etc/X11/xorg.conf to enable builtin agp support by nvidia.
OK. I know now, what nvidia-agp is for :-) The steps you mentioned, I did already yesterday. But without agpgart, the nvidia module does not load!
This might be correct. But it should not need the intel-agp loaded. Add intel-agp to /etc/hotplug/blacklist and reboot for testing.
That's, what I did (see comment #24). If intel-agp is not loaded, the problem with suspend-to-disk is resolved.
Ok. It should be investigated if this is a general problem with the intel-agp module or if this is somewhat related to the nvidia driver. It would help to test this with an Open Source driver. Of course this cannot be done with the nv driver. ATI or Intel chip could be used. Matthias, this would be something for you. :-)
Ok, I'll check that, but with a low priority, as we have a workaround (using NVidia's internal agp module).
Sorry, but ... using NVidia's internal agp module is not the workaround. The workaround (for me) was to blacklist intel-agp. Agpgart is still there.
That's what I'm talking about. agpgart is always loaded. By default, udev also loads the backend driver (intel-agp in your case). If the backend driver is loaded, the nvidia module cannot use its own agp backend. If you blacklist the backend driver, it isn't loaded, and the nvidia module tries to use its own backend.
Does this problem persist with the current NVIDIA driver and/or SUSE 10.1 (Beta8 has been released)?
Unfortunely yes :-( The current matrix (beta8 Nvidia 8178 with patches for 10.1) is: With nVidia Without nVidia Suspend-to-Disk strange X* OK** Suspend-to-RAM strange X OK Standby strange X OK * strange X meens, that the backlight is on, but the display shows _very_ strange colors going from black to white. The machine seems dead, no SSH possible, only reset switch. Vbetool does not help. ** OK means, that it works with vbestate_save and vbestate_restore. Without vbetool the backlight is not switched on, but the machine does respond. Suspend2ram/disk with Nvidia driver works without X: init 3 powersave -U press the lid button for resume -> OK but if I call then init 5 to switch back to X, the machine freezes. Did no special investigations now with logfiles etc, but if you have an idea, where the problem might be, I'm glad to hear about it.
Thanks for status update!
Unfortunately, I don't have any news yet. Just want to comment on the 'strange X issue': In that case the LCD panel isn't driven any longer at all. This state is *very* bad for the LCD, and can damage it if it holds on for a longer time (don't ask me what a longer time is - it certainly survived for me a couple of times for a total of a few minutes). So I wouldn't hestitate to switch the computer off *hard* if this happens to you again.
Any idea, why the X server freezes also when I switch back to runlevel 5 after suspend?
(In reply to comment #37) > Any idea, why the X server freezes also when I switch back to runlevel 5 after > suspend? I guess this happens because the kernel driver thought it had the chip initialized - which it hadn't. Does the freeze still occure with 8756? NVidia told us that they fixed a lot of suspend issues with that release. Though this seems to be a agp driver issue, the graphics driver could still be involved.
Unfortunately there is no change with the new NVidia driver. Let's close this bug, as it seems that I'm the only one with this problem. If someone from Nvidia is interested in more infos, feel free to contact me.