Bug 177955

Same problem here. Worked fine in SuSE 9.2 and not in 10.1.
I tried the following s2ram options after starting with init=/bin/bash (as described in http://en.opensuse.org/S2ram )

s2ram -f           : Video does not work
s2ram -f -a 1      : Computer reboots after resuming
s2ram -f -a 2      : Video does not work
s2ram -f -a 3      : Computer reboots after resuming
s2ram -f -p -s     : Video does not work
s2ram -f -s        : Video does not work... after a while some strange colors appear
s2ram -f -p        : Video does not work
s2ram -f -a 1 -s   : Computer reboots after resuming

Options during boot are vga=0 acpi=on resume=/dev/hda2 desktop

Output of s2ram -n

Machine matched entry 14:
    sys_vendor   = 'Dell Computer Corporation'
    sys_product  = 'Latitude D600 *'
    sys_version  = ''
    bios_version = ''
Fixes: 0x4c  VBE_SAVE VBE_POST NOFB
This machine can be identified by:
    sys_vendor   = "Dell Computer Corporation"
    sys_product  = "Latitude D600                   "
    sys_version  = ""
    bios_version = "A15"
See /usr/src/linux/Doc*/power/video.txt for details,
then reimplement neccessary steps here and mail patch to
pavel@suse.cz. Good luck!

If you report a problem, please include the complete output above.

Pavel, you might want to look into this.

Actually, this is enhancement: we do not support s2ram.

why it fails is another question... Try to find out which difference between 10.0 and 10.1 matters here. Is it kernel? Or difference between userspace scripts?

...uh, but we have it in the whitelist, so it should work. It definitely worked for someone at some point... What is different?

It's in whitelist and it worked, so it's obviously a bug.
I suppose it's kernel, but you could find the differences
much better.

Feel free to come and have a look. You could also have D800, but I don't
know if it works on it or not.

Tested with sles10 kotd 2.6.16.18-20060603092915-default, same behavior.

However, the system seems to be to some extent alive, as power down with [Power] button works. Maybe a video driver issue?

Does power button work even in SuSE 10.1? If so, I guess we can change the summary to "video does not work after resume from suspend to RAM".

(I assume suspend-to-disk works okay?)

Next step would probably trying suse10 scripts -- calling vbetool manually before and after suspend to ram. There's some docs in /usr/src/linux/Doc*/power/video.txt.

The power button works in 10.1, I have no other distro installed on that notebook. I'm not sure if the keyboard works too, would have to check.

Suspend to disk works OK.

Blindly typing "find /" (then looking at hdd light :-) is accepted way to test keyboard.

Can you do the vbetool test?

Well, not sure if there's not a screen saver ;-)

I could try the vbetest, just let me know what exactly to do.

(6) other radeon systems, where vbetool is enough to bring system back
  to life. It needs text console to be working. Do vbetool vbestate
  save > /tmp/delme; echo 3 > /proc/acpi/sleep; vbetool post; vbetool
  vbestate restore < /tmp/delme; setfont <whatever>, and your video
  should work.

...text mode console, in mode without X, preferably.

Seems it works, after running that script (in runlevel 3), the screen is in text mode again and up to some minor mess it works. There is this message shown on the screen (in case it matters):

  Allocated buffer at 0x11010 (base is 0x0)
  ES: 0x1101 EBX: 0x0000

I tried running X once and the computer froze hard.

Okay, so trying vesafb and unaccelerated X server is the next step. If that helps, we have X problem...

the last time i had a D600 in my hands, it only worked with vga=0 :-( but it might still be worth a try.

I had some time to do some tests. vga=0 option is used.

1. vbetool in runlevel 3 : Works fine!
2. vbetool in runlevel 5, but after rckdm stop : Works fine!
3. vbetool on the console, with ati driver in xorg.conf (without dri module) : Works fine!
4. vbetool in kde, with ati driver in xorg.conf (without dri module) : Executing the scripts does wake up the screen, but strange horizontal black lines are on the screen. After switching to another virtual desktop, the lines disappear. Doing suspend to ram using kpowesave does not wake up the screen. 

Tomorrow, I can test the same things, after enabling the dri module and with the radeon and radeonold drivers, if this is needed.

Is the above information enough to find a solution or is more information needed? If the information is fine, what is the change to have a solution? If not, can you tell me which information is still needed?

I have reproduced this on a machine here with some "interesting" results:
- s2ram -f -p does not work.
- "echo mem > /sys/power/state; vbetool post" does work. sometimes.
- before suspend, vbetool post does nothing else then clearing the screen
- after resume, first vbetool post does turn on the light, second vbetool post turns off the light and it never turns on again.

These are some strange and nasty problems, maybe related to timing and something being a bit broken after resume and i have no solution yet.

Maybe slightly off-topic :

I installed the fglrx driver (version 8.27.10) today.
Suspend to ram works fine with the following simple script :

#/bin/bash
chvt 1
rmmod ehci-hcd
rmmod uhci-hcd
echo 3 > /proc/acpi/sleep
modprobe uhci-hcd
modprobe ehci-hcd
chvt 7

I'm still trying to figure out how to make it work with kpowersave and the suspend button. Hints are welcome ;-)

The script is even easier :

#/bin/bash
chvt 1
echo 3 > /proc/acpi/sleep
chvt 7

Suspend to ram works with the fglrx driver, after deinstalling the suspend package and setting the SUSPEND2RAM_FORCE parameter in /etc/sysconfig/powersave/sleep to "yes". 

Wim: does that script work for you _reliably_? I.e. in config where it works, can you do 20 cycles?

I didn't test it 20 times, but I could use suspend to ram a whole weekend (let's say at least 5 cycles). I'm using version 8.27.10 of the fglrx ati driver.

The network card is not longer recognized after suspend to ram. Wireless does work perfectly. After a 

rcnetwork restart

everything is fine again.

What's the status here?

I have no hardware and even if i had, i probably could not fix it.
This bug needs to be assigned to someone who has a hardware debugger or something similar to debug the machine while still in the BIOS.

As Seife says it's not possible to fix, I'll close this.