Description of problem: at boot on kernel 3.7.2-201.fc18.x86_64 in a system with i915 and radeon card available. cat /sys/kernel/debug/vgaswitcheroo/switch 0:IGD: :Pwr:0000:00:02.0 1:DIS:+:Pwr:0000:01:00.0 2:DIS-Audio:+:Pwr:0000:01:00.1 Both cards are active and Xorg attempts to use both which causes graphics corruption, issues with system settings and has led to kernel panics in the i915 module as a result of this. How reproducible: Always
This bug effectively cripples a dual GPU laptop. Has there been any action taken? For the record, this was not an issue in 3.6, but began on the 3.7 kernel line.
This is still an issue on 3.8.0-0.rc6.git0.1.fc19.x86_64
This bug appears to have been reported against 'rawhide' during the Fedora 19 development cycle. Changing version to '19'. (As we did not run this process for some time, it could affect also pre-Fedora 19 development cycle bugs. We are very sorry. It will help us with cleanup during Fedora 19 End Of Life. Thank you.) More information and reason for this action is here: https://fedoraproject.org/wiki/BugZappers/HouseKeeping/Fedora19
[root@f19s Documents]# cat /sys/kernel/debug/vgaswitcheroo/switch 0:IGD: :Pwr:0000:00:02.0 1:DIS:+:Pwr:0000:01:00.0 2:DIS-Audio: :Pwr:0000:01:00.1 3.10.0-0.rc3.git0.1.fc20.x86_64.debug
# uname -a Linux silver.local 3.13.10-200.fc20.x86_64 #1 SMP Mon Apr 14 20:34:16 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux # cat /sys/kernel/debug/vgaswitcheroo/switch 0:IGD: :Pwr:0000:00:02.0 1:DIS:+:DynPwr:0000:01:00.0 2:DIS-Audio: :Pwr:0000:01:00.1 Could someone please take alook at this. Also using a service to disbale one of the cards at boot doesn't really help here. And in general it prevents an out-of-the-box usage of those kind of laptops. It worked with F18 ...
Could this be related to the radeon power management changes ?
Anyone? I don't find a workaround. I tried many combinations of placing it at the correct place during boot and using different DDIS MDIS etc calls to enable only one of the devices.
> > I don't find a workaround. I tried many combinations of placing it at the > correct place during boot and using different DDIS MDIS etc calls to enable > only one of the devices. Don't hold your breath: Kernel developers have made it clear that they don't care about this issue in many forums. There is some work being made by mjg59 on this for MBP retina's but it may be some time before it is in mainline, and even then it may not work on the 8,2. The main issue right now on the 8,2 is the lack of a system called lvds reprobe on i915 that causes the display to black on switch to the i915. Additionally, both cards being enabled on boot, causes all kinds of issues with consoles and X etc. The kernel developers have made clear that they won't support "turn one" of the two cards off in the boot process either. To make this "work" you need to boot with NO outb settings in grub. You need to write a systemd unit that very early in the boot process sets echo OFF > /sys/kernel/debug/vgaswitcheroo/switch To ensure the integrated card is disabled before X starts. Once X starts, to initiate a switch you need to stop the display manager, make the change and then restart the display server. Not that this helps you much: switching to the i915 goes to a black screen, but back to the radeon should work.
So far on Fedora 20 and Rawhide, I've just been adding i915.modeset=0 as a persistent boot parameter, and everything works OK. Although the radeon support is not great, as it's definitely not in any sort of power reduced mode, so the GPU gets warm and fans run even when doing nothing. If I nomodeset to also disable radeon, the problem is eliminated. I can still use gnome-shell but it then uses llvmpipe which soaks the CPU and again the laptop gets hot as a result.
I rebuild my grub2-efi with the outb module, and then add: # Switch display and DDC to internal card outb 0x728 1 outb 0x710 2 outb 0x740 2 # Power down discrete controller outb 0x750 0 Before the load video line. That way I get a working i915 and battery life etc.
(In reply to William Brown from comment #8) ... > To make this "work" you need to boot with NO outb settings in grub. You need > to write a systemd unit that very early in the boot process sets > > echo OFF > /sys/kernel/debug/vgaswitcheroo/switch > > To ensure the integrated card is disabled before X starts. > > Once X starts, to initiate a switch you need to stop the display manager, > make the change and then restart the display server. Not that this helps you > much: switching to the i915 goes to a black screen, but back to the radeon > should work. That is what I tried so far. I'll probably try to keep going into that direction. And try to find the correct systemd service dependencies I need to add so the service is run at the correct time. (In reply to Chris Murphy from comment #9) > So far on Fedora 20 and Rawhide, I've just been adding i915.modeset=0 as a > persistent boot parameter, and everything works OK. Although the radeon > support is not great, as it's definitely not in any sort of power reduced > mode, so the GPU gets warm and fans run even when doing nothing. If I > nomodeset to also disable radeon, the problem is eliminated. I can still use > gnome-shell but it then uses llvmpipe which soaks the CPU and again the > laptop gets hot as a result. That was a great hint! I used radeon.modeset=0 to disable the radeon card instead and use the i915. Hopefully this gives me a bit more battery life.
> That was a great hint! > I used radeon.modeset=0 to disable the radeon card instead and use the i915. > Hopefully this gives me a bit more battery life. This does *not* disable the radeon card. It's still connected, and powered, it's just not being used. That's what appears to give you the saving. The only way to actually switch it off is to modify your grub2-efi to have outb avaliable, and to carry out the steps I noted above.
Please don't put bugs in needinfo with the generic xgl-maint alias.
This message is a notice that Fedora 19 is now at end of life. Fedora has stopped maintaining and issuing updates for Fedora 19. It is Fedora's policy to close all bug reports from releases that are no longer maintained. Approximately 4 (four) weeks from now this bug will be closed as EOL if it remains open with a Fedora 'version' of '19'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 19 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Fedora 19 changed to end-of-life (EOL) status on 2015-01-06. Fedora 19 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.