Arch Linux

Update, after downgrading to 2.6.35.8 and .7:

Turns out that *now* in kernel 2.6.35.7 and 8 I have to switch it back on in order to suspend (but it does suspend). I upgraded to .35.7 in 2010-09-30, to .35.8 in 2010-11-06 and to .36 in 2010-11-29.

However, I am absolutely certain that I could do it with the card switched off in 2.6.35.8, because I only figured out recently that I had to unload certain USB 3.0 related modules in order to successfully suspend. So probably has some other cause. Since I have no clue to what that may be I'm attaching pacman.log.

Pacman.log sort of documents my mid-November attempts on suspending eg: install of kernel26-ice, which I later abandoned for pm-suspend/s2ram.

I'm kinda clueless, but uppon checking my pacman.log for possibly relevant upgrades, I found these two that fit the timeframe and were simultaneous with the upgrade to 2.6.36.1:

[2010-11-29 21:20] upgraded intel-dri (7.8.2-3 -> 7.9-1)
[2010-11-29 21:22] upgraded xf86-video-intel (2.12.0-3 -> 2.13.0-4)

Will downgrade them as well and report back. But, otherwise, I'm clueless.

I tried reverting to older packages on the following files, as stated pacman.log:

[2010-12-10 21:12] Running 'pacman -U /var/cache/pacman/pkg/xf86-video-intel-2.12.0-3-x86_64.pkg.tar.xz'
[2010-12-10 21:12] upgraded xf86-video-intel (2.13.0-4 -> 2.12.0-3)
[2010-12-10 21:15] Running 'pacman -U /var/cache/pacman/pkg/intel-dri-7.8.2-3-x86_64.pkg.tar.xz'
[2010-12-10 21:19] Running 'pacman -U /var/cache/pacman/pkg/libgl-7.8.2-3-x86_64.pkg.tar.xz'
[2010-12-10 21:19] Running 'pacman -R intel-dri'
[2010-12-10 21:19] Running 'pacman -R intel-dri xf86-video-intel'
[2010-12-10 21:19] removed xf86-video-intel (2.12.0-3)
[2010-12-10 21:19] removed intel-dri (7.9-1)
[2010-12-10 21:19] Running 'pacman -U /var/cache/pacman/pkg/libgl-7.8.2-3-x86_64.pkg.tar.xz'
[2010-12-10 21:19] upgraded libgl (7.9-1 -> 7.8.2-3)
[2010-12-10 21:19] Running 'pacman -U /var/cache/pacman/pkg/intel-dri-7.8.2-3-x86_64.pkg.tar.xz'
[2010-12-10 21:19] installed intel-dri (7.8.2-3)
[2010-12-10 21:19] Running 'pacman -U /var/cache/pacman/pkg/xf86-video-intel-2.12.0-3-x86_64.pkg.tar.xz'
[2010-12-10 21:20] installed xf86-video-intel (2.12.0-3)
[2010-12-10 21:31] Running 'pacman -U /var/cache/pacman/pkg/libx11-1.3.5-2-x86_64.pkg.tar.xz'
[2010-12-10 21:31] upgraded libx11 (1.4.0-1 -> 1.3.5-2)
[2010-12-10 21:38] Running 'pacman -U /var/cache/pacman/pkg/mesa-7.8.2-3-x86_64.pkg.tar.xz'
[2010-12-10 21:38] upgraded mesa (7.9-1 -> 7.8.2-3)
[2010-12-10 21:45] Running 'pacman -U /var/cache/pacman/pkg/sdl-1.2.14-5-x86_64.pkg.tar.xz'
[2010-12-10 21:45] upgraded sdl (1.2.14-6 -> 1.2.14-5)
[2010-12-10 21:49] Running 'pacman -U /var/cache/pacman/pkg/zvbi-0.2.33-2-x86_64.pkg.tar.gz'
[2010-12-10 21:49] upgraded zvbi (0.2.33-3 -> 0.2.33-2)
[2010-12-10 21:52] Running 'pacman -U /var/cache/pacman/pkg/xorg-server-1.9.2-1-x86_64.pkg.tar.xz'
[2010-12-10 21:53] upgraded xorg-server (1.9.2-2 -> 1.9.2-1)
[2010-12-10 21:53] Running 'pacman -U /var/cache/pacman/pkg/xorg-server-common-1.9.2-1-x86_64.pkg.tar.xz'
[2010-12-10 21:53] upgraded xorg-server-common (1.9.2-2 -> 1.9.2-1)

After this I upgraded the kernel back to 2.6.35.8 and then 2.6.36.1.

Unfortunately, I had no success. I still need to turn the nvidia card back on in both kernel 2.6.35.7 and .8. In kernel 2.6.36.1 I still can't suspend even after turning the nvidia card back on.

However I found that in kernel 2.6.36.1 I am getting some kind of error or error-like message on boot:

Dec 10 22:24:46 xehoz-laptop kernel: fb: conflicting fb hw usage inteldrmfb vs EFI VGA - removing generic driver

I'm attaching the current session log (from everything.log). That message comes up in line 1080. I believe it might be related to nouveau being installed and loaded.

