FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > ArchLinux > ArchLinux General Discussion

 
 
LinkBack Thread Tools
 
Old 01-03-2012, 04:52 PM
Jonathan Vasquez
 
Default Suspend seems not to work with nVidia Nouveau driver

On Tue, Jan 3, 2012 at 12:47 PM, Fabio Mancinelli
<fabio.mancinelli@gmail.com> wrote:
> Hi everybody,
>
> I switched from nVidia proprietary drivers, that had some window
> redrawing issues, to nouveau.
>
> This fixed the redrawing issues but made my laptop start to freeze on
> suspend (with the proprietary driver, suspend worked without any
> issues)
>
> I looked at the log in /var/log/ but everything seems to be ok.
>
> Could you suggest me how can I debug and understand what's going on
> and why suspend stopped to work?
>
> Thanks,
> Fabio
>
> P.S.: When I say "freeze" I mean that the system switches to text
> mode, and the cursor appears in the top left corner (without
> blinking). Everything is blocked and I have to hard-poweroff the
> laptop and restart it.
>
> P.P.S.: Here it is some configuration data:
>
> # uname -a
> Linux nemesis 3.1.6-1-ARCH #1 SMP PREEMPT Thu Dec 22 09:11:48 CET 2011
> x86_64 Intel(R) Core(TM) i5 CPU M 430 @ 2.27GHz GenuineIntel GNU/Linux
>
> # pacman -Q | grep nouveau
> nouveau-dri 7.11.2-1
> xf86-video-nouveau 0.0.16_git20110829-1
>
> # lspci | grep VGA
> 01:00.0 VGA compatible controller: nVidia Corporation GT216 [GeForce
> GT 330M] (rev a2)

For me, I have the proprietary NVIDIA drivers, and everything is
running on LVM, but I have the same problem. I've added "resume" to my
mkinitcpio, and to my parameters for grub.

The problem for me is that when I go to suspend, it doesn't even
suspend, it just closes everything, switches to a black/blank screen
with the blinking symbol _ , and stays there. It doesn't fully shut
down. Then I have to manually restart the computer.

I also have pm-utils installed.

- Jon
 
Old 01-03-2012, 07:25 PM
Javier Vasquez
 
Default Suspend seems not to work with nVidia Nouveau driver

On 1/3/12, Jonathan Vasquez <jvasquez1011@gmail.com> wrote:
> On Tue, Jan 3, 2012 at 12:47 PM, Fabio Mancinelli
> <fabio.mancinelli@gmail.com> wrote:
>> ....
>>
>> This fixed the redrawing issues but made my laptop start to freeze on
>> suspend (with the proprietary driver, suspend worked without any
>> issues)
>>
>> I looked at the log in /var/log/ but everything seems to be ok.
>>
>> ...
>>
>> Thanks,
>> Fabio
>>
>> P.S.: When I say "freeze" I mean that the system switches to text
>> mode, and the cursor appears in the top left corner (without
>> blinking). Everything is blocked and I have to hard-poweroff the
>> laptop and restart it.
>>
>> P.P.S.: Here it is some configuration data:
>>
>> ...
>
> For me, I have the proprietary NVIDIA drivers, and everything is
> running on LVM, but I have the same problem. I've added "resume" to my
> mkinitcpio, and to my parameters for grub.
>
> The problem for me is that when I go to suspend, it doesn't even
> suspend, it just closes everything, switches to a black/blank screen
> with the blinking symbol _ , and stays there. It doesn't fully shut
> down. Then I have to manually restart the computer.
>
> I also have pm-utils installed.
>
> - Jon

Jah, not only me then, :-)

This is happening to me as well for 3 years, but not all the time
(maybe 1 out of 3). I also use nouveau, but what I'm using right now
to suspend is:

% cat /usr/bin/local_s2disk.sh
#!/usr/bin/env sh

echo "Suspending to Disk NOW..."
sync
swapoff -a
swapon -a
netcfg -a
acpitool -S
netcfg-menu

I believe "acpitool -S" does a direct write of "disk" to
/sys/power/state, but I prefer acpitool, and I've been using it for
quiet a while, :-)

I also have:

% 'grep' resume /etc/mkinitcpio.conf
HOOKS="base udev autodetect pata scsi sata usb filesystems keymap
usbinput resume"

% 'grep' resume /etc/default/grub
GRUB_CMDLINE_LINUX_DEFAULT="resume=/dev/sda5"

And I still get the misbehavior when attempting to suspend some times.

As a side note, I wanted to use the UUID format to specify the swap
partition to grab the image from which to resume, which works for me
on debian. But on arch I'm not sure if it's due to the initrd image
generated, or the way the kernel is compiled, but it doesn't work, I
have to specify plain partition... Not sure if any one has tried
using UUID instead.

--
Javier.
 
Old 01-03-2012, 07:46 PM
Jonathan Vasquez
 
Default Suspend seems not to work with nVidia Nouveau driver

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

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"

--
Jonathan Vasquez
 
Old 01-03-2012, 08:28 PM
C Anthony Risinger
 
Default Suspend seems not to work with nVidia Nouveau driver

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
 
Old 01-03-2012, 09:39 PM
Javier Vasquez
 
Default Suspend seems not to work with nVidia Nouveau driver

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, :-)

--
Javier.
 
Old 01-03-2012, 10:15 PM
Javier Vasquez
 
