looking for hardware reasons why suspend and hibernation don't work
 

My suspend-to-disk and suspend-to-RAM stopped working months ago. I've grasped at straws about why ever since, but I really don't think it's a software problem, because I've reinstalled my system (MEPIS) repeatedly. What sort of hardware failures could cause this? What should I be looking for?

I notice that at boot, Linux always says "no resume image found," even if I left the system in suspension or hibernation. I can post parts of the dmesg if someone tells me what to look for; I can't display the whole thing because it's too long to fit here.

suspend and hibernate are handled with acpi. So look for

dmesg | grep acpi

some laptops need extra kernel options for acpi to work properly
Did suspend/wake fail after an upgrade by chance?

man initramfs-tools :

resume
On install initramfs-tools tries to autodetect the resume parti‐
tion. On success the RESUME variable is written to
/etc/initramfs-tools/conf.d/resume. The boot variable noresume
overrides it

sudo nano /etc/initramfs-tools/conf.d/resume

make sure line:

RESUME=XXXXx-XXX-XXXX-XXXX

points at your swap partition uuid. save and exit, then:

sudo update-initramfs -u

Dmesg | grep acpi says:
I'm using a desktop computer.

It might have been after some piece of software was upgraded that the suspend/wake failed, but I don't think so, because if I reinstall the entire system from my liveCD so that those upgrades are gone, I still can't suspend.

Yeah OK - it is likely that you have a HW (or firmware) issue spoiling suspend.

You do have acpi enabled. Drat - grep is case sensitive...

dmesg | grep -i acpi

... this will provide more messages. I was wondering if perhaps the dsdt went awol:

dmesg | grep -i dsdt

should tell you.

Anyway, you could try flashing your BIOS.
There is a detailed approach for tracking down suspend/resume problems here. Happy hacking ;)

I discovered that the problem seems to be my network adapter. This is how I found out. I wanted to see whether this would happen on another distro, so I installed one (Kubuntu, because I've been looking at it) on another partition, and tried both types of suspend from there. Suspend-to-RAM didn't work there either--the computer shuts down, but can't find any image when rebooting, but something interesting happened when I tried suspending to disk. It did shut down, but for a second, I saw a message to the effect that "rt61" was interfering with the suspend-to-disk. Rt61 is the driver of my wireless network adapter. (It's a Linksys WMP54G.)

Well, this seems a difficult problem. This is my second model of wireless adapter; after the first, a Linksys WUSB54G, broke, I bought a PCI card instead so I would have less cable clutter. I really can't spend money on a different network adapter (perhaps another WUSB54G, since I know it works), so unless someone has a solution for network adapters interfering with suspend/hibernate functionality, I'm probably stuck.

[double-posted by mistake]

you can tell acpi to remove your wireless driver when it suspends - check with lsmod -r rt61 just before doing a suspend. If that works then you can either remember to do this every time or add it to a suspend script.

I have been distracted from this problem, mostly by school, until now. (I was just surviving without hibernation.) When I enter "lsmod -r rt61," the terminal says "usage: lsmod." That's odd--why wouldn't lsmod know that parameter?