Bug 113064

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.