If I blacklist nouveau in rc.conf I am able to normaly suspend (and I am still able to power the card off) with kernel 2.6.36.1 and .2 (I have since upgraded).

However, since absolutely no nvidia/nouveau related packages fit the timeframe that I referred, which is 29th Nov - 5th Dec (I'm 100% sure I was able to do it on the 25th of November, as I did a forum post about it), it still puzzles me what may have caused.

After all these posts a *SUMMARY* may be in order, to clarify what I've done, stated and conclusions/assumptions I reached.

1. Through testing, like I stated above, I believe I demonstrated that it doesn't seam to be kernel related, since even with the older kernels I had to turn the card back on - which I didn't before.

At least, not completely kernel related, as the behavior is different in kernel 2.6.35.7/8 and 2.6.36.1/2: If I turn the card off (a must, since it emanates heat and consumes a lot of power, even if the card isn't usable in the current state of the art), in 2.6.35.7/8 I can suspend if I turn the card back on, but in 2.6.36.1/2 I can't suspend even if the card is turned back on.

2. Absolutely sure that the behavior stated in the description "Until kernel 2.6.35.8, I could suspend with the discrete card switched off" was possible on 25th Nov.

3. Reverting the packages mentioned in the previous comments (and also pm-utils) had no effect. Those packages were updated between 29th Nov and 5th Dec as stated in pacman.log. Other packages were updated but don't seem anyway related to this issue.

4. Deactivating all the daemons, activating them one by one and initiating the system in recovery mode had no effect.

5. Blacklisting nouveau in rc.conf allows suspend.

6. No nvidia related packages were updated between 29th Nov and 5th Dec as stated in pacman.log.

7. I still don't know if the message I started getting in kernel 2.6.36.x has anything to do with this issue: "Dec 10 22:24:46 xehoz-laptop kernel: fb: conflicting fb hw usage inteldrmfb vs EFI VGA - removing generic driver".

any update?

Does the problem persist with 2.6.38? No update since December.

I tested this a couple of weeks ago and I still needed to blacklist nouveau (as well as disabling/enabling usb3.0 before/after suspend). I shall try it again later tonight and report back.

I've tested this from the console (after killing X - see below, after "----". why):
1. It seems that I no longer need to modprobe -r xhci-hcd and ehci-hcd
2. (With nouveau) It *works* if the nvidia card is *on*.
3. (With nouveau) It still *does not work* if the nvidia card is *off* (acpi_call method).
4. (With nouveau) It *works* if the nvidia card is *off* (newish asus_vgaswitcheroo method).

About 'asus_vgaswitcheroo':
https://github.com/awilliam/asus-switcheroo
http://linux-hybrid-graphics.blogspot.com/2011/04/githubcomawilliam-module-explained.html
Mailing list from: https://launchpad.net/~hybrid-graphics-linux
Particularly: https://lists.launchpad.net/hybrid-graphics-linux/msg00765.html

I figure the acpi_call method was always supposed to be a temporary fix, while the kernel vgaswitcheroo didn't work with Nvidia Optimus. While this asus_vgaswitcheroo isn't official yet, it's a very recent solution that seems to work with most Optimus machines - Asus or not.

/var/log/pm-suspend.log output is the same for both the situations in which it works:
-
Activating Runtime PM for device type i2c

/usr/lib/pm-utils/sleep.d/00powersave resume suspend: successs.
Running hook /usr/lib/pm-utils/sleep.d/00logging resume suspend:

/usr/lib/pm-utils/sleep.d/00logging resume suspend: success.
Qua Mai 4 00:29:43 WEST 2011: Finished
-

* package version(s)
kernel26-2.6.38.4-1
pm-utils 1.4.1-3
xf86-video-nouveau 0.0.16_git20110316-2

----

Unfortunately, I can't test it from X (KDE), due to a bug (unreported in Arch Linux bugtracker) in upower. I reported this twice, after being asked to try out a new asus_vgaswitcheroo (that works, at least to disable the discrete card) in the last few weeks in the https://launchpad.net/~hybrid-graphics-linux mailing list:

"About this, there seems to be a problem with upower 0.9.8 and 0.9.9 (testing in arch), when switching OFF. It goes berserk, with 100% CPU usage, as I reported earlier, in another post. I think I haven't tried 0.9.9 by that occasion, but it happens all the same.
upower is required if you use KDE, particularly kdelibs and depends on udev libusb polkit pm-utils dbus-glib (req / dep on Arch Linux) and replaces the old devicekit-power. You get the picture: it's essential in KDE. This happens with the oldish acpi_call method, unless you blacklist nouveau."

This particular problem was reported in Arch's and Gentoo's Forums:
https://bbs.archlinux.org/viewtopic.php?id=112238
http://forums.gentoo.org/viewtopic-t-862188-start-0.html

Since all this acpi_call and vgaswitcheroo stuff is pretty much experimental, I decided not to report it. Not yet, at least. I will, if you think is advisable.

Edit: I just noticed upower 0.9.10-1 was just published. I'll try it out.

I just don't know if tracking such an experimental and quickly evolving feature as a downstream (Archlinux) bug is worthwhile. Perhaps it would be better to just document the current situation on the wiki?