Bug 15845
Summary: | [PATCH]vgaswitcheroo: System freeze after waking up from suspend to ram and toggling the graphics cards. | ||
---|---|---|---|
Product: | Drivers | Reporter: | Thomas Martitz (kugel) |
Component: | Video(Other) | Assignee: | drivers_video-other |
Status: | RESOLVED OBSOLETE | ||
Severity: | normal | CC: | alan, kugel, mail, nexor, shuber2 |
Priority: | P1 | ||
Hardware: | All | ||
OS: | Linux | ||
Kernel Version: | 2.6.34-rc4 | Subsystem: | |
Regression: | No | Bisected commit-id: | |
Attachments: | [PATCH] Turn the device off after suspend if vga_switcheroo was enabled |
Description
Thomas Martitz
2010-04-25 09:18:04 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 ). *** Bug 16038 has been marked as a duplicate of this bug. *** 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. 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. (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 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. 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 |