[180.08] Screen off after suspend to ram

[nevion]

Nada, the hal fdi's originally have my t61p (prefix with 6459) as needing quirk.none, but even when trying the s3_bios/s3_mode by hand with pm-suspend, nothing happens on resume except an initial lightup of the hd and then hardlock - screen never does anything and ethernet/wifi doesn't come up (I use system managed so it should come on even if x is dead). Additionally, I have to hold down the power button to reset it.

note: I use lshal to make sure the desired settings are set before each suspend trial.

Edit:
I just had a naive thought, what if nvidia isn't reading/replying to this thread cause 180.06 is in the title? Can we get a moderator to rename the thread so it reflects 180.18?

[craftyguy]

I think the having '180.06' in the title has less of an impact on nvidia reading this thread than the 'suspend' in the title...

[perfectska04]

Originally Posted by craftyguy

I think the having '180.06' in the title has less of an impact on nvidia reading this thread than the 'suspend' in the title...

Is there a chance to get someone to change the title to "ALL 180 series drivers released so far"?

[stevenaaus]

I haven't tested this driver yet, but haven't seen mention of using NvAGP.
For me suspend to ram has never worked if i use agpgart. .. Have to set "NvAGP=1" in xorg.conf.
Is this the same for everyone ?

[craftyguy]

Originally Posted by stevenaaus

.. Have to set "NvAGP=1" in xorg.conf.
Is this the same for everyone ?

As of >177.XX drivers, nope, does not make any difference whether I'm using kernel AGP stack or NvAGP..

[perfectska04]

Originally Posted by stevenaaus

I haven't tested this driver yet, but haven't seen mention of using NvAGP.
For me suspend to ram has never worked if i use agpgart. .. Have to set "NvAGP=1" in xorg.conf.
Is this the same for everyone ?

Well, I guess it depends on the card in order to test that. It seems the problem is happening mostly on 8+ series cards and these are usually PCI-Express rather than AGP so I don't know if setting "NvAGP=1" will help.

[elmi]

Hallo

I had the same problem with my DELL Precision M70, Nvidia Quadro FXGo 1400, Gentoo and the "Tuxonice" sources (2.26) installed.
Resuming after suspend worked fine with 177.xx but failed with 180.xx.

After an upgrade to kernel 2.6.28 resuming with tuxonice and nvidia-drivers-180.18 works again perfectly

Cheers Ralf

[Kirurgs]

Have You tried this w/o tuxonice? Can You try it for the rest of us?

P.S. Thanks for sharing info, but .28 kernel for me is no-go at the moment because of fingerprint reader issues

[elmi]

[quote=Kirurgs;1892994]Have You tried this w/o tuxonice? Can You try it for the rest of us?

Only with tuxonice.
Can't see a possibility to do so without it. There is no /proc/acpi/power and echo -n disk > /sys/power/state creates an tuxonice cycle.
Don't want to change my kernel only for a test.

Best for you and maybe some others: Make a try with 2.6.28

Bye Ralf

[NvFuchs]

Kirurgs: those issues have been resolved, try the attached patches (one is for the kernel and should make it into mainline, one is for thinkfinger if you are using it).

As an important information: It just worked here with gentoo 2.6.28 (so no tux on ice, but not vanilla. I have no vanilla at hand) once, but as I am tied to bed due to an illness I can't be arsed to do extended testing. Sorry for that, hope this helps anyway.

Kind regards

Fuchs

[elmi]

Originally Posted by elmi

After an upgrade to kernel 2.6.28 resuming with tuxonice and nvidia-drivers-180.18 works again perfectly

For Gentoo users: 2.6.28-tuxoncice is still missing in the portage tree. So I created my own overlay:
../local/sys-kernel/tuxonice-sources/tuxonice-sources-2.6.28.ebuild

Good luck, Ralf

[bistory]

I think this bug is related to Phoenix BIOS'es, i'm compiling the kernel 2.6.28 to test if it is also fixed to my computer (I saw that a new option appeared on this release that fix a problem to suspend/resume for Phoenix BIOS'es).