[arch-general] Suspend seems not to work with nVidia Nouveau driver

Angel Velásquez angvp at archlinux.org
Tue Jan 3 20:23:26 EST 2012


-----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 at gmail.com> wrote:
>> On 1/3/12, C Anthony Risinger <anthony at xtfx.me> wrote:
>>> On Tue, Jan 3, 2012 at 2:46 PM, Jonathan Vasquez
>>> <jvasquez1011 at gmail.com> wrote:
>>>> On Tue, Jan 3, 2012 at 3:43 PM, Alex Ferrando
>>>> <alferpal at 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...
> 

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-----


More information about the arch-general mailing list