Bug 230528

Summary:	s2ram on compaq presario M2000 laptop
Product:	[openSUSE] openSUSE 10.2	Reporter:	Fatih Alabas <f.alabas>
Component:	X.Org	Assignee:	Forgotten User ZhJd0F0L3x <forgotten_ZhJd0F0L3x>
Status:	RESOLVED DUPLICATE	QA Contact:	E-mail List <qa-bugs>
Severity:	Normal
Priority:	P2 - High	CC:	behlert, eich
Version:	Final
Target Milestone:	---
Hardware:	x86-64
OS:	Other
Whiteboard:
Found By:	Other	Services Priority:
Business Priority:		Blocker:	---
Marketing QA Status:	---	IT Deployment:	---

Description Fatih Alabas 2006-12-22 15:48:14 UTC

I made some intensive test on my laptop that is not in the s2ram whitelist.

Machine ID:
sys_vendor= "Hewlett-Packard"
sys_product= "Presario M2000 (EQ547PA#UUF)"
sys_version= "Rev 1"
bios_version= "F.27"

1) When vga=0, "s2ram -f -a 1" works perfect for both text mode and X mode. When vga is set to a value ( 0x317 for my machine ) only X mode works perfect but text mode resumes on partial blue screen with a cursor blinking at top left. However machine is still alive and reacts to commands I wrote blindly.
2) when vga is set to a value ( 0x317 for my machine ), only "s2ram -f -a 1 -m" works perfect for both text mode and X mode. There is a small thing I ignored; after resume from init=/bin/bash and runlevel 1 the opensuse logo at the top left is not seen, while resume from runlevel 2,3 and virtual consoles within X mode the logo is ok.
3) I tried other options of s2ram for information, but nothing else worked; all the problem seems the video; such as LCD off or LCD on, but blank; ı could still type commands blindly and machine reacted. In addition -s option was dangerous as it crashed my machine.

Now, I set s2ram options in pm-utils config file to "-f -a 1 -m" and using Grub's Vga=0x317, all tests are perfect. I am happy.

Comment 1 Fatih Alabas 2006-12-26 15:54:33 UTC

Further test results and existence of some problems;

1) "-s" option alone ( with "-f" ) or in any combination crashes the machine
2) "-p" option alone ( with "-f" ) or in any combination has no effect
3) "-a 2" option alone ( with "-f" ) or in any combination has no effect, so trying "-a 3" option has no advantage too.
4) "-r" option has no advantage other than bringing screen to on but still blank , instead of screen-off as a result of useless options.
5) if I do not use "-m" option together with "-a 1", then after resume, system works unstable, such as kpowersave shows battery charging permanently, zmd doesn't work or works but some already configured repositories are lost. These are what I could detect.
6) as already seen in my first report; "-f -a 1 -m" seems the best option for both text and X mode. However, even in this combination, there exists one very annoying thing: after resume, display power management starts not working, i.e. screen never goes off.

Comment 2 Fatih Alabas 2006-12-28 19:27:49 UTC

Any idea about non-working display power management after resume ???

my graphics card;
ATI Technologies Inc ATI Radeon XPRESS 200M 5955 (PCIE)

Comment 3 Forgotten User ZhJd0F0L3x 2007-02-01 21:53:39 UTC

not really. It could be something similar than bug 197858

Comment 4 Fatih Alabas 2007-02-05 00:28:43 UTC

Stefan, yes, you are right, my issue is almost same as which was discussed in bug 197858 and I can reproduce the bug as you have already discussed. Only difference is that my case happens after resume-from-ram. 

i.e.
suspend-to-ram
resume-from-ram
exit from kpowersave
rcpowersaved stop
xset dpms force off
by pressing power button or plugging or unplugging AC
then see backlight on but screen blank.

However, bug 197858 has a resolution for openSUSE 10.3, what to do with 10.2 ??

Comment 5 Fatih Alabas 2007-04-13 11:00:09 UTC

People, don't you think a connection between this and bug 197858 ?? I think they are almost the same and there should be an update for 10.2 too.

Comment 6 Forgotten User ZhJd0F0L3x 2007-04-16 14:38:35 UTC

in bug 197858 it actually happened after a VT switch, not specifically after suspend/resume.
However, suspend also does a VT switch, so it triggers this bug.

So yes, this really looks like a duplicate of bug 197858, and you should  be able to use the "option nopm yes" workaround described in https://bugzilla.novell.com/show_bug.cgi?id=197858#c0

*** This bug has been marked as a duplicate of bug 197858 ***

Comment 7 Fatih Alabas 2007-04-17 12:00:29 UTC

Your comment #6 has awaken me. I do not know why I haven't tested for this bug with VT-switch instead of trying with s2ram only until now !! Actually I need to make VT-switch very very rarely. 

Anyway, today I did a test by switching between virtual terminals and yesss, the bug was immediately appeared as reported in bug 197858. So not only after suspend operation but also after VT switch the DPMS does not work.

And, fortunately, the workaround (Option "NoPM" "yes") resolved this issue in my case.

I need to say that; during my search through internet for various suspend problems, I see that there are pretty much people with non-working DPMS after suspend and they mainly think that this is an issue with s2ram, pm-utils or a problem with their ACPI table, so maybe digging within an endless loop. It may be better to resolve this issue with an official update beforehand to help stop exhaustions possibly caused by this xorg issue.

As a conclusion, there is no more problem remaining with s2ram on my machine and can also be whitelisted. 

Thanks for help.

Comment 8 Forgotten User ZhJd0F0L3x 2007-04-17 12:19:27 UTC

Ok, cool. For the s2ram whitelist: did you actually try "s2ram -f -a3"? It _should_ be basically the same as "-f -a1 -m", just a little bit safer.
(if it really does not work, i am glad to add the machine with "-a1 -m" to the whitelist ;-)

Comment 9 Fatih Alabas 2007-04-17 14:58:24 UTC

Yes, I tried "s2ram -f -a3", then after resume, partial blue screen ! 

I certainly need -m option to bring back the screen properly. If -a3 option is safer than -a1, then "s2ram -f -a3 -m" is working too, but I see no difference practically between -f -a3 -m and -f -a1 -m, anyway both works. :-)