No wakeup after suspend-to-ram

It seems that I have seen this problem before in the last month or so and that the problem was solved, I'm not sure, but have you tried a forum search?

regards,
Bad Dog
SimplyMEPIS 6.0 - kernel 2.6.15-26-686-SMP - KDE 3.5.3

Bad dog,

I searched the forum, and found that my problem was most similar to this problem:

http://www.mepis.org/node/9445

But no one seemed to have an answer to it.

I have tried all the video refresh utilities: switch_vt, (called from /etc/powersave/events) vbe_post (called from /etc/powersave/sleep), and the video_post tool. These are the usual fixes that are recommended in forums. It makes me think that something is causing the computer to hang on it's way back up from suspend-to-ram. It is completely unresponsive when I wake it back up. The same thing happens on suspend-to-disk.

Any ideas?

Here's the post: www.mepis.org/node/10679 , from this search: www.google.com/search?hl=en&q=mepis+%22suspend+to+ram%22&btnG=Google+Search

regards,
Bad Dog
SimplyMEPIS 6.0 - kernel 2.6.15-26-686-SMP - KDE 3.5.3

Ok, perhaps I have not had very good manners on this forum. The situation is this: After making the post that I did before, (node 10679) my problem changed. I'm not sure what I did to make it change, but I could no longer resume after a suspend-to-ram. It is not just a video post issue, either. Should I have resumed the thread www.mepis.org/node/10679 with an update of my problem? I guess I felt that the responses I got sort of changed the subject of the thread to a discussion of suspend to disk vs. suspend to ram, and scripting the lidbutton on my laptop.

This new problem is very distinct: Neither suspend-to-ram nor suspend-to-disk will resume fully anymore, even with teh video post scripts and tools.

My hunch is that it is a module (or a few modules) that do not cooperate with powersave's suspend-to-ram. I have seen some vague solutions on multiple forums saying that certain modules will cause problems with suspend to ram and should be unloaded before suspend happens. I haven't yet found a list of which modules need to be unloaded. Below is the result of lsmod on my machine.

Sorry if I'm out of line with my posts. I'm still learning forum etiquitte. Thanks for the time, Bad Dog.

sorry about the line breaks. couldn't figure out how to get rid of them.

<br />
$lsmod</p>
<p>Module                  Size  Used by<br />
i915                   18432  1<br />
drm                    66196  2 i915<br />
binfmt_misc            11144  1<br />
ppdev                   8452  0<br />
capifs                  5896  1<br />
video                  16260  0<br />
thermal                13576  0<br />
tc1100_wmi              6916  0<br />
sony_acpi               5644  0<br />
pcc_acpi               12416  0<br />
hotkey                 11556  0<br />
fan                     4868  0<br />
dev_acpi               11140  0<br />
container               4608  0<br />
button                  6672  0<br />
acpi_sbs               19980  0<br />
battery                 9988  1 acpi_sbs<br />
i2c_acpi_ec             5120  1 acpi_sbs<br />
i2c_core               19984  1 i2c_acpi_ec<br />
ac                      5252  1 acpi_sbs<br />
ipt_limit               2432  2<br />
ipt_state               2048  66<br />
ipt_LOG                 6016  2<br />
ipt_REJECT              5248  2<br />
ip_conntrack_ftp        7280  0<br />
ip_conntrack_irc        6640  0<br />
ip_conntrack           47148  3 ipt_state,ip_conntrack_ftp,ip_conntrack_irc<br />
nfnetlink               6296  1 ip_conntrack<br />
ndiswrapper           156628  0<br />
cpufreq_userspace       4440  0<br />
cpufreq_powersave       1920  0<br />
cpufreq_ondemand        6172  0<br />
speedstep_lib           4228  0<br />
speedstep_centrino      7888  1<br />
freq_table              4484  1 speedstep_centrino<br />
processor              23360  2 thermal,speedstep_centrino<br />
dm_mod                 52152  0<br />
md_mod                 64084  0<br />
af_packet              21000  6<br />
pcmcia                 36668  0<br />
yenta_socket           25740  2<br />
rsrc_nonstatic         12288  1 yenta_socket<br />
pcmcia_core            38672  3 pcmcia,yenta_socket,rsrc_nonstatic<br />
ipw2200                98476  0<br />
ieee80211              32328  1 ipw2200<br />
ieee80211_crypt         6016  1 ieee80211<br />
b44                    23180  0<br />
ieee80211_1_1_13       33608  0<br />
ieee80211_1_1_13_crypt     6528  1 ieee80211_1_1_13<br />
mii                     5376  1 b44<br />
ohci1394               31156  0<br />
bcm4400                36940  0<br />
hw_random               5396  0<br />
parport_pc             32708  0<br />
lp                     10820  0<br />
parport                32968  3 ppdev,parport_pc,lp<br />
joydev                  9152  0<br />
usbhid                 33888  0<br />
shpchp                 40384  0<br />
pci_hotplug            26164  1 shpchp<br />
snd_intel8x0           30620  1<br />
snd_intel8x0m          16268  6<br />
snd_ac97_codec         83360  2 snd_intel8x0,snd_intel8x0m<br />
snd_ac97_bus            2304  1 snd_ac97_codec<br />
psmouse                32772  0<br />
snd_pcm_oss            46368  0<br />
snd_mixer_oss          16896  1 snd_pcm_oss<br />
snd_pcm                79880  6 snd_intel8x0,snd_intel8x0m,snd_ac97_codec,snd_pcm_oss<br />
snd_timer              22660  1 snd_pcm<br />
snd                    50276  19 snd_intel8x0,snd_intel8x0m,snd_ac97_codec,snd_pcm_oss,snd_mixer_oss,snd_pcm,snd_timer<br />
soundcore               9568  1 snd<br />
snd_page_alloc         10248  3 snd_intel8x0,snd_intel8x0m,snd_pcm<br />
serio_raw               6916  0<br />
rtc                    12468  0<br />
sworks_agp              8864  0<br />
amd_k7_agp              8204  0<br />
ali_agp                 6656  0<br />
sis_agp                 8452  0<br />
ati_agp                 8332  0<br />
nvidia_agp              7964  0<br />
via_agp                 9600  0<br />
intel_agp              21276  1<br />
agpgart                31816  10 drm,sworks_agp,amd_k7_agp,ali_agp,sis_agp,ati_agp,nvidia_agp,via_agp,intel_agp<br />
uhci_hcd               29328  0<br />
evdev                   9088  1<br />

