On 1/3/12, Javier Vasquez <j.e.vasquez.v@gmail.com> wrote:
On 1/3/12, C Anthony Risinger <anthony@xtfx.me> wrote:
On Tue, Jan 3, 2012 at 2:46 PM, Jonathan Vasquez <jvasquez1011@gmail.com> wrote:
On Tue, Jan 3, 2012 at 3:43 PM, Alex Ferrando <alferpal@gmail.com> wrote:
On 03/01/12 21:25, Javier Vasquez wrote:
% 'grep' resume /etc/mkinitcpio.conf HOOKS="base udev autodetect pata scsi sata usb filesystems keymap usbinput resume"
Last time I checked (2 secs ago) resume hook should go before filesystems.
I have this but my comp as I said before doesn't even get to suspend in the first place since it gets stuck at the black screen just before suspending:
HOOKS="base udev scsi sata lvm2 resume filesystems usbinput"
is there a reason to not use the `autodetect` hook?
it's not clear to me that everyone in this thread is talking about suspend-to-disk, ie. `hibernation` ... the OP i believe was referring to suspend-to-RAM, though perhaps i am mistaken ... AFAIK the term "suspend" is generally used for the RAM variant.
`resume` hook is for hibernation only. it should run immediately after the swap partition holding the frozen image becomes available. whatever drivers/hooks needed to access the swap device should of course run first, in general this just means `udev` + `autodetect` -- if the swap partition is on an LVM2 partition, *then* `lvm2` hook is also ran -- again, run the minimum needed to access to the swap partition, then follow it by the `resume` hook. i don't remember for sure, but IIRC so long as the `udev` hook is ran before `resume` (always), you *should* be able to use the device UUID or label.
the `filesystem` hook is install-only (no actual hook) ... it just adds all the FS modules (usually filtered by `autodetect` hook) -- the order won't make a difference -- in general it should be last or near the end. IIRC `resume` should normally follow `udev` unless the setup is a bit more complex (eg, LVM2).
i don't really use hibernation, but there is likely a way to increase verbosity by modifying the initramfs hook and rebuilding the image. FTW, i use nouveau with suspend-to-RAM often, without issue.
--
C Anthony
As I have things set, I have no problems with "suspend to RAM" (actually what gets written into /sys/power/state is "mem", and I use "acpitool -s" for that in a similar script I use for suspend to disk)...
I use suspend to disk to resume work after a night, or days, in which case suspend to RAM is not good given its power consumption, not to mention consuming power and the environment, :-)
So, as I haven't experienced problems with suspend to RAM, my supposition, and perhaps other's, was that we were talking about suspend to disk...
BTW, you were right about the resume hook, only thing is that it's documented in the pm-utils wiki which I do not use, :-) Not sure if that'll help me specifying the resume swap partition with UUID type of specification instead of plain partition, I'll have to try out, :-)
Still don't know if referred to suspend to ram or disk, but I moved "resume" before "filesystems" in the hooks array, and I experience just the same thing, as mentioned by someone else... -- Javier.