180.22 works well on my Lenovo T61 with nvidia NVS140M

[pauljohn]

There's so much doom and gloom in this group, I'd just like to say that I have a very good experience with the new nvidia driver. I'm running Ubuntu 8.10 and I built debian packages from the deb src files I found on the ubuntu repository server. (Apparently, they are not yet ready to offer the deb files, but they are easy to build for yourself if you take the files from this directory:
http://us.archive.ubuntu.com/ubuntu/...s-drivers-180/
)

I would make those deb packages available to you if I were not afraid of being sued by Nvidia. Really, it is easy to build them yourself.

This new driver solves the problems I was having with poor screen refresh in terminals, in image viewers like GQview, and in Firefox. I've not seen that broken-up screen malfunction a single time since installing the new driver.

Happy new year

PJ

Further, I have suspended and resumed 5 times without observing the "screen stays black" trouble. I used to have that problem on Dell PCs, but that was due to weaknesses in the Fedora Linux configuration.

[nevion]

Why did you go off and create another thread? The discussion will just spill off into this thread now.

do the following:

lshal|grep power_management

and post the output.

Also do nvidia-bug-report.sh and post the reslts so we can get the complete relevant details of your setup (specifically your xorg and kernel versions).

Finally, what method of suspend have you used to suspend. Have you waited a few minutes before trying to resume? I was able to resume a few times back to back before but not if I waited a few minutes.

[ledoc]

Yes, more specs please.

Also, the nvidia debian packager was fast and has uploaded 180.22 to experimental already.
http://packages.qa.debian.org/n/nvid...0T224707Z.html

[kvaster]

As for me I have two problems with my Lenovo thinkad R61:
1) 30 seconds hang when restarting X without restarting system.
2) Terminal corruption with compiz - driver transfers image to the screen before it is updated.

[pauljohn]

Originally Posted by nevion

do the following:

lshal|grep power_management

and post the output.

$ lshal|grep power_management
  power_management.acpi.linux.version = '20080609'  (string)
  power_management.can_hibernate = true  (bool)
  power_management.can_suspend = true  (bool)
  power_management.can_suspend_hybrid = false  (bool)
  power_management.is_powersave_set = false  (bool)
  power_management.quirk.vbe_post = true  (bool)
  power_management.type = 'acpi'  (string)

Also do nvidia-bug-report.sh and post the reslts so we can get the complete relevant details of your setup (specifically your xorg and kernel versions).

Finally, what method of suspend have you used to suspend. Have you waited a few minutes before trying to resume? I was able to resume a few times back to back before but not if I waited a few minutes.

I've suspended for 12 hours and it wakes up perfectly. I'm using Gnome, and I've had success with suspend from the gnome-power-manager as well as the System/Shut Down menu. I don't do the suspend-to-disk (hibernate), don't see any value in using that.

I'm attaching the nvidia-bug-report.log file

pj

[nevion]

You didn't attach the nvidia-bug-report.log file. Perhaps you need to bzip2 it first (forum doesn't attach files over certain size).

Edit:
Well, I adjusted my hal settings so they matched yours, same old hardlock. It's not screens simply going black as you mentioned earlier, the machines hardlock after a burst of io from resume (from ram). Perhaps the missing piece of the puzzle is in your log file but I have to ask, are you sure you're not using the nv driver? :-)

[pauljohn]

Originally Posted by nevion

You didn't attach the nvidia-bug-report.log file. Perhaps you need to bzip2 it first (forum doesn't attach files over certain size).

Edit:
Well, I adjusted my hal settings so they matched yours, same old hardlock. It's not screens simply going black as you mentioned earlier, the machines hardlock after a burst of io from resume (from ram). Perhaps the missing piece of the puzzle is in your log file but I have to ask, are you sure you're not using the nv driver? :-)

I am absolutely sure I'm using "nvidia" because I can run nvidia-settings and mess around with the display.

I did attach the log before, I promise. I've gzipped it and am trying again.

About 6 weeks ago, I had seen that hard lock problem you describe, but don't see it now. I believed at the time it only happened when I touched the keyboard before everything on the system was fully awake. I read somewhere about a race condition that could be caused by premature keyboard access in wakeup.

pj

[nevion]

I don't think this is the bug you are imagining.

I duplicated your setup to every last option in the log. I found that I could get things to suspend with gnome and s2ram --force/pm-suspend. Using vde_post as the hal files do made things work also but made the console shot after resume, at least for me. Seems like quirk.none is the way to go after all.

But while suspend works with gnome, it doesn't with kde4 and possibly other environments. Who knows what userspace kde is doing that could trip up the nvidia driver but this is still a suspend bug from nvidia. Things (wrt to suspend/resume) work fine with 177 in seemingly all environments.

I'd be interested in you trying out kde4 on your laptop if you're not already (4.2 beta 2 or rc1 would be best) and to hear your results. The newer kde4's installation details for ubuntu are here and here. I will try with 4.1.3 soon (I use 4.2 rc1 atm).

[NCleopatra]

Originally Posted by kvaster

As for me I have two problems with my Lenovo thinkad R61:
1) 30 seconds hang when restarting X without restarting system.
2) Terminal corruption with compiz - driver transfers image to the screen before it is updated.

the 30 seconds problem ..... so so boring
probably it will be resolved in the next next stable version..