Bug 15845 - [PATCH]vgaswitcheroo: System freeze after waking up from suspend to ram and toggling the graphics cards.
[PATCH]vgaswitcheroo: System freeze after waking up from suspend to ram and t...
Status: RESOLVED OBSOLETE
Product: Drivers
Classification: Unclassified
Component: Video(Other)
All Linux
: P1 normal
Assigned To: drivers_video-other
:
: 16038 (view as bug list)
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2010-04-25 09:18 UTC by Thomas Martitz
Modified: 2013-12-10 18:25 UTC (History)
5 users (show)

See Also:
Kernel Version: 2.6.34-rc4
Tree: Mainline
Regression: No


Attachments
[PATCH] Turn the device off after suspend if vga_switcheroo was enabled (3.91 KB, patch)
2012-05-15 13:16 UTC, Peter Wu
Details | Diff

Description Thomas Martitz 2010-04-25 09:18:04 UTC
When coming back from stand-by/suspend to ram, then both cards are on (Windows has this problem as well). The problematic thing: vgaswitcheroo is misdetecting the state of the card that was off before going to stand-by (i.e. it thinks it's still off). 
When I try to turn off the discrete card explicitly (echo OFF > /sys/[...]/switch), nothing happens (probably because vgaswitcheroo things it's off) as the energy drawn from the battery is still high. But turning it on (echo ON > /sys/[...]/switch) before turning it off, and then turning it off makes my system freeze completely. Hence I'm unable to switch the external card of after waking up from stand-by (this toggling works on Windows as a workaround).

My system is an acer 3810tg. My boot parameters are "ro quiet splash acpi_backlight=vendor i8042.reset=1". Note that I need i8042.reset=1 to be able to wakeup from stand-by in the first place (otherwise the system would simply turn off, see https://bugs.launchpad.net/ubuntu/+source/linux/+bug/405120 and https://bugzilla.kernel.org/show_bug.cgi?id=15612
Comment 1 Attilio 2010-05-22 14:55:51 UTC
My system suffers from the same problem, it's an Acer 4810TG and i'm using mainline kernel 2.6.34 on a Fedora 13 (beta) system.

The exact steps I do are:

1. check the power consumption with powertop, which shows 10-11W
2. put the system on suspend to ram
3. resume, which seems to work OK
4. now powertop shows 14-15W, which, in my case, is still lower than when I leave both cards on, which is around 20W

  [root@acer vgaswitcheroo]# cat switch 
  0: :Off:0000:01:00.0
  1:+:Pwr:0000:00:02.0
(0 is the radeon, 1 the integrated)


5. (optional) run "echo OFF >" to the switch, which results in no change
6. try with "echo DDIS >" or "echo ON >", wich makes crash the shell process, and after a few seconds the whole X freezes and can't be stopped, forcing me to hard-reset the machine. Background processes seems to survive.

I've also experienced a similar behavior in Ubuntu with a patched 2.6.33 kernel.
I've tried with the default fedora boot arguments and with i8042.nomux, which fixes the touchpad but makes no difference to this bug.

As the reporter mentioned, the abnormal power consumption happens on Windows 7 as well, probably doesn't so in Vista, as the reports found on the web don't mention it (see http://www.theacerguy.com/forum/topic/timeline-4810tg-standby-bug-windows-7 ).
Comment 2 Stefan Huber 2010-05-23 20:23:22 UTC
*** Bug 16038 has been marked as a duplicate of this bug. ***
Comment 3 Stefan Huber 2010-05-24 08:49:49 UTC
As I wrote in the (duplicate) bug report (bug 16038) the kernel hang can be circumvented by powering both cards before suspending. Hence -- without counter checking on my system -- I would conjecture that 'echo "ON" > /sys/.../switch' leads to a call of 'vga_switchon()' on the pretended non-powered card.

If I find some more spare time I will check this in more depth.
Comment 4 Attilio 2010-05-24 11:55:44 UTC
Enlightened from Stefan Hauber's post, I've been able to workaround the issue creating a trivial pm-utils hook, I'm posting it in case anyone (even less) experienced than me passes by:

#!/bin/bash
case $1 in
        suspend)
                echo ON > /sys/kernel/debug/vgaswitcheroo/switch
                ;;
        resume)
                echo OFF > /sys/kernel/debug/vgaswitcheroo/switch
                ;;
esac

Put the code in /etc/pm/sleep.d/20-vgaswitcheroo-workaround and make the file executable.
Comment 5 Stefan Huber 2010-05-24 17:24:58 UTC
(In reply to comment #4)
> Enlightened from Stefan Hauber's post, I've been able to workaround the issue
> creating a trivial pm-utils hook,

In fact I use a similar script as workaround. But for the matter of completeness I show you my file '/etc/pm/sleep.d/90vga_switch' which also takes hibernating to disc into account:

#!/bin/sh
case "$1" in
        hibernate|suspend)
                echo ON > /sys/kernel/debug/vgaswitcheroo/switch
                ;;
        thaw|resume)
                echo OFF > /sys/kernel/debug/vgaswitcheroo/switch
                ;;
esac
Comment 6 Marco Trevisan (Treviño) 2012-03-14 13:24:15 UTC
And as result of this bug, when using my ATi discrete card (with the integrated one turned off), and I suspend to ram, once I wakeup my laptop, the backlight of my screen is turned off (maybe because linked to the Intel integrated card) and the only way I have to turn it on is to do (using ssh or just typing without seeing anything, of course):

echo DIGD > /sys/kernel/debug/vgaswitcheroo/switch
echo OFF > /sys/kernel/debug/vgaswitcheroo/switch

Using scripts like these works for me, but I guess that the problem should be fixed even at kernel level.
Comment 7 Peter Wu 2012-05-15 13:16:39 UTC
Created attachment 73302 [details]
[PATCH] Turn the device off after suspend if vga_switcheroo was enabled

This issue occurs because the suspend/resume sequence brings the device back to D0 (fully on) state where it was in D3 before suspending.

I had one solution that has to be implemented in the video drivers themselves (radeon, nouveau). The "dumb, ugly, but working" solution is enabling the video card before suspend, and disabling it again when resuming. This idea is used in practise by bbswitch [1].

However, since the card is going to suspend anyway, this seems somehow silly to me. A better approach would skip enabling the card before suspend, and do some magic on resume to ensure that the saved state is still valid and the card is off. I made a patch in December 2011 for nouveau, but am not sure if there were any issues with it (cannot remember). If you know more about it, please review and/ or test.

Also, I have not checked if it has any side effects to enter suspend with the video card disabled (besides the issues on resume that were mentioned before)

 [1]: https://github.com/Bumblebee-Project/bbswitch/issues

Note You need to log in before you can comment on or make changes to this bug.