If you want to give advice on fixing the problem, that's great
But I'm actually more interested in learning how to debug suspend issues... I'm stumped even at that point... It seems to me there are no logs, and looking at the pm scripts, it really doesn't seem there's a good place to actually log a resume process, esp when resuming from RAM.
My DuoT2400/i945GM Dell e1405 has trouble resuming from suspend (for which I am more concerned) and hiberante, I think for different reasons.
Resuming from suspend seems to be tricky business, and the odds of a good resume are worse when using an SMP kernel - I'm not sure why as I've been reading up and apparently the hotplug CPU issue is old and resolved. The worst bootup scenario is no activity at all; it might look like just a blacked out screen, but there's no disk, no nuthin, no nada. Climbing upwards from there is the resumed system with the black screne - this, I've conquered. So usually, I get either a really dead resume or I get a really screwed up resumed system. The screwiness is that the filesystems appear horribly damaged. ls -l gives lots of ?'s, various programs only want to report I/O errors, etc. I think this might be a SATA issue. I have found these problems with 2.6.15, .16, & .17, uni or SMP versions. However, after I editing the /etc/pm/functions-intel script to not run the vbestate restore command, using .15no-smp resume is usually successful.
Resume from hibernate never works. My swap is on /dev/sda5 and its label is SWAP=sda5. I did all this by hand. Swap space works perfecetly with /etc/fstab having LABEL=SWAP-sda5. I have also put resume=LABEL=SWAP-sda5 on all my kernels' option lists in grub.conf. However, on any boot, booting reports that it cannot find my swap device, correctly listing the resume option's value... well, sort of. Say I have
Boot will complain, "(Cannot find resume device LABEL=swap-sda5
Note the LF! Yes it really gets printed before the closing paren. Now, say I have this:
Boot will complain, "(Cannot find resume device resume=LABEL=swap-sda5 some_option=some_value
Again with the LF! Oy! And what's with the trailing options> Sounds like a kernel option parsing problem to me... am I not specifying this correctly? Or, at best, its just a printing problem.
Well, that's where I am so far.