can't suspend when using acpi_call

[esbennn]

Greetings

As the header indicates, my lappy wont suspend.
To get it to suspend in the first place, i did this: http://forums.fedoraforum.org/showthread.php?t=265588 which works fine.

But as it's a laptop with nvidia optimus, i am using acpi_call to disable the discrete card to save power. Information on this can be found here: https://github.com/mkottman/acpi_call

Once the discrete card has been dsabled, suspend doesn't work. I didn't expect it to either. Screen just goes blank and hdd spins down, but the computer is still on.

However, i would expect it to work if i use acpi_call to turn the card back on. But it doesn't - it does almost the same as before, except it leaves some text on the screen: http://dl.dropbox.com/u/5416864/2012-01-06_16-02-39_511.jpg
I have also tried unloading the acpi_call module (and re-enabling the card) like this:
sudo rmmod acpi_call

So right now, i have to choose between bad battery life and no ability to suspend.

I would be so very pleased, if anyone had any idea how to work around this.

Thanks in advance :)

Oh, btw here's the /var/log/pm-suspend.log from a failed suspend:
[esben@fedora ~]$ cat /var/log/pm-suspend.log
Initial commandline parameters:
Sat Jan 7 19:12:06 CET 2012: Running hooks for suspend.
Running hook /usr/lib64/pm-utils/sleep.d/00logging suspend suspend:
Linux fedora 3.1.6-1.fc16.x86_64 #1 SMP Wed Dec 21 22:41:17 UTC 2011 x86_64 x86_64 x86_64 GNU/Linux
Module Size Used by
rfcomm 63357 4
ppdev 8131 0
parport_pc 21058 0
lp 10418 0
parport 35827 3 ppdev,parport_pc,lp
lockd 78490 0
bnep 15370 2
nf_conntrack_ipv4 9030 2
nf_defrag_ipv4 1561 1 nf_conntrack_ipv4
ip6t_REJECT 4451 2
nf_conntrack_ipv6 8338 2
nf_defrag_ipv6 9740 1 nf_conntrack_ipv6
xt_state 1370 4
nf_conntrack 76503 3 nf_conntrack_ipv4,nf_conntrack_ipv6,xt_state
ip6table_filter 1735 1
ip6_tables 19304 1 ip6table_filter
fuse 69330 7
snd_hda_codec_hdmi 25842 1
snd_hda_codec_realtek 327386 1
uvcvideo 66310 0
videodev 92903 1 uvcvideo
media 12416 2 uvcvideo,videodev
v4l2_compat_ioctl32 9334 1 videodev
snd_hda_intel 26310 1
snd_hda_codec 97519 3 snd_hda_codec_hdmi,snd_hda_codec_realtek,snd_hda_i ntel
snd_hwdep 6891 1 snd_hda_codec
snd_seq 58599 0
snd_seq_device 6425 1 snd_seq
snd_pcm 89984 3 snd_hda_codec_hdmi,snd_hda_intel,snd_hda_codec
arc4 1481 2
asus_nb_wmi 1915 0
asus_wmi 16175 1 asus_nb_wmi
sparse_keymap 3854 1 asus_wmi
uinput 8254 0
joydev 10372 0
ath3k 6383 0
btusb 16240 1
bluetooth 237251 24 rfcomm,bnep,ath3k,btusb
ath9k 87851 0
microcode 19616 0
mac80211 244208 1 ath9k
i2c_i801 9893 0
ath9k_common 2904 1 ath9k
ath9k_hw 369409 2 ath9k,ath9k_common
snd_timer 22199 2 snd_seq,snd_pcm
snd 71085 11 snd_hda_codec_hdmi,snd_hda_codec_realtek,snd_hda_i ntel,snd_hda_codec,snd_hwdep,snd_seq,snd_seq_devic e,snd_pcm,snd_timer
ath 16506 3 ath9k,ath9k_common,ath9k_hw
soundcore 7124 1 snd
snd_page_alloc 8061 2 snd_hda_intel,snd_pcm
cfg80211 181887 3 ath9k,mac80211,ath
iTCO_wdt 12452 0
iTCO_vendor_support 2699 1 iTCO_wdt
atl1c 35691 0
serio_raw 4558 0
sunrpc 225584 2 lockd
rfkill 17938 5 asus_wmi,bluetooth,cfg80211
binfmt_misc 7775 1
nouveau 754554 0
i915 560335 4
ttm 61533 1 nouveau
drm_kms_helper 30277 2 nouveau,i915
drm 213647 7 nouveau,ttm,i915,drm_kms_helper
i2c_algo_bit 5572 2 nouveau,i915
mxm_wmi 1743 1 nouveau
i2c_core 28203 7 videodev,i2c_i801,nouveau,i915,drm_kms_helper,drm, i2c_algo_bit
wmi 9737 2 asus_wmi,mxm_wmi
video 12388 2 nouveau,i915
total used free shared buffers cached
Mem: 8080616 1748792 6331824 0 50312 915752
-/+ buffers/cache: 782728 7297888
Swap: 2064380 0 2064380

