Opened defect 210307 at bugzilla.novell.com. Adding comments now to answer your questions.
Regards, Dave ------------------- This message comes to you from a desktop that is 100% free of Microsoft Windows. David Dulong Sr. Technical Team Manager. [EMAIL PROTECTED] 336.324.7249 Novell, Inc. Software for the Open Enterprise http://www.novell.com/open >>> Stefan Seyfried <[EMAIL PROTECTED]> 10/05/06 1:02 PM >>> On Wed, Oct 04, 2006 at 08:10:56AM -0600, David Dulong wrote: > On the opensuse site, I saw that you wanted us to post what worked and > what didn't work to this e-mail distribution list so here you go... > > I went through the processes recommended on > http://en.opensuse.org/S2ram and here is what I found on my SLED10 > machine (2.6.16.21-0.15-default): > > 1) The output of s2ram -n: > [EMAIL PROTECTED]:~> sudo /usr/sbin/s2ram -n > Machine matched entry 21: > sys_vendor = 'Dell Inc.' > sys_product = 'Latitude D610 *' > sys_version = '' > bios_version = '' > Fixes: 0x4c VBE_SAVE VBE_POST NOFB > This machine can be identified by: > sys_vendor = "Dell Inc." > sys_product = "Latitude D610 " > sys_version = "" > bios_version = "A06" > See http://en.opensuse.org/S2ram for details. > > 2) Doing a minimal boot (init=/bin/bash and mounting /proc and /sys) - > the suspend command: "s2ram -f -p -s" worked for me time and time again > after turning off the framebuffers (vga=0). > > 3) Rebooted machine and booted into GNOME. The framebuffers were off > (vga=0) > > 4) Opened terminal window executed "sudo /usr/sbin/s2ram -f -p -s" > > 5) The machine suspended just fine and recovered just fine. > > 6) Re-ran the command from #4 above, this time the screen filled with > a Y's with what looked like 2 dots over it (not 100% sure if that's what > it was) and continuously flashed on the screen. This is normal. Since the contents of the VGA console are stored inside the graphics card memory, which is not preserved during suspend to RAM, you basically get random garbage in the console after resume. You just did not see it since the machine switched back to X almost immediately. > It sat here until a > hard power-off was performed. This, however, should not happen :-) Did the machine actually suspend a second time and hang this way after (trying to) resume or did it hang already before it suspended the second time? What graphics card does this machine have (lspci|grep VGA)? What driver (for X) are you using? Can you switch to console 1 after the first resume or does this also hang the machine? > I attached my sleep config file which was also edited based on the > "working" s2ram switches: > SUSPEND2RAM_FORCE="yes" > SUSPEND2RAM_VBE_SAVE="yes" > SUSPEND2RAM_VBE_POST="yes" this should not be needed, since s2ram already knows your machine (see the line "Fixes: 0x4c VBE_SAVE VBE_POST NOFB" above. > What else can I provide for you? I'm no linux guru so if you need the > output of some commands, just tell me what commands to run and I'll be > glad to do it. does it work better if you use powersaved to suspend? "powersave -u" (can be run as regular user) should suspend to RAM. This does additional stuff like unloading known problematic modules etc. which might be responsible for the machine locking up. > I'll be happy to open a bugzilla on this if you like. This is probably a good idea, if only to get this documented. -- Stefan Seyfried QA / R&D Team Mobile Devices | "Any ideas, John?" SUSE LINUX Products GmbH, Nürnberg | "Well, surrounding them's out." ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ Suspend-devel mailing list Suspend-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/suspend-devel
