-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 03/01/12 20:15, Javier Vasquez wrote: > On 1/3/12, Javier Vasquez <j.e.vasquez.v@xxxxxxxxx> wrote: >> On 1/3/12, C Anthony Risinger <anthony@xxxxxxx> wrote: >>> On Tue, Jan 3, 2012 at 2:46 PM, Jonathan Vasquez >>> <jvasquez1011@xxxxxxxxx> wrote: >>>> On Tue, Jan 3, 2012 at 3:43 PM, Alex Ferrando >>>> <alferpal@xxxxxxxxx> 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... > OMG Javier did learn how to bottom-post! Congratulations \o/ - -- Angel Velásquez angvp @ irc.freenode.net Arch Linux Developer / Trusted User Linux Counter: #359909 http://www.angvp.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJPA6oOAAoJEEKh2xXsEzut66gH/0vUL79Bc2cDp+Ch48zwj8ee 6G2Es5XIWm5FBOsZZKtx5uz8tUekDHbcDDKQ4yC/efAmlw5uYBBQu6ebqJpUK9qx OIUgIGK9I8yCLsKC3gxtgVdMNoDZ0wcRwAs+XnaxuGbofRqMO4aWRIYv0XTgxkLz iwU19ELhZ6O+m2Tk4QBe9FGDxO/pfto9O5QGMGTZfQF2j5PJQyqtnqSGCVYDyYOV N04qcwkNLlQcla+ZS2C5chQc35ClV+sYk4Wrn7PuhCv2lcVuwuyieR32l3Jy/UGY IiQOJAQ6mdTL1cgb9Er6d519vM+/hFham6ksb3WOBNCHex3wX/GelajgC6KHWnk= =nj0h -----END PGP SIGNATURE-----
