I have a problem with my laptop where suspending to ram seems to work, but the system won't recover properly afterwards. (It'll go to sleep, it just won't wake up!) I can put it to sleep with the ACPI lid event, Gnome's power manager, or just "echo -n mem > /sys/power/state", and it looks like it works fine.

When I try to bring it back by pressing the power or function button, the power light comes on and the fan revs, but nothing else responds and the screen stays blank. Nothing in the logs looks like it ever really wakes up. This is on gentoo with kernel 2.6.25 (and tried on 2.6.27), and on an Acer Aspire 5100-3372 laptop. Everything else with power and ACPI seems to work fine. Any tips on where to start looking?

Attached Files

kernel-conf.txt (46.8 KB, 8 views)

I remember there's some procedure somewhere in the web telling you what to do in (not uncommon) cases like this.
What I usually do to try to understand what happens:
1) try to go to runlevel 3 (no GUI) and try to suspend
2) play with the various options of your suspend tools - on opensuse for instance, you can make use of the s2ram/s2disk utilities, that have options like --vbe_save --vbe_post --vbe_mode --pci_save to try to be a bit more robust
3) try to remove as many external devices as you can, and as many modules as you can. I saw that some distribution tries to remove troublesome modules before trying to suspend. In my case, for instance, I have problems with my wifi usb device (rtl8187), removing its kernel module is enough to allow me to suspend and resume

Hope this helps!

Ah, thanks! I've narrowed it down a bit (not a module problem, or an issue with X), and using s2ram lets me resume almost correctly. The only problem left is that the screen is garbled when it starts up again, and only fixes itself if I start X (haven't tried it while running an X server yet). This is definitely progress, though.

s2ram says the Aspire 5100 is recognized as "entry 17", so I'm hopeful; I'll try fiddling with the different options. The other thing that comes to mind is that I'm using the framebuffer; could that be causing trouble?

I don't think that the framebuffer could cause problems more than using another video driver... anyway I would suggest changing it as using the card's specific module usually leads to superior performance.

The card's specific module for the framebuffer? (I can do that?) I'm using ATI's fglrx module for X, but maybe I don't have a firm grasp of what's going on for the console. I think I'll try a kernel without any of that just to see what happens, and then go from there. Thanks for the advice.

You're right, it's not a framebuffer issue (and it turns out I've been using the radeonfb driver, compiled in, without even realizing it). I'm not getting any success with the different s2ram options... any other ideas?

If you tried all the options --vbe_save --vbe_post --vbe_mode --pci_save I don't know what else you could try...
yes you could try using the VESA video driver, just to see if something changes, or using the non-proprietary "radeon" module, that usually leads to good performance but less than the proprietary one, as of my experience.
Last, updating (more or less in order of importance) xorg, the driver itself, and the kernel could lead to some improvement... I hope there's someone else that can report his own experience

Well, I haven't had any luck without X (or any extra video drivers at all), and I'm on the most recent kernel provided by Gentoo's package manager (2.6.27.8), so I'm a bit stuck. But, after fiddling with the kernel options, it looks like suspend-to-disk actually works just fine, so I think for the moment I'll just set up ACPI to do that in some of the events instead of going to ram. I guess it's a fair bit slower, but at least it works properly. I consider it a success, in any case. Anyway, thanks a lot for your help!