[arch-general] Suspend seems not to work with nVidia Nouveau driver
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)
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
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.
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
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
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
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.
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.
-----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+XnaxuGbofRqMO4aWRIYv0XTgxkLz iwU19ELhZ6O+m2Tk4QBe9FGDxO/pfto9O5QGMGTZfQF2j5PJQyqtnqSGCVYDyYOV N04qcwkNLlQcla+ZS2C5chQc35ClV+sYk4Wrn7PuhCv2lcVuwuyieR32l3Jy/UGY IiQOJAQ6mdTL1cgb9Er6d519vM+/hFham6ksb3WOBNCHex3wX/GelajgC6KHWnk= =nj0h -----END PGP SIGNATURE-----
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+XnaxuGbofRqMO4aWRIYv0XTgxkLz iwU19ELhZ6O+m2Tk4QBe9FGDxO/pfto9O5QGMGTZfQF2j5PJQyqtnqSGCVYDyYOV N04qcwkNLlQcla+ZS2C5chQc35ClV+sYk4Wrn7PuhCv2lcVuwuyieR32l3Jy/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
[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
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
[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
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
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.
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
[2012-01-03 21:47:56 -0500] Jonathan Vasquez:
I'm tired of seeing this type of attitude from the Linux community.
The Linux community is tired of seeing this type of attitude from you too.
If people don't speak up against that type of action, then what type of society are we promoting?
One that gets things done. -- Gaetan
On Tue, Jan 3, 2012 at 9:55 PM, Gaetan Bisson <bisson@archlinux.org> wrote:
[2012-01-03 21:47:56 -0500] Jonathan Vasquez:
I'm tired of seeing this type of attitude from the Linux community.
The Linux community is tired of seeing this type of attitude from you too.
If people don't speak up against that type of action, then what type of society are we promoting?
One that gets things done.
-- Gaetan
Before you speak about what attitudes I supposedly have.. why don't you search my forum name "Cows", and see my contributions. I mostly don't even ask for support, I give support. Check the AUR to see the packages I've submitted. While you are at it, why don't you check my Youtube channel "FearedBliss" and or the "Newbie Corner", and see what things I've provided. https://bbs.archlinux.org/viewtopic.php?id=132949 I've been doing things to attract users to Arch. Whether they are newbs or not, because I want people to learn. As long as you have willingness and determination to learn, that is the important thing. The resources are out there, people just need to look, and I'm willing to add to those resources. You aren't adding anything beneficial by telling others that their comments are equal to troll statements, when this is clearly not true. -- Jonathan Vasquez
On Tue, 3 Jan 2012 21:58:34 -0500 Jonathan Vasquez <jvasquez1011@gmail.com> wrote:
Before you speak about what attitudes I supposedly have.. why don't you search my forum name "Cows", and see my contributions. I mostly don't even ask for support, I give support. Check the AUR to see the packages I've submitted. While you are at it, why don't you check my Youtube channel "FearedBliss" and or the "Newbie Corner", and see what things I've provided. https://bbs.archlinux.org/viewtopic.php?id=132949
I've been doing things to attract users to Arch. Whether they are newbs or not, because I want people to learn. As long as you have willingness and determination to learn, that is the important thing. The resources are out there, people just need to look, and I'm willing to add to those resources.
You aren't adding anything beneficial by telling others that their comments are equal to troll statements, when this is clearly not true.
Arch is just software, not a religion -- noone needs your prayers. If you don't have better things to do, at least try reading carefully the original email. You'll see that your mkinitcpio hooks are absolutely irrelevant for the OP problem. On-topic: have anyone tried running pm-suspend with quirks? -- Leonid Isaev GnuPG key ID: 164B5A6D Key fingerprint: C0DF 20D0 C075 C3F1 E1BE 775A A7AE F6CB 164B 5A6D
On Tue, Jan 3, 2012 at 10:09 PM, Leonid Isaev <lisaev@umail.iu.edu> wrote:
On Tue, 3 Jan 2012 21:58:34 -0500 Jonathan Vasquez <jvasquez1011@gmail.com> wrote:
Before you speak about what attitudes I supposedly have.. why don't you search my forum name "Cows", and see my contributions. I mostly don't even ask for support, I give support. Check the AUR to see the packages I've submitted. While you are at it, why don't you check my Youtube channel "FearedBliss" and or the "Newbie Corner", and see what things I've provided. https://bbs.archlinux.org/viewtopic.php?id=132949
I've been doing things to attract users to Arch. Whether they are newbs or not, because I want people to learn. As long as you have willingness and determination to learn, that is the important thing. The resources are out there, people just need to look, and I'm willing to add to those resources.
You aren't adding anything beneficial by telling others that their comments are equal to troll statements, when this is clearly not true.
Arch is just software, not a religion -- noone needs your prayers. If you don't have better things to do, at least try reading carefully the original email. You'll see that your mkinitcpio hooks are absolutely irrelevant for the OP problem.
On-topic: have anyone tried running pm-suspend with quirks?
-- Leonid Isaev GnuPG key ID: 164B5A6D Key fingerprint: C0DF 20D0 C075 C3F1 E1BE 775A A7AE F6CB 164B 5A6D
Who said anything about religion? If I'm so easily willing to leave the Arch community, leave the Linux community, etc etc, how can it be a religion for me? This is no dogma. Being kind to others is not a religion but it's definitely Etiquette. Treating others like crap or animals is an intolerable act in my eyes. Who wants others to be treated like an animal? Like they are worthless, useless, unintelligible beings? You have to be kidding me to give me a freaking "this isn't a religion therefore you can go" statement. It's funny because that statement means that you basically believe that it's ok to treat others like crap as long as you don't consider software a religion, or whatever the reason. OT: I have tried pm-suspend with quirks and it didn't work. My original statement wasn't about the OP's hooks, but they were a confirmation that I was also having a similar issue which I was willing to work with others in order to help solve. Javier confirmed that all 3 of us are having similar issues. The same with Don Juan, and his statement about trying the alternative 'nv' driver. -- Jonathan Vasquez
On 01/03/2012 06:47 PM, Jonathan Vasquez wrote:
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.
I agree these high school, I am better than some bullshit is stupid and its become such a regular thing on most message boards I am on. Debian I think being the worst with uber feminists correcting endless fodder that leads to no real help on situations. Its a new year why cant we all just start off fresh again and drop stupid attitudes over nothing more than who can stick there chest out the furthest and beat it the loudest. I agree more people should speak up about it, its childish behavior and truly is of no benefit to anyone including the one starting the pissing match. Flame me all you want for saying something as well. [OnT] I have noticed the same behavior with the beta nvidia driver as well, nouveau never works for my graphics card and gives more issues than the closed source one. Have you tried running the nv driver? I dropped both the nouveau and closed source driver for this one, as I can get everything working properly and have a decent resolution, this includes suspend and hibernate. But there seems to be no way to get effects, but I could careless about them on my laptop. Until xorg-server or nvidia closed source get their new bugs worked out I am happy on the nv driver and best of all it ALWAYS works for me, just a tad sluggish on opening windows to full screen only thing I have noticed.
On 04/01/12 15:16, Gaetan Bisson 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...
I think it is important to gather as much relative and relevant info as possible when solving a problem. Often patterns can be found that help to resolve the problem. If there is only one perspective on the problem then it is going to be very difficult to ascertain whether there is a pattern.
On Wed, Jan 04, 2012 at 01:16:03PM +1100, Gaetan Bisson wrote:
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...
...And the first use of the word with T goes to... oh, wait a minute! That was good trolling, and really added no value whatsoever to the discussion. If you're boared you could as well try to reproduce the bug. Personally I'm not using hibernation, afaik I'd need to set up swap for that. Also I wasn't aware that I'd have to modify initcpio for that. Maybe I'll play around with it by the end of the week. cheers! mar77i
On 1/3/12, Angel Velásquez <angvp@archlinux.org> wrote:
...
OMG Javier did learn how to bottom-post!
Congratulations \o/
- -- Angel Velásquez
I'm afraid the Javier you're referring to is another one, :-) I've seen a more active Javier on the list. I participate way less since though I have years using/managing linux, I don't consider myself an expert, :-) I've always tried to bottom post in all lists I barely participate in (debian-user, arch-general, and several others)... Sorry to disappoint you, :-) -- Javier.
On Wed, Jan 4, 2012 at 5:34 PM, Javier Vasquez <j.e.vasquez.v@gmail.com>wrote:
I'm afraid the Javier you're referring to is another one, :-)
Angel did confuse you with Jonathan Vasquez who still don't know how to bottom post. -- Cédric Girard
On Jan 4, 2012 11:34 AM, "Javier Vasquez" <j.e.vasquez.v@gmail.com> wrote:
On 1/3/12, Angel Velásquez <angvp@archlinux.org> wrote:
...
OMG Javier did learn how to bottom-post!
Congratulations \o/
- -- Angel Velásquez
I'm afraid the Javier you're referring to is another one, :-) I've seen a more active Javier on the list. I participate way less since though I have years using/managing linux, I don't consider myself an expert, :-)
I've always tried to bottom post in all lists I barely participate in (debian-user, arch-general, and several others)...
Sorry to disappoint you, :-)
-- Javier.
I've been bottom posting for all the posts in the thread and all the other ones as well. I haven't been on the mailing lists for long so the problem was corrected easier. I think you should read my replies and then correct your outdated statement.
On Jan 4, 2012 3:27 PM, "Jonathan Vasquez" <jvasquez1011@gmail.com> wrote:
On Jan 4, 2012 11:34 AM, "Javier Vasquez" <j.e.vasquez.v@gmail.com> wrote:
On 1/3/12, Angel Velásquez <angvp@archlinux.org> wrote:
...
OMG Javier did learn how to bottom-post!
Congratulations \o/
- -- Angel Velásquez
I'm afraid the Javier you're referring to is another one, :-) I've seen a more active Javier on the list. I participate way less since though I have years using/managing linux, I don't consider myself an expert, :-)
I've always tried to bottom post in all lists I barely participate in (debian-user, arch-general, and several others)...
Sorry to disappoint you, :-)
-- Javier.
I've been bottom posting for all the posts in the thread and all the
other ones as well. I haven't been on the mailing lists for long so the problem was corrected easier. I think you should read my replies and then correct your outdated statement. There have been 12 posts I made in this thread, only 1 was top post because it slipped my key stroke.
On Jan 4, 2012 2:30 PM, "Jonathan Vasquez" <jvasquez1011@gmail.com> wrote:
There have been 12 posts I made in this thread, only 1 was top post
because
it slipped my key stroke.
While top posting is indeed annoying (I often waste my own time converting them to inline-style when replying, to preserve context), this thread has no further use ... the OP has neither clarified nor responded. It's all good -- nice work on the contributions elsewhere -- best to simply ignore nonconstructive thoughts entirely. I would recommend you and others open a new thread with your respective hibernation problems. Try tracing the mkinitcpio procedure to learn more ... it's very simple; most hooks only run at creation-time, some at boot-time, and some both. Tweak the kernel line or resume hook to increase verbosity, or add a line to the hook that drops you to an interactive busybox shell for investigation -- explore a bit to learn how. Copy the command printed after `mkinitcpio -p linux` and generate debug images using an alternate target location (and maybe config too) and modify your bootloader on the fly or add a separate entry ... this prevents you from locking yourself out should something go awry. The 'Net welcomes only autodidacts, and expects brute force mastery of knowledge ... success is developing a wickedly efficient attack vector. Good luck. -- C Anthony
On 05-01-12 01:17, C Anthony Risinger wrote:
On Jan 4, 2012 2:30 PM, "Jonathan Vasquez"<jvasquez1011@gmail.com> wrote:
[top posting]
It's all good -- nice work on the contributions elsewhere -- best to simply ignore nonconstructive thoughts entirely.
I would recommend you and others open a new thread with your respective hibernation problems. Try tracing the mkinitcpio procedure to learn more
That advice is of course good. The funny thing is that this thread saw quite a few reactions about mkinitcpio, while the OP said something about a problem with the shutting down part of the process ;). Too bad that one (funny) reaction caused so much turmoil. I hope the OP isn't scared away from asking here. mvg, Guus
participants (14)
-
Alex Ferrando
-
Angel Velásquez
-
C Anthony Risinger
-
Cédric Girard
-
Don Juan
-
Fabio Mancinelli
-
Gaetan Bisson
-
Guus Snijders
-
Javier Vasquez
-
Jonathan Vasquez
-
Leonid Isaev
-
Martin
-
Martti Kühne
-
Ross Hamblin