[arch-general] pm-hibernate not working since update to 3.4.5-1-ARCH
Hello, I have already been used to not beeing able to suspend my MacBook Pro since the buggy nvidia version which came with 3.4.x kernel. But as of the latest updates which brought kernel 3.4.5-1 I am not able to use pm-hibernate anymore. When looking into /var/log/pm-suspend.log it seems that hibernating went well: lots of "success" messages and no errors. But when I then start the MacBook again it does not resume but boots normally. fsck detects that disks haven't been unmounted orderly, recovers journal and I am back to a fresh booted system then. I already looked up the wiki about pm-utils and found something about adding 'acpi_sleep=nonvs' in /boot/grub/menu.lst. Issues mentioned there with kernel versions around 2.6, which seems to be long time ago now. I tried it anyway, but with no effect at all. Any ideas what might be causing this issue? More fresh bugs in nvidia 302.17-3? TIA, Arvid -- [ Arvid Warnecke ][ arvid (at) nostalgix (dot) org ] [ IRC/OPN: "madhatter" ][ http://www.nostalgix.org ] ---[ ThreePiO was right: Let the Wookiee win. ]---
Op vrijdag 20 juli 2012 08:05:33 schreef Arvid Warnecke:
Hello,
I have already been used to not beeing able to suspend my MacBook Pro since the buggy nvidia version which came with 3.4.x kernel. But as of the latest updates which brought kernel 3.4.5-1 I am not able to use pm-hibernate anymore. When looking into /var/log/pm-suspend.log it seems that hibernating went well: lots of "success" messages and no errors. But when I then start the MacBook again it does not resume but boots normally. fsck detects that disks haven't been unmounted orderly, recovers journal and I am back to a fresh booted system then.
I already looked up the wiki about pm-utils and found something about adding 'acpi_sleep=nonvs' in /boot/grub/menu.lst. Issues mentioned there with kernel versions around 2.6, which seems to be long time ago now. I tried it anyway, but with no effect at all.
Any ideas what might be causing this issue? More fresh bugs in nvidia 302.17-3?
TIA, Arvid
-- [ Arvid Warnecke ][ arvid (at) nostalgix (dot) org ] [ IRC/OPN: "madhatter" ][ http://www.nostalgix.org ] ---[ ThreePiO was right: Let the Wookiee win. ]---
could you try the same with the long lived branch of nvidia utils and drivers? these are at version 295.59 nvidia-ll: https://aur.archlinux.org/packages.php?ID=60602 nvidia-utils-ll: https://aur.archlinux.org/packages.php?ID=60604 fist build utils, then driver --Ike
On 20 July 2012 09:27, Ike Devolder <ike.devolder@gmail.com> wrote:
could you try the same with the long lived branch of nvidia utils and drivers?
these are at version 295.59
nvidia-ll: https://aur.archlinux.org/packages.php?ID=60602 nvidia-utils-ll: https://aur.archlinux.org/packages.php?ID=60604
fist build utils, then driver
--Ike
nouveau or vesa would be probably even better, because this way we could better track down what is causing it (kernel or nvidia binary driver). Lukas
Op vrijdag 20 juli 2012 16:11:43 schreef Lukáš Jirkovský:
On 20 July 2012 09:27, Ike Devolder <ike.devolder@gmail.com> wrote:
could you try the same with the long lived branch of nvidia utils and drivers?
these are at version 295.59
nvidia-ll: https://aur.archlinux.org/packages.php?ID=60602 nvidia-utils-ll: https://aur.archlinux.org/packages.php?ID=60604
fist build utils, then driver
--Ike
nouveau or vesa would be probably even better, because this way we could better track down what is causing it (kernel or nvidia binary driver).
Lukas
Well in my case the suspend to ram problems are gone when using the long lived branch nvidia drivers, the new ones don't come back up --Ike
Hello, On Fri, Jul 20, 2012 at 04:14:35PM +0200, Ike Devolder wrote:
Op vrijdag 20 juli 2012 16:11:43 schreef Lukáš Jirkovský:
On 20 July 2012 09:27, Ike Devolder <ike.devolder@gmail.com> wrote:
could you try the same with the long lived branch of nvidia utils and drivers?
these are at version 295.59
nvidia-ll: https://aur.archlinux.org/packages.php?ID=60602 nvidia-utils-ll: https://aur.archlinux.org/packages.php?ID=60604
fist build utils, then driver
I will try that. Do they work with the current kernel? I have already been thinking about downgrading the nvidia package to nvidia-295.53-1, which seems to be the last version from the official repository whithout such issues.
nouveau or vesa would be probably even better, because this way we could better track down what is causing it (kernel or nvidia binary driver).
I can try to do so, too. I moved to nvidia from the nouveau because I had to disable acceleration on nouveau because of the graphics board in my Macbook Pro. Seemed to be a well known issue.
Cheers, Arvid -- [ Arvid Warnecke ][ arvid (at) nostalgix (dot) org ] [ IRC/OPN: "madhatter" ][ http://www.nostalgix.org ] ---[ ThreePiO was right: Let the Wookiee win. ]---
Op vrijdag 20 juli 2012 17:11:12 schreef Arvid Warnecke:
Hello,
On Fri, Jul 20, 2012 at 04:14:35PM +0200, Ike Devolder wrote:
Op vrijdag 20 juli 2012 16:11:43 schreef Lukáš Jirkovský:
On 20 July 2012 09:27, Ike Devolder <ike.devolder@gmail.com> wrote:
could you try the same with the long lived branch of nvidia utils and drivers?
these are at version 295.59
nvidia-ll: https://aur.archlinux.org/packages.php?ID=60602 nvidia-utils-ll: https://aur.archlinux.org/packages.php?ID=60604
fist build utils, then driver
I will try that. Do they work with the current kernel?
yes they do 3.4.6 just works fine
I have already been thinking about downgrading the nvidia package to nvidia-295.53-1, which seems to be the last version from the official repository whithout such issues.
nouveau or vesa would be probably even better, because this way we could better track down what is causing it (kernel or nvidia binary driver).
I can try to do so, too. I moved to nvidia from the nouveau because I had to disable acceleration on nouveau because of the graphics board in my Macbook Pro. Seemed to be a well known issue.
Cheers, Arvid --Ike
Hello Ike, On Fri, Jul 20, 2012 at 09:27:22AM +0200, Ike Devolder wrote:
Op vrijdag 20 juli 2012 08:05:33 schreef Arvid Warnecke:
I have already been used to not beeing able to suspend my MacBook Pro since the buggy nvidia version which came with 3.4.x kernel. But as of the latest updates which brought kernel 3.4.5-1 I am not able to use pm-hibernate anymore. When looking into /var/log/pm-suspend.log it seems that hibernating went well: lots of "success" messages and no errors. But when I then start the MacBook again it does not resume but boots normally. fsck detects that disks haven't been unmounted orderly, recovers journal and I am back to a fresh booted system then.
Any ideas what might be causing this issue? More fresh bugs in nvidia 302.17-3?
could you try the same with the long lived branch of nvidia utils and drivers?
these are at version 295.59
nvidia-ll: https://aur.archlinux.org/packages.php?ID=60602 nvidia-utils-ll: https://aur.archlinux.org/packages.php?ID=60604
fist build utils, then driver
Is there an ideal way of replacing nvidia by nvidia-ll? I build the utils, but am not able to install it, because the actually installed nvidia requires the other nvidia-utils. ┌─[ madhatter(archBookPro):~/builds/nvidia-ll ] └──╼ makepkg -sf ==> Making package: nvidia-ll 295.59-2 (Fr 20. Jul 21:51:18 CEST 2012) ==> Checking runtime dependencies... ==> Installing missing dependencies... error: target not found: nvidia-utils-ll=295.59 ==> ERROR: 'pacman' failed to install missing dependencies. The utils are build, but not installed yet. Hmpf, Arvid -- [ Arvid Warnecke ][ arvid (at) nostalgix (dot) org ] [ IRC/OPN: "madhatter" ][ http://www.nostalgix.org ] ---[ ThreePiO was right: Let the Wookiee win. ]---
On Fri, Jul 20, 2012 at 09:53:01PM +0200, Arvid Warnecke wrote:
Hello Ike,
On Fri, Jul 20, 2012 at 09:27:22AM +0200, Ike Devolder wrote:
Op vrijdag 20 juli 2012 08:05:33 schreef Arvid Warnecke:
I have already been used to not beeing able to suspend my MacBook Pro since the buggy nvidia version which came with 3.4.x kernel. But as of the latest updates which brought kernel 3.4.5-1 I am not able to use pm-hibernate anymore. When looking into /var/log/pm-suspend.log it seems that hibernating went well: lots of "success" messages and no errors. But when I then start the MacBook again it does not resume but boots normally. fsck detects that disks haven't been unmounted orderly, recovers journal and I am back to a fresh booted system then.
Any ideas what might be causing this issue? More fresh bugs in nvidia 302.17-3?
could you try the same with the long lived branch of nvidia utils and drivers?
these are at version 295.59
nvidia-ll: https://aur.archlinux.org/packages.php?ID=60602 nvidia-utils-ll: https://aur.archlinux.org/packages.php?ID=60604
fist build utils, then driver
Is there an ideal way of replacing nvidia by nvidia-ll? I build the utils, but am not able to install it, because the actually installed nvidia requires the other nvidia-utils.
┌─[ madhatter(archBookPro):~/builds/nvidia-ll ] └──╼ makepkg -sf ==> Making package: nvidia-ll 295.59-2 (Fr 20. Jul 21:51:18 CEST 2012) ==> Checking runtime dependencies... ==> Installing missing dependencies... error: target not found: nvidia-utils-ll=295.59 ==> ERROR: 'pacman' failed to install missing dependencies.
The utils are build, but not installed yet.
Hmpf, Arvid
-- [ Arvid Warnecke ][ arvid (at) nostalgix (dot) org ] [ IRC/OPN: "madhatter" ][ http://www.nostalgix.org ] ---[ ThreePiO was right: Let the Wookiee win. ]---
remove the ones that are already installed, and then finish building and installing the new ones
On Fri, Jul 20, 2012 at 03:52:34PM -0400, Daniel Wallace wrote:
On Fri, Jul 20, 2012 at 09:53:01PM +0200, Arvid Warnecke wrote:
On Fri, Jul 20, 2012 at 09:27:22AM +0200, Ike Devolder wrote:
could you try the same with the long lived branch of nvidia utils and drivers?
these are at version 295.59
nvidia-ll: https://aur.archlinux.org/packages.php?ID=60602 nvidia-utils-ll: https://aur.archlinux.org/packages.php?ID=60604
fist build utils, then driver
Is there an ideal way of replacing nvidia by nvidia-ll? I build the utils, but am not able to install it, because the actually installed nvidia requires the other nvidia-utils.
remove the ones that are already installed, and then finish building and installing the new ones
That results in removing 41 packages depending on nvidia and nvidia-utils. Any better way? -- [ Arvid Warnecke ][ arvid (at) nostalgix (dot) org ] [ IRC/OPN: "madhatter" ][ http://www.nostalgix.org ] ---[ ThreePiO was right: Let the Wookiee win. ]---
Op vrijdag 20 juli 2012 22:06:31 schreef Arvid Warnecke:
On Fri, Jul 20, 2012 at 03:52:34PM -0400, Daniel Wallace wrote:
On Fri, Jul 20, 2012 at 09:53:01PM +0200, Arvid Warnecke wrote:
On Fri, Jul 20, 2012 at 09:27:22AM +0200, Ike Devolder wrote:
could you try the same with the long lived branch of nvidia utils and drivers?
these are at version 295.59
nvidia-ll: https://aur.archlinux.org/packages.php?ID=60602 nvidia-utils-ll: https://aur.archlinux.org/packages.php?ID=60604
fist build utils, then driver
Is there an ideal way of replacing nvidia by nvidia-ll? I build the utils, but am not able to install it, because the actually installed nvidia requires the other nvidia-utils.
remove the ones that are already installed, and then finish building and installing the new ones
That results in removing 41 packages depending on nvidia and nvidia-utils. Any better way?
building in chroot or follow the following steps without rebooting: 1) build 'nvidia-utils-ll' 2) remove 'nvidia' 3) install 'nvidia-utils-ll' 4) build 'nvidia-ll' 5) install 'nvidia-ll' and that should do it and not get you to remove many packages --Ike
Hello Ike, On Fri, Jul 20, 2012 at 10:15:48PM +0200, Ike Devolder wrote:
Op vrijdag 20 juli 2012 22:06:31 schreef Arvid Warnecke:
On Fri, Jul 20, 2012 at 03:52:34PM -0400, Daniel Wallace wrote:
On Fri, Jul 20, 2012 at 09:53:01PM +0200, Arvid Warnecke wrote:
Is there an ideal way of replacing nvidia by nvidia-ll? I build the utils, but am not able to install it, because the actually installed nvidia requires the other nvidia-utils.
remove the ones that are already installed, and then finish building and installing the new ones
That results in removing 41 packages depending on nvidia and nvidia-utils. Any better way?
or follow the following steps without rebooting:
1) build 'nvidia-utils-ll' 2) remove 'nvidia' 3) install 'nvidia-utils-ll' 4) build 'nvidia-ll' 5) install 'nvidia-ll'
and that should do it and not get you to remove many packages
Worked well. But did not solve the problem. Hibernation still seems to work at first, but when I start the laptop it boots normally, fscks disks because of unclean unmount and leaves me with a freshly rebooted machine. What does work now with 295.59 for me is pm-suspend. I read a lot about people having issues with nvidia from official, too. But with vbetool dpms on in my handler.sh it seems to work pretty well. Cheers, Arvid -- [ Arvid Warnecke ][ arvid (at) nostalgix (dot) org ] [ IRC/OPN: "madhatter" ][ http://www.nostalgix.org ] ---[ ThreePiO was right: Let the Wookiee win. ]---
Op zaterdag 21 juli 2012 13:30:24 schreef Arvid Warnecke:
Hello Ike,
On Fri, Jul 20, 2012 at 10:15:48PM +0200, Ike Devolder wrote:
Op vrijdag 20 juli 2012 22:06:31 schreef Arvid Warnecke:
On Fri, Jul 20, 2012 at 03:52:34PM -0400, Daniel Wallace wrote:
On Fri, Jul 20, 2012 at 09:53:01PM +0200, Arvid Warnecke wrote:
Is there an ideal way of replacing nvidia by nvidia-ll? I build the utils, but am not able to install it, because the actually installed nvidia requires the other nvidia-utils.
remove the ones that are already installed, and then finish building and installing the new ones
That results in removing 41 packages depending on nvidia and nvidia-utils. Any better way?
or follow the following steps without rebooting:
1) build 'nvidia-utils-ll' 2) remove 'nvidia' 3) install 'nvidia-utils-ll' 4) build 'nvidia-ll' 5) install 'nvidia-ll'
and that should do it and not get you to remove many packages
Worked well. But did not solve the problem. Hibernation still seems to work at first, but when I start the laptop it boots normally, fscks disks because of unclean unmount and leaves me with a freshly rebooted machine.
What does work now with 295.59 for me is pm-suspend. I read a lot about people having issues with nvidia from official, too. But with
vbetool dpms on
in my handler.sh it seems to work pretty well.
Cheers, Arvid
and for the hibernation, do you have the "resume=/my/swap' and do you have the resume hook in your mkinitcpio.conf ? personally i dont use hiberantion since that or fresh boot are both taking approx the same time so then i prefer fresh boot :p. --Ike
On Sat, Jul 21, 2012 at 04:27:41PM +0200, Ike Devolder wrote:
Op zaterdag 21 juli 2012 13:30:24 schreef Arvid Warnecke:
Worked well. But did not solve the problem. Hibernation still seems to work at first, but when I start the laptop it boots normally, fscks disks because of unclean unmount and leaves me with a freshly rebooted machine.
What does work now with 295.59 for me is pm-suspend. I read a lot about people having issues with nvidia from official, too. But with
vbetool dpms on
in my handler.sh it seems to work pretty well.
and for the hibernation, do you have the "resume=/my/swap' and do you have the resume hook in your mkinitcpio.conf ?
No. But I never had and it worked until last week. I will look into that then.
personally i dont use hiberantion since that or fresh boot are both taking approx the same time so then i prefer fresh boot :p.
I agree, but because I still loose battery capacity while suspended, I prefered hibernation. Cheers, Arvid -- [ Arvid Warnecke ][ arvid (at) nostalgix (dot) org ] [ IRC/OPN: "madhatter" ][ http://www.nostalgix.org ] ---[ ThreePiO was right: Let the Wookiee win. ]---
Hi Ike, On Sat, Jul 21, 2012 at 04:27:41PM +0200, Ike Devolder wrote:
Op zaterdag 21 juli 2012 13:30:24 schreef Arvid Warnecke:
Worked well. But did not solve the problem. Hibernation still seems to work at first, but when I start the laptop it boots normally, fscks disks because of unclean unmount and leaves me with a freshly rebooted machine.
What does work now with 295.59 for me is pm-suspend. I read a lot about people having issues with nvidia from official, too. But with
vbetool dpms on
in my handler.sh it seems to work pretty well.
and for the hibernation, do you have the "resume=/my/swap' and do you have the resume hook in your mkinitcpio.conf ?
Okay, I added the hook, as described in the wiki, to the mkinitcpio.conf and checked that the resume part is still in the kernel line of my grub configuration. No luck. When I pm-hibernate and then start again the system boots and does not resume at all. :( Cheers, Arvid -- [ Arvid Warnecke ][ arvid (at) nostalgix (dot) org ] [ IRC/OPN: "madhatter" ][ http://www.nostalgix.org ] ---[ ThreePiO was right: Let the Wookiee win. ]---
On Fri, Jul 20, 2012 at 9:05 AM, Arvid Warnecke <arvid@nostalgix.org> wrote:
When looking into /var/log/pm-suspend.log it seems that hibernating went well: lots of "success" messages and no errors. But when I then start the MacBook again it does not resume but boots normally. fsck detects that disks haven't been unmounted orderly, recovers journal and I am back to a fresh booted system then.
I just have to ask: do you still have the "resume" hook and the related option in kernel command line? I remember this happening when I accidentally lost mine a few weeks earlier. -- Mantas Mikulėnas
Hello, On Fri, Jul 20, 2012 at 10:40:21AM +0300, Mantas Mikulėnas wrote:
On Fri, Jul 20, 2012 at 9:05 AM, Arvid Warnecke <arvid@nostalgix.org> wrote:
When looking into /var/log/pm-suspend.log it seems that hibernating went well: lots of "success" messages and no errors. But when I then start the MacBook again it does not resume but boots normally. fsck detects that disks haven't been unmounted orderly, recovers journal and I am back to a fresh booted system then. I just have to ask: do you still have the "resume" hook and the related option in kernel command line? I remember this happening when I accidentally lost mine a few weeks earlier.
I removed the option from the kernel command line when I noticed that it does not seem to solve my issues. And I have few changes in /etc/acpi/handler.sh which made hibernating possible when closing the lid in the first place: button/lid) case "$3" in close) echo "LID closed!">/dev/tty5 #vbetool dpms off #pm-suspend pm-hibernate ;; open) echo "LID opened!">/dev/tty5 xset -display :0 dpms force on ;; esac ;; Cheers, Arvid -- [ Arvid Warnecke ][ arvid (at) nostalgix (dot) org ] [ IRC/OPN: "madhatter" ][ http://www.nostalgix.org ] ---[ ThreePiO was right: Let the Wookiee win. ]---
participants (5)
-
Arvid Warnecke
-
Daniel Wallace
-
Ike Devolder
-
Lukáš Jirkovský
-
Mantas Mikulėnas