Unsolved
This post is more than 5 years old
18 Posts
0
3973
May 4th, 2008 05:00
1420n Suspend/Resume White Screen
Hello All,
I recently bought a 1420n from dell preinstalled with Ubuntu with an nvidia graphics card. It arrived in a very timely fashion, and, so far, all the hardware (including wifi, webcam, mic, lin DVD, card reader) seems to work quite well (with a few short trips to google over the course of a couple hours which, in my opinion, is more than acceptable as a new computer linux experience).
I upgraded from the preinstalled Gutsy to Hardy after a couple hours of playing around. I got suspend/hibernate to work by following the directions here: http://linux.dell.com/wiki/index.php/Ubuntu_7.10/Issues/8400M_Suspend_Hibernate-Failure - The only problem I have left is that, after suspending and resuming, the screen is completely white. When I type my password at this white screen, I am immediately back into my session, and everything seems to work ok. I assume the white screen is supposed to be the typical gnome-screensaver prompt for the user password. Does anyone know how to get this white screen to show up correctly. It isn't really a pressing issue (since suspend/resume still works ok after typing the password), but it makes showing off my new laptop (and how awesome ubuntu is) to my friends less than ideal ;)
For your information, I am using the official 169.12 nvidia-glx-new driver for the restricted drivers in Hardy. In the nvidia 173.08 beta driver release notes, they claim some improved suspend/resume support in some nvidia laptops, but I don't want to install a beta driver to test this. Perhaps someone else knows if the 173.08 (and future drivers) fix this issue? Or is there another fix?
Thanks,
-Jack
PhillyFloyd
175 Posts
0
May 4th, 2008 11:00
Do you know if you are suspending to RAM or suspending to disk there is a little difference in the way PM manages those two events...
I would check /etc/pm/functions-nvidia if one exists, go ahead and move it aside to a different directory, like ~/Desktop and then see if you get the same results after a reboot (you'll need to reload the module, so if you like, an init 1 followed by init 5 would also work ok).
If this doesn't resolve the issue, try adding the line:
ALLOW_NVIDIA_SUSPEND="yes" to the file (/etc/pm/functions-nvidia) and reload the module (reboot or cycle init)
See how that goes
jdeslip
18 Posts
0
May 5th, 2008 01:00
Thanks for the attempt, but there is no difference.
To answer your questions, I was talking about suspend to ram (i.e. "suspend"), but suspend to disk (i.e. "hibernate") has exactly the same issue: the system suspends and resumes, but the screen is completely white where there should be the gnome password-prompt, and, when I type my password, all is good again and I am back to my working gnome session.
I did not have an /etc/pm/functions-nvidia file. I created a new one with the line you provided and rebooted. Suspend/resume still has the white screen issue, however.
PhillyFloyd
175 Posts
0
May 5th, 2008 10:00
OK try this:
ls mod | grep ehci
you prob will see ehci_hcd which is the USB2 enhanced host controller ... issue:
rmmod ehci_hcd
then ensure it is gone by issuing the first command again ...
then try STR (suspend to ram)
FYI --> hibernate is a windows word -- when I hear hibernate I actually thing of JBoss and their query service named - hibernate ;-) Hibernate is more a windows and Ubuntu terminology than with other distros you will hear more often s2ram s2disk
You can also try tuxonice which is a nice alternative to using the built-in kernel suspend
savage.cm
4 Posts
0
May 5th, 2008 22:00
This appears to be a known bug in the nvidia driver that occurs under both fast user switching and resuming from suspend/hibernate. The bug is apparently exposed by compiz and the only seemingly reliable way to avoid it is to disable the advanced desktop effects (under Preferences -> Appearance -> Visual Effects). I have seen quite a few different other "fixes" out there but they don't seem to work for everybody (none of them worked for me) and it is not clear they are fixing the same problem anyways.
Occasionally, the screen will pop up correctly for me without adjusting anything, so don't get your hopes up if it seems to work for you after tinkering around. If you do manage to get it to work several times in a row, then you are on to something (and you can enlighten the rest of us :smileyhappy:).
PhillyFloyd
175 Posts
0
May 6th, 2008 01:00
It is also a known issue the the NVRM spits out XID errors when it remaps the memory for the enhanced host controller interface caus a STR to hang ... the ehci problems however, only occur with suspend (to RAM or Disk)
The problem with COMPIZ and the NVIDIA drivers can easily be resolved by added various NVreg_RegistryDwords and parm: entries for NVreg options or installed a legacy driver ... it is well documented in other forums (the FedoraForums and LQ forum) and is resolved on 2.6.24.5-85 running 169.12 version of the NVIDIA driver on GeForcGo 7xxx and upstream GPUs
Try the ehci work around first ... and also grep'ing for NVRM from /var/log/messages helps isolate the problem
AS AN ASIDE:
Don't get discouraged or siddetracked when you have a problem you are told is a KNOWN BUG ... EVERYTHING can be fixed (granted when dealing with proprietary closed-source drivers it is a little more challenging)... it is just a matter of how much elbow grease and effort you are willing to put into it ... I understand a working laptop is crucial, however, rather than blaming GNU/Linux, NVIDIA, or Ubuntu, perhaps we should be asking Dell why it ships every Ubuntu pre-installed laptop with a vanilla kernel without specific configs to optimize (or even utilize) the hardware on the laptop.
jdeslip
18 Posts
0
May 6th, 2008 03:00
Thanks for the help. The rmmod ehci_hcd did not seem to help.
However, on the compiz forum savage linked to, their was a link to an ubuntu bug report that contains a patch to compiz written by a user. This fixes the issue for me! It seems it is indeed an nvidia bug but it can be worked around (avoided) by applying this patch to compiz.
For future reference, the workaround is here:
https://bugs.launchpad.net/dell/+bug/160264/comments/69