So, here it is. After hours of fruitless searching on the web about which modules are incompatible with acpi, I decided to find out for myself. The whole process took about an hour and a half, so if you really want your computer to suspend, just crank it out. Just as a note, I am running mepis 6.0 with acpid and kpowersave. Here is the algorithm I used to determine conflicting modules:

1. Make sure you have a button that you can use to put your computer to sleep (can be a hotkey, sleep button, etc. I just used my laptop's lidbutton, which I have a rule for in /etc/powersave/events for it to "suspend to ram" on lid close). The reason you need a button is because you are going to be telling your computer to sleep about 50 times and you'll get tired of doing it manually (with a terminal command or otherwise)

2. In a terminal, type lsmod to get a list of currently loaded modules.

3. Strip the extra data (mem size, used by, etc.) because all we want is a list of names of modules. I pasted the whole thing into a spreadsheet and told it to divide columns separated by spaces.

4. Paste the whole column of just names into /etc/powersave/sleep where it says: UNLOAD_MODULES_BEFORE_SUSPEND2RAM=""
(in between the parentheses) and then save the document.

5. Certain modules will not unload when you tell the computer to suspend2ram. Therefore, you have to eliminate all of those from your list. To do this, push the sleep button. It will start unloading modules from the beginning of your list. If it gets to a module that won't unload, it will give an error and tell you which module wouln't unload. So remove that from your list in UNLOAD_MODULES_BEFORE_SUSPEND2RAM=""
Make sure to save the document before trying to suspend again.

6. Repeat step 5 until the computer successfully sleeps. Then you know that all the modules in your list were successfully unloaded. Now, when you tell your box to wake up, it *should* wake up fully with no problems. If it doesn't, then I don't know what your problem is.

7. Copy and paste your list of modules that successfully unload into a separate text file for reference.

8. Then, remove one half of your list and tell your machine to sleep. If your machine successfully wakes still, you know the faulty module is one that you didn't delete. If not, repaste that half back in and delete the other half.

9. Repeat step 8 until you have found the faulty module (or modules). This could probably be written into a script, but I don't know much about script writing, so I'll leave it to someone else. That would be a huge savior to a ton of people on forums who seem to be having problems with incompatible modules keeping their machine from suspending.

For me, the culprit module was "bcm4400" so if your lsmod reveals that, try just unloading that one first.

Hope that helps a lot of folks out. I was pretty kicked to get my supend-to-ram working.

Vergil

I recently upgraded to Mepis 6.0 on my ThinkPad T-42. Wakeup after suspend-to-ram resulted in no video. I ended up here in digging around for a solution. Here is what worked for me:

add: acpi_sleep=s3_bios resume=/dev/hda2

(assuming your linux swap ptn is /dev/hda2)

to /boot/grub/menu.lst. run grub-install. voila. suspend to ram and to disk work fine with an off-the-cd mepis 6.0 install.