/usr/lib64/pm-utils/sleep.d/00logging suspend suspend: success.
Running hook /usr/lib64/pm-utils/sleep.d/00powersave suspend suspend:

/usr/lib64/pm-utils/sleep.d/00powersave suspend suspend: success.
Running hook /usr/lib64/pm-utils/sleep.d/01grub suspend suspend:

/usr/lib64/pm-utils/sleep.d/01grub suspend suspend: not applicable.
Running hook /etc/pm/sleep.d/20_custom-ehci_hcd suspend suspend:

/etc/pm/sleep.d/20_custom-ehci_hcd suspend suspend: success.
Running hook /usr/lib64/pm-utils/sleep.d/49bluetooth suspend suspend:

/usr/lib64/pm-utils/sleep.d/49bluetooth suspend suspend: not applicable.
Running hook /usr/lib64/pm-utils/sleep.d/55NetworkManager suspend suspend:
Having NetworkManager put all interfaces to sleep...Done.

/usr/lib64/pm-utils/sleep.d/55NetworkManager suspend suspend: success.
Running hook /usr/lib64/pm-utils/sleep.d/56atd suspend suspend:

/usr/lib64/pm-utils/sleep.d/56atd suspend suspend: success.
Running hook /usr/lib64/pm-utils/sleep.d/56dhclient suspend suspend:

/usr/lib64/pm-utils/sleep.d/56dhclient suspend suspend: success.
Running hook /usr/lib64/pm-utils/sleep.d/75modules suspend suspend:

/usr/lib64/pm-utils/sleep.d/75modules suspend suspend: not applicable.
Running hook /usr/lib64/pm-utils/sleep.d/90clock suspend suspend:

/usr/lib64/pm-utils/sleep.d/90clock suspend suspend: not applicable.
Running hook /usr/lib64/pm-utils/sleep.d/94cpufreq suspend suspend:

/usr/lib64/pm-utils/sleep.d/94cpufreq suspend suspend: success.
Running hook /usr/lib64/pm-utils/sleep.d/95led suspend suspend:

/usr/lib64/pm-utils/sleep.d/95led suspend suspend: not applicable.
Running hook /usr/lib64/pm-utils/sleep.d/95packagekit suspend suspend:

/usr/lib64/pm-utils/sleep.d/95packagekit suspend suspend: success.
Running hook /usr/lib64/pm-utils/sleep.d/98video-quirk-db-handler suspend suspend:
Kernel modesetting video driver detected, not using quirks.

/usr/lib64/pm-utils/sleep.d/98video-quirk-db-handler suspend suspend: success.
Running hook /usr/lib64/pm-utils/sleep.d/99video suspend suspend:
kernel.acpi_video_flags = 0

/usr/lib64/pm-utils/sleep.d/99video suspend suspend: success.
Sat Jan 7 19:12:06 CET 2012: performing suspend

[Dutchy]

Hi, I also do have an Asus and use the same usb suspend script as you to enable sleep in the first place as well as acpicall to save some power.

Let me first state that I do not have any trouble with this setup nor do I have a solution to your problem.

