Go Back   nV News Forums > Linux Support Forums > NVIDIA Linux

Newegg Daily Deals

Thread Tools
Old 02-01-06, 01:11 PM   #1
Registered User
Join Date: Jan 2006
Posts: 8
Default Resume from Suspend-to-RAM

I have read several posts on this issue now and tried several driver versions from 6113 to 8178 (with latest update) and kernel versions (well, not every combination of these I guess) and nothing seems to help :

I CAN do suspend-to-RAM (ACPI S3) just fine - IF the X server is not running with the nvidia binary drivers enabled (Xorg NV driver works). Disabling AGPFW or AGPSBA, using NvAGP=1 (which I always do), setting X to the same resolution as the framebuffer (I'm using VESAFB with VGA=791), acpi_suspend=s3_bios, everything else suggested so far - DOESN'T HELP, the graphics card doesn't seem to reinitialize when I suspend while X is running and then resume - screen's blank (also when in FB with X active).

The rest of the system seems to be working OK, even though I don't see anything (restoring with vbetool doesn't help). Once I kill X and restart it (or it's being restarted by XDM) after suspend, though, the drivers DO reinitialize and everythings working again. Now, having to restart X all the time makes suspend quasi useless. If I return to X from FB after resume, while the screen is dark, the system hangs (although SysRq still works, but nothing else).

So, what exactly happens with the card when I start X? Can you do the same thing that brings the display 'back to life' WITHOUT restarting X?

Please, I desperately want this to work, I'd really appreciate it if you (the nVidia devs) found a solution to that. I'll post an nvidia-bug-report and dmesg ouput now, maybe you find something, although I don't think the dmesg stuff will be of much use ...

e7af7f85dad902edbfa06e80d7c7b9f3 nvidia-bug-report.gz.log
f0b29b9767949bf134702c44d4d24ee1 dmesg.gz.log - dmesg output after suspend & restart X

(gzipped, were too large for upload, I put the gz before the .log because I couldn't upload with .gz ending)

Attached Files
File Type: log nvidia-bug-report.gz.log (28.1 KB, 123 views)
File Type: log dmesg.gz.log (13.2 KB, 123 views)

Last edited by Calim; 02-01-06 at 01:28 PM.
Calim is offline   Reply With Quote
Old 04-06-06, 08:18 PM   #2
Registered User
Join Date: Apr 2006
Posts: 1
Default Re: Resume from Suspend-to-RAM


I had a hard time figuring this out, but it seems that the agpgart module was causing the problem on my machine. I had to recompile a kernel without it, stock debian kernel has it so it was loaded (even with NvAGP=1). I am using the vesafb framebuffer, vga=792, the consoles are still garbled after hibernate.

tkpapp is offline   Reply With Quote
Old 04-07-06, 08:57 AM   #3
Registered User
Join Date: Jun 2004
Posts: 4
Default Re: Resume from Suspend-to-RAM


Try this. In the file /etc/pm/functions-nvidia, comment out the one line which says "/usr/sbin/vbetool post" so it looks like this:

# /usr/sbin/vbetool post
/usr/sbin/vbetool dpms on
/usr/sbin/vbetool vbestate restore < /var/run/vbestate
) >/dev/null 2>&1

This works fine for me and allows the video to resume normally after either a manual or automatic suspend. The only side effect is some corruption of the framebuffer, which you will only see momentarily when you logoff, shutdown or restart. It seems to be harmless.
sarah is offline   Reply With Quote
Old 04-07-06, 10:19 AM   #4
Registered User
Join Date: May 2003
Location: Sunnyvale, CA
Posts: 116
Default Re: Resume from Suspend-to-RAM

You can't use vesafb with acpi suspend/resume. In fact, even the text mode console isn't so great, but at least the vbetool trick works.

On my laptop, using the text console, the console will become garbled when ever you switch to it from X after a resume. I have a hotkey set up that runs vbetool so I can fix it when I need to. If you unload and reload the nvidia driver after the resume, it will fix things (and also fix the loss of performance problem).
philipl is offline   Reply With Quote
Old 04-10-06, 11:47 AM   #5
Registered User
Join Date: Jan 2006
Posts: 8
Default Re: Resume from Suspend-to-RAM

Thanks for the replies !
I noticed the following on my laptop (HP Pavilion zd7000) (driver version 8756):
- When I switch to the console when suspending, the display only comes back when I use vbetool post (backlight comes back) and vbetool vbestate restore (console visible again, but garbled - when I switch terminals once, it's normal again (using vesafb-tng))
- BUT with vbetool post on switching back to X, it hangs, even without suspending - so vbetool post is obviously bad (here reboot is still possible via Ctrl-Alt-Del). I checked dmesg, and noticed nothing out of the ordinary (I instructed the machine to write dmesg to disk every few seconds - my logger doesn't work properly and I can't switch back to terminal after switching to X after suspend, but the programa ran anyway)
When I stay in X, the backlight comes back on without vbetool post, but the machine hangs after a few seconds, and the screen also stays blank.

Suspend-to-Disk works fine, though (although the console is black until I switch to X and back) ...
Now ... could the driver please not-crash when resuming in X?

EDIT: the xorg nv driver also needs the post to work again, but unlike the nvidia driver, it doesn't crash. And I have to switch to the console ... Maybe it isn't the nvidia driver after all ...

Last edited by Calim; 04-10-06 at 11:57 AM.
Calim is offline   Reply With Quote

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Forum Jump

Similar Threads
Thread Thread Starter Forum Replies Last Post
302.07 no resume from suspend stecklum NVIDIA Linux 85 12-07-12 01:27 PM
Computex: ASUS Mars III Dual GTX 680 Card Comes With 8GB RAM News Archived News Items 0 06-05-12 01:40 PM
NVS3100 (Thinkpad T410) blank screen on resume NvFuchs NVIDIA Linux 2 05-15-12 01:02 PM
[Bug Report] Xid error after resume with 307.02, and compiz stops working. John K. NVIDIA Linux 0 05-09-12 02:42 PM
Program to Identify DDR RAM modules speeds MUYA General Hardware 4 10-11-02 11:41 AM

All times are GMT -5. The time now is 09:03 PM.

Powered by vBulletin® Version 3.7.1
Copyright ©2000 - 2015, Jelsoft Enterprises Ltd.
Copyright 1998 - 2014, nV News.