Default Suspend seems not to work with nVidia Nouveau driver

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.
 
Old 01-04-2012, 12:27 AM
Jonathan Vasquez
 
Default Suspend seems not to work with nVidia Nouveau driver

2012/1/3 Angel Velásquez <angvp@archlinux.org>:
> -----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@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...
>>
>
> 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+XnaxuGbofRqMO4 aWRIYv0XTgxkLz
> iwU19ELhZ6O+m2Tk4QBe9FGDxO/pfto9O5QGMGTZfQF2j5PJQyqtnqSGCVYDyYOV
> N04qcwkNLlQcla+ZS2C5chQc35ClV+sYk4Wrn7PuhCv2lcVuwu yieR32l3Jy/UGY
> IiQOJAQ6mdTL1cgb9Er6d519vM+/hFham6ksb3WOBNCHex3wX/GelajgC6KHWnk=
> =nj0h
> -----END PGP SIGNATURE-----

How is this relevant to help Javier fix his problem? It seems like you
are just trolling on people that have legitimate questions. Signal to
Noise increased.

--
Jonathan Vasquez
 
Old 01-04-2012, 01:30 AM
Jonathan Vasquez
 
Default Suspend seems not to work with nVidia Nouveau driver

Are you freaking kidding me? If I have the same problem as a fellow
Arch user, then it's my god damn right to post it with him. If we both
have a problem that are alike, then maybe there is a freaking
correlation with other users that have not have the time nor the
energy to post? How do you think problems will ever get solved? If you
are an Arch user, you sure aren't acting like someone who is
interesting in working with upstream. How will you know what's wrong
all by yourself in your little cave? The only reason you would know
besides problems that don't affect you is if community members speak
up and post there problems as well. Eventually we will find the
underlying issue, and if it's a problem with upstream, then the Arch
Linux distro as a whole has a responsibility to put it's philosophy
where it's mouth is and report the problems together to upstream.

So don't come to me with your bull of that my comments provide no
further value to this conversation. Reanalyze the conversation, the
words, intentions, and meanings of the posters, or get the hell out.
Or maybe you will lose another valuable member to your community.

On Tue, Jan 3, 2012 at 9:16 PM, Gaetan Bisson <bisson@archlinux.org> wrote:
> [2012-01-03 20:27:57 -0500] Jonathan Vasquez:
>> It seems like you are just trolling on people that have legitimate
>> questions. Signal to Noise increased.
>
> Exactly!
>
> Even Angel's troll brings more signal to this discussion than your "I
> have the same problem and no clue how to diagnose/fix it" messages...
>
> --
> Gaetan



--
Jonathan Vasquez
 
Old 01-04-2012, 01:44 AM
Jonathan Vasquez
 
Default Suspend seems not to work with nVidia Nouveau driver

On Tue, Jan 3, 2012 at 9:41 PM, Gaetan Bisson <bisson@archlinux.org> wrote:
> [2012-01-03 21:30:25 -0500] Jonathan Vasquez:
>> How do you think problems will ever get solved?
>
> When somebody actually *investigates* the issue, as opposed to
> incoherently describe random aspects of their setup and never get to the
> bottom of anything.
>
>> If you are an Arch user, you sure aren't acting like someone who is
>> interesting in working with upstream.
>
> You're so funny...
>
> --
> Gaetan

Yes, it looks like I am very funny, because you by yourself, are a
glorified Archer, and can detect errors, and fix all your problems
independently with upstream. Good lucky with that. No point of even
being part of the Open Source community if you want to isolate
yourself and treat others like crap.

Freaking ridiculous.

--
Jonathan Vasquez
 
Old 01-04-2012, 01:47 AM
Jonathan Vasquez
 
Default Suspend seems not to work with nVidia Nouveau driver

On Tue, Jan 3, 2012 at 9:47 PM, Martin <mzecher@gmail.com> wrote:
> Please stop fighting, this list is intended for technical discussions and
> not personal problems.
>
>
> On Tue, 03 Jan 2012 23:44:10 -0300, Jonathan Vasquez
> <jvasquez1011@gmail.com> wrote:
>
>> On Tue, Jan 3, 2012 at 9:41 PM, Gaetan Bisson <bisson@archlinux.org>
>> wrote:
>>>
>>> [2012-01-03 21:30:25 -0500] Jonathan Vasquez:
>
> <snip>
>
>>>
>>> When somebody actually *investigates* the issue, as opposed to
>>> incoherently describe random aspects of their setup and never get to the
>>> bottom of anything.
>>>
> <snip>
>
>>>
>>> You're so funny...
>>>
>>> --
>>> Gaetan
>>
>>
>> Yes, it looks like I am very funny, because you by yourself, are a
>> glorified Archer, and can detect errors, and fix all your problems
>> independently with upstream. Good lucky with that. No point of even
>> being part of the Open Source community if you want to isolate
>> yourself and treat others like crap.
>>
>> Freaking ridiculous.
>>
>
>

It's ok Martin. I decided to speak up on behalf of the members because
I'm tired of seeing this type of attitude from the Linux community.
People thinking that they are better than everyone else. This isn't
just an Arch thing, a lot of distros have these types of users, and so
does society. If people don't speak up against that type of action,
then what type of society are we promoting. I'm out of these mailing
lists. Later.

--
Jonathan Vasquez
 

Thread Tools




All times are GMT. The time now is 01:00 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright ©2007 - 2008, www.linux-archive.org