System goes back into standby after it resumed

[mike4141]

I got a DELL 5150c Desktop machine (with a 7300GS nvidia card), standby (suspend to ram, is what im refering to in this report) did not work in first instance.. it went fully into standby but when i pressed my powerbutton (i only have 1 button on this case, and thats a powerbutton) it only showed a black background with a mousecursor, nothing happend for the rest, so the system was left unusable.

After reading trough other reports i found out that:
changing the following two properties in /etc/defaults/acpi-support
SAVE_VBE_STATE=false
POST_VIDEO=false

Fixes standby/resume for 99%

Im using kpowersave on this machine, the default event for the 'Power button' is i'Suspend to ram' (S3)

Only problem is, after it resumes from standy (it goes really quickly : ), it goes back into standby again!
when i press the powerbutton once more, it comes again back to the desktop and allows me to continue

So it goes in standby / suspends twice
(standby -> resume(for 3sec) -> standby -> full resume)

Linux mymachine.. 2.6.20-16-generic #2 SMP Thu Jun 7 20:19:32 UTC 2007 i686 GNU/Linux

Dmesg: http://www.pastebin.ca/556197
LSPCI: http://www.pastebin.ca/556201
memtest86: 0 errors

(fyi: im worrying a bit about the "ACPI Exception (acpi_processor-0677): AE_NOT_FOUND, Processor Device is not present" errors as well)

-edit: i see that /etc/acpi/suspend.d/05-acpi-lock.sh is used to drop events between standby and resume, can it be the case that Kpowersave isnt using this well?

[mike4141 (mike4141)]

the powerbutton on my dell system seems to generate 2 events (there's only one press possible, not half / and full or something -> its just 'click')

when i rightclick on Kpowersave and say 'Suspend to RAM' it doesnt go back into standby after resuming.

no solution yet, but im trying to fix it..

[mike4141 (mike4141)]

Another problem is that im not able to access VT's anymore after using standby.

any ideas?

[Bryce Harrington (bryce)]

Are you using the binary nvidia driver? If so, then possibly this is related to bug 104889, esp. since turning off SAVE_VBE_STATE and POST_VIDEO works.

[mlaverdiere (mlaverdiere)]

I think I have the exact same problem here on Kubuntu Feisty, *without any nvidia driver*, and using the 2.6.20-16-generic kernel on a Compaq Presario V2610CA laptop. 50% of the time (average!), the system is going back to suspend state on resume completion and then, resume does not work.

On previous kernels and versions (Dapper & Edgy) suspend was working fine.

I'm trying the "SAVE_VBE_STATE=false + POST_VIDEO=false" fix as described above. Up to now, it seems to work. I'll come back if the problem occurs again.

[mlaverdiere (mlaverdiere)]

Well, finaly, the "SAVE_VBE_STATE=false + POST_VIDEO=false" fix described above doesn't work for me. However, going back to the 2.6.20-15-generic kernel appears to solve the problem.

[mlaverdiere (mlaverdiere)]

After a week of testing, it appears that regressing to 2.6.20-15-generic kernel did help, but the problem still occurs from time to time on my Kubuntu Feisty system.

Using an alternate suspend2 patched kernel (available at: http://3v1n0.tuxfamily.org/dists/feisty/suspend2/index.html) appears to completely fix the problem. It has also fixed this bug: https://bugs.launchpad.net/ubuntu/+source/linux-source-2.6.20/+bug/86820

My experience lead me to believe that Feisty kernels are problematic for suspend/hibernation when compared to Dapper and Edgy ones...

[Hans Bakker (hansmbakker)]

I also have the problem that my laptop keeps going in standby. When i resume, the "screen is locked" window comes up. You can then unlock the screen and you are back Into Feisty, but after a few moments it goes back into standby and this remains until you restart the computer.

I have the 2.6.20-16-generic kernel (Kubuntu Feisty).

lspci http://www.pastebin.ca/601873
dmesg http://www.pastebin.ca/601906

(You can see the ext3 fs tries to recover from the hard shutdown I did when it was in standby as it kept going into standby)

[Bryce Harrington (bryce)]

Since it also occurs with other drivers, I think this is more likely to be a kernel issue. Filing as such.

Can someone please test this on Gutsy to see whether or not the problem is resolved with a 2.6.22-based kernel?

[Launchpad Janitor (janitor)]

[Expired for linux-source-2.6.20 (Ubuntu) because there has been no activity for 60 days.]