I believe I do not need to remove the module in order to get it to sleep (but it also shouldn't hurt to do so).
Are you using any other power saving methods?
I have experienced your symptoms when I'd enabled certain options with Powertop.

Are you having problems with suspend, hibernate or both?
Your screen shot seem to be a resume from hibernate and I recognize the ironlake part which is relate to the Intel igp (I do not know what it means but when I boot with an external monitor attached (and the laptop's screen is off) I experience a hang at boot).
Do you use any kernel arguments?
I use these:
-rdblacklist=nouveau (to disable the nouveau drivers (which causes the error messages))
-i915.i915_enable_rc6=1 (Intel Core I power saving)
-i915.i915_enable_fbc=1 (Intel power saving)
-i915.lvds_downclock=1 (Intel power saving)

I've read that a problem of acpi_call is that it is actually a kind of hack and there is no certainty that it plays nice with the hardware or BIOS.

So to me your options are:
-Make a choice between sleep or power saving (the latter seems best to me although it depends on how long you use it each time).
-Update acpi_call and/or try to find ways to debug it for your system
-Update your BIOS may help (or even screw things up more), however BIOS updates for laptops most of the time are insignificant.

[esbennn]

Just tried hibernation - no dice. Leaves me with a black screen and a blinking cursor.
Not doing anything else to save power.
Also i am not using any special kernel arguments - in fact i forgot where to put them, could you enlighten me? Maybe that's my problem :)

In this post http://forums.fedoraforum.org/showthread.php?t=265588, are you using the first or the second script? I am using the first one, but they seem quite different, so maybe that has some influence.

thanks for ur help :)

[Dutchy]

Hmmm, they both seem alike but a somewhat different from mine (https://help.ubuntu.com/community/Asus_N53).

To enable the kernel arguments you can interrupt grub and press "e" to edit the boot paramaters (append the arguments).
To make them permanent edit /etc/default/grub (put the "special" arguments at GRUB_CMDLINE_LINUX_DEFAULT=" ").
After that run grub2-mkconfig -o /boot/grub2/grub.cfg (info (http://fedoraproject.org/wiki/Features/Grub2)).

When I think of it, It actually sounds to me like your sleep script isn't doing its thing (I also do not see it comming up in the suspend.log).
Is that script placed in /etc/pm/sleep.d with root and execute permissions?

[esbennn]

Hm, i believe it is:
[esben@fedora ~]$ dir /etc/pm/sleep.d/ -l
total 4
-rwxr-xr-x. 1 root root 1168 Jan 6 19:42 20_custom-ehci_hcd


I will try the script you are using and adding the kernel arguments to see if it makes any difference.

Also, have you had luck with bumblebee on fedora?

[Dutchy]

No, not yet.
More interested in power saving for now.

The permissions seem right.
/etc/pm/sleep.d/20_custom-ehci_hcd suspend suspend: success.
There it is, I just missed it ;)

[esbennn]

Hm, i don't get it...

The script you are using acts in the same way, and the kernel arguments don't make any difference concerning suspend.

The machine is able to suspend and resume just fine until i disable the nvidia card with acpi_call.
And from then on it doesn't work - even though i reverse those commands by doing the opposite acpi call and remove the acpi_call.ko mod.

So this
sudo insmod /home/esben/acpi_call/acpi_call.ko
sudo sh /home/esben/acpi_call/test_off.sh
must change something, that isn't changed back by
sudo rmmod acpi_call
sudo echo '\_SB.PCI0.PEG0.GFX0.DON' > /proc/acpi/call

What could that possibly be?

[duende]

sudo rmmod acpi_call
sudo echo '\_SB.PCI0.PEG0.GFX0.DON' > /proc/acpi/call

Are you sure that you should be executing the first command BEFORE the second?
In fact I suppose you do not need to unload the module at all.

I also use acpi_call but on a different model of notebook (Asus U36JC) I used the instructions I found a long time ago here:
http://ubuntuforums.org/showthread.php?t=1705406
You can try it. Everything works perfectly for me. (Watch it - it is a different model - uses different calls for /proc/acpi/call, also, you might not need these parts with usb3.0 - I don't know if your model has it)
I do not think with this method acpi_call gets unloaded

[esbennn]

Oh, that was supposed to be in the opposite order.
Not sure that the module needs to be removed, but it doesn't work either way.

It's practically the same laptop, just with a newer processor and graphics card - so that it works for you is promosing.
By the way, is your computers power consumption as described in that guide?
After disabling the nvidia card, mine still has a discharge rate of at least 1500 mW :S

[duende]

Oh, that was supposed to be in the opposite order.
Not sure that the module needs to be removed, but it doesn't work either way.

I was not sure, just thought that perhaps the second command did not really do anything once the module was removed. But it seems that the problem is elsewhere. I hope the method from the link above works for you.

By the way, is your computers power consumption as described in that guide?
After disabling the nvidia card, mine still has a discharge rate of at least 1500 mW :S
When the computer is not working very hard: with nvidia card enabled the discharging rate is about 18000 mW, after disabling nvidia card it is usually somewhere between 12000 and 13000 mW, and the lowest I have seen is 11000 (I use KDE).



EDIT:

Of course the ubuntu method has to be modified to suit Fedora. For example in the file /etc/init.d/optimusoff
line

. /lib/lsb/init-functions

had to be changed
to

. /etc/init.d/functions

Unfortunately I do not remember all the changes, but they were very few and rather obvious.

EDIT2
Sorry, it seems I have not read your first post properly. It seems to me that your problem is that you have nouveau loaded - it should not be.
Have you passed the argument to the kernel ? Also, blacklist nouveau /etc/modprobe.d.
Nouveau should not appear when you run lsmod.

[esbennn]

That's interesting, i had not noticed that.
I have blacklisted nouveau in the kernel arguments now with "rdblacklist=nouveau" (correct me if i'm wrong :) ) then, do i make this file /etc/modprobe.d/nouveau_blacklist_ck.conf
with content: blacklist nouveau?

[duende]

I think that was also something about updating initramfs (I do not remember because I did it a long time ago).
In fact, I have just checked, that now I do not have any parameters in grub refering to nouveau. I just have a file
/etc/modprobe.d/blacklist-nvidia.conf with content

blacklist nouveau
blacklist nvidia

and this is all, as far as I can tell. Probably when the new kernel is installed this file gets read, and taken into account in initramfs.
You could simply try reinstalling the kernel and see what happens, or find out how to recreate initramfs (with dracut ?)

In any case, on my computer nouveau does not get loaded at all.

[esbennn]

Okay, this is weird.

I installed system updates incl. new kernel and blacklisted nouveau and nvidia.
Now the computer acts as if the nvidia card is off all the time, concerning battery discharge rate and fan speeds. However this
$ lspci |grep VGA
00:02.0 VGA compatible controller: Intel Corporation 2nd Generation Core Processor Family Integrated Graphics Controller (rev 09)
01:00.0 VGA compatible controller: nVidia Corporation Device 1050 (rev a1)
[esben@fedora ~]$

seems to me like it is still present.

However, suspend works without a hassle, and the command to load the acpi_call module no longer functions:
$ sudo insmod /home/esben/acpi_call/acpi_call.ko
insmod: error inserting '/home/esben/acpi_call/acpi_call.ko': -1 Invalid module format
[esben@fedora ~]$


which makes me quite unable to use the actual call to disable the card.

wtf ???

Did the new kernel do this?

[duende]

You have to compile acpi_call against every new kernel.
(Just to compile and insert module, all the configuration files remain the same.
With every kernel update I simply repeat the lines from

Code:

cd acpi_call/
make

.......

to
....

sudo cp acpi_call.ko /lib/modules/<UNAME -R VALUE>/kernel/drivers/acpi/
sudo depmod

in that ubuntu guide that I mentioned.


The fact that lspci still shows the card is quite normal. I have the same. How about lsmod? Is nouveau still there or not?

[esbennn]

Ah, but of course. Concerning lsmod, it's the fact that it says 'rev a1' in the parentheses in the nvidia line. It used to say 'ref ff' when i had switched the card off, so that's sort of a hint that the card is still on.
But battery life is similar to when i switched it off before i blacklisted nouveau, and (i think) similar to windows at about 4-6 hours with wifi on and screen brightness somewhere in the middle.

Every trace of nouveau and nvidia has disappeared after being blacklisted :)

[duende]

Well, that is interesting.

I did not know what (rev a1) was. But if the battery life is now long, I suppose it solves your problem.

I have kernel 3.1.7-1.fc16.x86_64 and still have to switch off the card with acpi_call.

[esbennn]

Yeah. I recompiled the acpi_call module and by using it battery life is now even longer.
And wha'ts even better, suspend now works!

Blacklisting nouveau and nvidia seemed to do it, and by adding

echo '\_SB.PCI0.PEG0.GFX0.DOFF' > /proc/acpi/call
at the buttom of the resume|thaw) section to the suspend script /etc/pm/sleep.d/20_custom-ehci_hcd disables the card again upon resume.
(The one i'm using can be found here (https://help.ubuntu.com/community/Asus_N53))

Then i just created a script to disable the card and added it to startup applications:
#!/bin/bash
#Disable nvidia card
sudo insmod /home/esben/acpi_call/acpi_call.ko
sudo sh /home/esben/acpi_call/test_off.sh


Thanks for your help guys :)
Unless you have anything to add, ill mark this thread as solved.

[duende]

Congratulations on having solved the problem! :)

[esbennn]

All thanks to you guys ;)