Bug 765954 - EFI boot failure to properly initialize graphics on Macs with Intel and AMD graphics (MacBookPro 8,2 and 8,3
Summary: EFI boot failure to properly initialize graphics on Macs with Intel and AMD g...
Alias: None
Product: Fedora
Classification: Fedora
Component: xorg-x11-drv-intel
Version: 20
Hardware: x86_64
OS: Linux
Target Milestone: ---
Assignee: Kernel Maintainer List
QA Contact: Fedora Extras Quality Assurance
Depends On:
TreeView+ depends on / blocked
Reported: 2011-12-09 18:45 UTC by Chris Murphy
Modified: 2019-04-15 22:24 UTC (History)
30 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2015-06-29 11:37:32 UTC
Type: ---

Attachments (Terms of Use)
dmesg_mbp82_EFI_boot1.txt (95.04 KB, text/plain)
2011-12-09 18:48 UTC, Chris Murphy
no flags Details
dmesg_mbp82_EFI_boot2.txt (95.41 KB, text/plain)
2011-12-09 18:48 UTC, Chris Murphy
no flags Details
photo of display problem (331.77 KB, image/jpeg)
2011-12-09 18:56 UTC, Chris Murphy
no flags Details
dmesg using linux 3.3.0-0.rc3.git7.2.fc17.x86_64 (104.40 KB, text/plain)
2012-03-09 02:49 UTC, Chris Murphy
no flags Details
dmesg using linux 3.3.4-3.fc17.x86_64 (93.96 KB, text/plain)
2012-05-05 08:34 UTC, Chris Murphy
no flags Details
Grub2-efi config for use with kernel-3.5.0-0-rc5.2.git0 (2.72 KB, application/octet-stream)
2012-07-03 22:34 UTC, Ben Pierce
no flags Details
Xorg log running kernel-3.5.0-0.rc5.2.git0 (28.56 KB, text/x-log)
2012-07-03 22:35 UTC, Ben Pierce
no flags Details
compile to turn off discrete gpu after resume (583 bytes, text/x-csrc)
2012-07-31 19:42 UTC, Ben Pierce
no flags Details
dmesg with kernel 3.6.1-1 (101.50 KB, text/plain)
2012-10-21 19:41 UTC, Chris Murphy
no flags Details
dmesg MacbookPro 8,2 kernel 3.6.10-4 (104.66 KB, text/plain)
2012-12-18 07:21 UTC, Chris Murphy
no flags Details
dmesg blackscreen kernel 3.5.11 (106.08 KB, text/plain)
2013-10-27 23:16 UTC, Chris Murphy
no flags Details
Xorg.log blackscreen kernel 3.5.11 (48.85 KB, text/plain)
2013-10-27 23:16 UTC, Chris Murphy
no flags Details
dmesg working kernel 3.11.2 (103.90 KB, text/plain)
2013-10-27 23:17 UTC, Chris Murphy
no flags Details
Xorg.log working kernel 3.11.2 (46.83 KB, text/plain)
2013-10-27 23:17 UTC, Chris Murphy
no flags Details
dmesg blackscreen kernel 3.11.5 (106.08 KB, text/plain)
2013-10-27 23:18 UTC, Chris Murphy
no flags Details
Xorg.log blackscreen kernel 3.11.5 (48.85 KB, text/plain)
2013-10-27 23:18 UTC, Chris Murphy
no flags Details
dmesg 3.11.2 radeon.modeset=0 (99.04 KB, text/plain)
2013-10-28 19:29 UTC, Chris Murphy
no flags Details
Xorg kernel 3.11.2 radeon.modeset=0 (24.11 KB, text/plain)
2013-10-28 19:31 UTC, Chris Murphy
no flags Details

Description Chris Murphy 2011-12-09 18:45:01 UTC
Description of problem:

Immediately after GRUB Legacy EFI loads vmlinuz and initramfs, display becomes scrambled (see attached photo). 

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1. Insert (verified) DVD.
2. Power up with option key pressed.
3. Choose "EFI Boot" DVD icon in the menu.
4. Wait for GRUB timeout for default option.
Actual results:
Long pause at GRUB timeout menu, all of which looks reasonable and legible. Followed by scrambled display as shown in attached  photo. At no time is there legible text or graphics after GRUB Legacy. It is possible to blindly type commands and output to a USB stick. Attaching two dmesg reports from back to back boots. There appears to be a different number of "EFI: memXXX: type=x, attr=xxx, range=xxxxx" between boots - not sure if something is being corrupted on boot or if this is normal.

Expected results:
Legible text followed by legible graphical startup.

Additional info:
Problem does not occur with CSM-BIOS boot/startup.

Model tested info:
MacBookPro 8,2 (adding 8,3 because it has the same paired graphics)
Intel HD Graphics 3000
AMD Radeon HD 6750M

NOTE: MacBookPro8,2 also comes in a model with Intel HD Graphics 3000 + AMD Radeon HD 6490M . MacBookPro8,1 comes only with Intel HD Graphics 3000.

Comment 1 Chris Murphy 2011-12-09 18:48:05 UTC
Created attachment 544651 [details]

Comment 2 Chris Murphy 2011-12-09 18:48:27 UTC
Created attachment 544652 [details]

Comment 3 Chris Murphy 2011-12-09 18:56:19 UTC
Created attachment 544654 [details]
photo of display problem

Comment 4 Roderick MacKenzie 2011-12-12 14:19:29 UTC
I can confirm that this happens on my mac book to.

Comment 5 Chris Murphy 2012-03-09 02:23:54 UTC
Problem  has regressed in F17 alpha. Shortly after screen scrambles, blue LED on USB stick stops flashing, and I have no ability to ssh into the computer or blindly login to text console and output any messages. I can't tell if I've been dropped into dracut, or panicked.

Comment 6 Chris Murphy 2012-03-09 02:49:28 UTC
Created attachment 568801 [details]
dmesg using linux 3.3.0-0.rc3.git7.2.fc17.x86_64

OK my mistake, I had a 2.5G ramdisk specified as a kernel parameter and I think that was the problem. It does still boot, same behavior as before and per the latest dmesg I'm attaching, same problems getting info from display firmware:

[drm:radeon_get_bios] *ERROR* Unable to locate a BIOS ROM
[drm:intel_dsm_pci_probe] *ERROR* failed to get supported _DSM functions

Still wondering if the problem is that both Intel HD Graphics 3000 and Radeon 6750 graphics are enabled at the same time. I have tried kernel parameters:

No difference in behavior.

Comment 7 James Hogarth 2012-03-23 12:05:30 UTC
What behaviour do you get if you blacklist the radeon module (or intel) in the kernel arguments?

Comment 8 Chris Murphy 2012-03-23 17:30:43 UTC
Would that be rdblacklist=radeon for AMD? I'm not sure what it is for Intel graphics.

Comment 9 Chris Murphy 2012-03-25 05:20:26 UTC
linux 3.3.0-1


No difference, garbled screen persists.

Comment 10 kxra 2012-03-28 02:51:56 UTC
Is this related to bug 735860?

Comment 11 Chris Murphy 2012-03-28 04:38:37 UTC
Bug 735860 is a Macbook Pro 2,1 (2006) with only ATI Mobility Radeon X1600 graphics. This bug, Macbook Pro 8,2 and 8,3 have both Intel HD Graphics 3000, and one of: AMD Radeon HD 6490M , 6750M, or 6770M.

However, the commonality appears to be a problem getting VBIOS information during an EFI boot.

Bug 751147 does not have the same GPU as the above bugs, but Ben Skeggs suspects VBIOS corruption during EFI boot. So it too might be related.

Comment 12 kxra 2012-03-28 04:53:02 UTC


Seems like a good bug to keep track of all of these.

Comment 13 Chris Murphy 2012-05-05 08:34:31 UTC
Created attachment 582262 [details]
dmesg using linux 3.3.4-3.fc17.x86_64

F17 TC3 Live Desktop, EFI boot from USB stick produced with livecd-iso-to-disk. No longer has the garbled display in "photo of display problem" attachment. Text scroll during boot ends at:
[    3.596397] fb: conflicting fb hw usage radeondrmfb vs EFI VGA - removing generic driver
Attaching latest dmesg, linux 3.3.4-3.fc17.x86_64.

Comment 14 meltingrobot 2012-05-29 19:30:52 UTC
I managed to get Fedora 17 installed using VNC, but I still cannot get X to startup.  Anybody find a workaround for this yet?

Comment 15 meltingrobot 2012-05-29 19:31:16 UTC
I managed to get Fedora 17 installed using VNC, but I still cannot get X to startup.  Anybody find a workaround for this yet?

Comment 16 Matthew Stanton 2012-06-02 05:30:51 UTC
I can confirm that this is still an issue on MBP 8,2.  I am booting from the kernel that was released with the Fedora 17 Final DVD (64-bit).  I was able to install from the DVD by using Kernel Parameter nomodeset.  

Booting with intel.modeset=1 radeon.modeset=0 does not work either.  The Intel driver seems to be unable to read the vbios.

What kernel log information can I provide that has not already been provided?

Comment 17 kubrick@fgv6.net 2012-06-02 21:55:59 UTC
(In reply to comment #16)
> I can confirm that this is still an issue on MBP 8,2.  I am booting from the
> kernel that was released with the Fedora 17 Final DVD (64-bit).  I was able
> to install from the DVD by using Kernel Parameter nomodeset.  
> Booting with intel.modeset=1 radeon.modeset=0 does not work either.  The
> Intel driver seems to be unable to read the vbios.
Same problem here and installing AMD proprietary driver didn't helped. (no screens found...)

Comment 18 William Brown 2012-06-17 09:56:16 UTC
I am able to boot without a garbled screen on F17 using nomodeset to a TTY. Of course, X won't start.

From both my experience with my MBP8,2 and from discussions with various people, this is an issue in loading the VBIOS from Efi into grub automatically. You can manually load the vbios using grub2-efi after booting CSM and dumping the vbios. Some individuals have started work on solving why the VBIOS is unabled to be loaded out of grub automatically at this time. 

There is an outline of how to use the i915 from efi on this website http://dentifrice.poivron.org/laptops/macbookpro8,2/ . However, the LVDS patch does not apply as it appears that the code for the i915 has recently changed in kernel versions higher that 3.1. Perhaps a new bugzilla entry is needed for getting the i915 to work with LVDS patch properly. 

Additionally, this site implicates that compiling the vbios into the kernel will work, but like the previous patch is unlikely to apply cleanly.

Finally, this patch http://ubuntuforums.org/showpost.php?p=10848581&postcount=456 will allow the vga_switcheroo to operate for this machine between the radeon and the i915 card. Again, this patch does not apply cleanly to 3.4 and will probably need some work (and a new bugzilla entry).

Comment 19 Ben Pierce 2012-07-03 04:59:14 UTC
looks like linux kernel 3.5 is close to being released and, according to the changelog, lvds_channel in drm/i915 driver is applied.  Fedora popped out 3.4.4 very quickly after release, so I wonder if it's just a matter of weeks till we get this fixed.  /*crossing fingers*/

Comment 20 Adam Williamson 2012-07-03 19:22:50 UTC
There are already 3.5 kernel builds for F18. If you wanted to check, you could grab one of those and either just see if it'll boot on F17, or rebuild from the .src.rpm for F17. http://koji.fedoraproject.org/koji/buildinfo?buildID=328938 is the latest one, as I write this.

Comment 21 Ben Pierce 2012-07-03 22:34:34 UTC
Created attachment 596106 [details]
Grub2-efi config for use with kernel-3.5.0-0-rc5.2.git0

Comment 22 Ben Pierce 2012-07-03 22:35:55 UTC
Created attachment 596107 [details]
Xorg log running kernel-3.5.0-0.rc5.2.git0

Comment 23 Ben Pierce 2012-07-03 22:39:56 UTC
I was able to load kernel-3.5.0-0.rc5.2.git0 from rawhide without issue.  Added i915.lvds_channel_mode=2 and extra pieces to turn off discrete gpu. I am now running perfectly on the intel card.  I have attached my grub2-efi.cfg as well as a copy of my Xorg.0.log.  I no longer have scrambled video using the intel card so looks like the i915 fixes in 3.5 work.  I will test the battery life difference as soon as I have a full charge.

BTW.  I am running a MacbookPro 6,2.

Comment 24 William Brown 2012-07-31 01:06:35 UTC
This appears to work on my MBP 8,2 now (Which is an ATI model, rather than the nvidia in the 6,2), in conjuction with grub2-efi. Graphics work, but gnome3 cannot adjust brightness (But manually echoing to /sys will change the brightness correctly). Resume from suspend DOES NOT work as it would appear that the hardware re-activates the ATI card on resume, which takes over the display channel causing the display to go black. The machine is still functioning, so ssh or keyboard commands still work.

Comment 25 Chris Murphy 2012-07-31 01:25:43 UTC
(In reply to comment #24)
Works in Rawhide you mean?

Comment 26 William Brown 2012-07-31 02:01:09 UTC
(In reply to comment #25)
> (In reply to comment #24)
> Works in Rawhide you mean?

Works on fedora 17, with the 3.5 f17 kernel pulled from koji.

Comment 27 Ben Pierce 2012-07-31 19:42:05 UTC
Created attachment 601571 [details]
compile to turn off discrete gpu after resume

Fix suspend by compiling this file:
gcc -O2 igd.c -o igd

then create new file called "10igd" under /etc/pm/sleep.d:


make this file executable:
chmod +x /etc/pm/sleep.d/10igd

Comment 28 William Brown 2012-07-31 22:51:29 UTC
That script works perfectly, thanks. In the future the "best" solution will be a working vga_switcheroo mechanism (Which I believe is currently in the works). This will reduce the grub2 complexity, and the need for scripts like these.

Comment 29 David Woodhouse 2012-08-01 17:20:02 UTC
See bug 837461 for switcheroo, which is working for me now.

Comment 30 Chris Murphy 2012-10-21 19:41:51 UTC
Created attachment 630999 [details]
dmesg with kernel 3.6.1-1

This is still a problem with F18 beta TC6. Screen goes black between 4 and 5 seconds with rhgb quiet removed and does not come back. kernel is 3.6.1-1.fc18.x86_64.

[9.008514] vga_switcheroo: enabled

Comment 31 William Brown 2012-10-29 04:31:06 UTC
Your dmesg indicates that both cards start up - This in itself may be the issue.

I remember that if I did the wrong commands on VGA switcheroo, if I ever had both cards powered on at once, it would cause the display to go black, and I could never get it back. Perhaps this is a bug in the way that the gmux works, that initially both cards are on at boot?

Perhaps try booting with the grub2 outb lines to switch the gmux over to the i915 at boot, then try swapping to the ati after that?

Comment 32 William Brown 2012-10-31 23:41:22 UTC
In my dmesg on patched 3.5 I get:

i915: switched off

I don't see this in your dmesg. Having a read where this comes from, it's from drivers/gpu/drm/i915/i915_dma.c . For my kernel 3.5, 1257, in 3.6, 1260. the function is i915_switcheroo_set_state. Reading this, it would seem from the i915 that you should either get the message "switched on" or "switched off" if this is being called. But it would appear, it is not being called by this kernel. Again, if my thinking is correct, is this a bug in the apple_gmux?

Comment 33 William Brown 2012-11-08 01:06:15 UTC
I can confirm what Chris reported - I can get TC7 to boot on my MBP, but the display "freezes" partway through. The display however retains information from the kernel output.

Booting with "nomodeset" produces a working text console / text installer, so it's a start.

Comment 34 David Woodhouse 2012-11-08 08:22:10 UTC
This is a problem with matching the EFI framebuffer to the active display. Strangely, the gmux isn't involved in that — it's done by matching the framebuffer sizes. I'm not entirely sure what would happen if the dual display had already been used, and both were set up to be the same size.

Should be fixed in the F18 3.6.6 kernels, after I applied a couple of patches backported from 3.7.

But switching still doesn't actually work. There's still a missing patch to make the Intel device reprobe its LVDS output when we switch to it — and even with that, I get a fading-to-white screen when I switch to IGD. And even switching back to the Radeon doesn't work after that; I get a corrupted screen.

Comment 35 William Brown 2012-11-08 11:20:11 UTC
I have now installed F18 TC7 on my MBP. As suspected, both cards are active when I start X:

0:IGD: :Pwr:0000:00:02.0

However, Xorg shows I am using the radeon.

This makes for a few issues with multiple displays, as Xorg thinks the intel is also a valid display to render to. 

I am on kernel 3.6.6.

Comment 36 William Brown 2012-11-29 12:52:53 UTC
Has there been any update on this? It would be nice to have the intel GPU working, as the radeon is quite "warm".

Comment 37 Chris Murphy 2012-12-18 05:01:25 UTC
Fedora 18 TC3, kernel 3.6.10-4, works! dd'd the LiveCD to a USB stick and booted from it, without any modifications. Does seem quite warm, battery is getting soaked. top reports ~99% idle. System Settings > Displays reports two displays oddly enough.

Comment 38 William Brown 2012-12-18 05:41:22 UTC
Chris: Please see comment #35

If you don't mind, can you do a reboot, and then show the contents of 


The temporary work around is to run

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

as root at some stage of the boot process.

Comment 39 Chris Murphy 2012-12-18 07:21:18 UTC
Created attachment 665339 [details]
dmesg MacbookPro 8,2 kernel 3.6.10-4

There are several ACPI firmware bug messages, so I'm attaching a current dmesg.

[root@localhost liveuser]# cat /sys/kernel/debug/vgaswitcheroo/switch
0:IGD: :Pwr:0000:00:02.0

Comment 40 William Brown 2012-12-18 07:53:18 UTC
Yep, same problem I had. The kernel leaves both GPU's powered on. As stated in comment #38, run

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

To disable the intel gpu. the second monitor display in system settings will go away.

Comment 41 William Brown 2013-02-16 22:37:38 UTC
Still no work on getting the i915 to work in a dual gpu setup?

Comment 42 Chris Murphy 2013-03-22 04:34:58 UTC
Maybe this needs to go against radeon, with a new bug filed, but with up to date F18 infrastructure server (no x), I am getting a regression with 3.9.0-0.rc3.git1.3.fc19.x86_64 where at line:
[    5.772287] fb: conflicting fb hw usage radeondrmfb vs EFI VGA - removing generic driver
The text stops scrolling and the display freezes at that point. I can ssh into the computer. This does not happen with 3.8.3.

I *think* this should go against radeon, and also against 19. But I figured I'd ask here first.

Comment 43 William Brown 2013-03-22 04:45:50 UTC
The issue may be the radeon.

The i915 issue is the lack of LVDS reprobe when you make the switch that the display isn't found.

The radeon issue in 3.9.0 I seem to remember was not radeon itself, but an issue with the EFI fb changes that were made. 

The easiest fix is to build grub2 yourself with the iorw module and then to add the correct outb lines to swap to the i915 on boot. This avoids the reprobe issue.

Comment 44 Chris Murphy 2013-04-05 22:23:38 UTC
The radeon problem may be a 3.9.0 regression so I've filed it as Bug 949083. It may be related to regression Bug 927451, which has an attached patch that fixes both regressions.

Comment 45 William Brown 2013-05-31 05:15:22 UTC
Similar to https://bugzilla.redhat.com/show_bug.cgi?id=837461

This now has been working for a number of kernel versions. You can boot and initialize graphics on macs now from EFI. 

The remaining issue with this technically, is now not the lack of mechanism to do the switch, but deficiencies in the i915 driver to reprobe the LVDS display during the switching process. 

Thus I think this issue should be closed, and the issues with the i915 should be examined more closely.

Comment 46 Chris Murphy 2013-06-02 20:16:54 UTC
With 3.10.0-0.rc3.git0.1.fc20.x86_64.debug I still have problems with the switch. Both i915 and radeon appear to be on:
[root@f19s Documents]# cat /sys/kernel/debug/vgaswitcheroo/switch
0:IGD: :Pwr:0000:00:02.0
2:DIS-Audio: :Pwr:0000:01:00.1

The computer is always very hot, and the fan runs high, even though there are no processes using more than 1% CPU. If I use radeon.modeset=0 this doesn't happen, the computer runs cool, but now I have no graphics at all, basically I'm in runlevel 3.

Comment 47 Chris Murphy 2013-10-27 23:15:31 UTC
This was working with Fedora 20 alpha with 3.11.2-301.fc20.x86_64, but now with Fedora beta TC5 and TC6 with 3.11.5-302.fc20.x86_64  and 3.11.6-301 I'm getting a black screen during the startup process which doesn't recover.

I'm not seeing an obvious difference between 3.11.2 and 3.11.5 to account for this, although the Xorg has quite a few more intel references in the failure case.

Comment 48 Chris Murphy 2013-10-27 23:16:09 UTC
Created attachment 816621 [details]
dmesg blackscreen kernel 3.5.11

Comment 49 Chris Murphy 2013-10-27 23:16:30 UTC
Created attachment 816622 [details]
Xorg.log blackscreen kernel 3.5.11

Comment 50 Chris Murphy 2013-10-27 23:17:29 UTC
Created attachment 816623 [details]
dmesg working kernel 3.11.2

Comment 51 Chris Murphy 2013-10-27 23:17:49 UTC
Created attachment 816624 [details]
Xorg.log working kernel 3.11.2

Comment 52 Chris Murphy 2013-10-27 23:18:21 UTC
Created attachment 816625 [details]
dmesg blackscreen kernel 3.11.5

Comment 53 Chris Murphy 2013-10-27 23:18:48 UTC
Created attachment 816626 [details]
Xorg.log blackscreen kernel 3.11.5

Comment 54 Chris Murphy 2013-10-28 19:26:17 UTC
I can't get i915 graphics to work. Default boot, no kernel parameters:
# cat /sys/kernel/debug/vgaswitcheroo/switch
0:IGD: :Pwr:0000:00:02.0
2:DIS-Audio: :Pwr:0000:01:00.1

If try to switch:
# echo IGD > /sys/kernel/debug/vgaswitcheroo/switch
[   73.867662] vga_switcheroo: client 0 refused switch

If I turn off the disconnected i915 first:
echo OFF > /sys/kernel/debug/vgaswitcheroo/switch

And then try to switch:

# echo IGD > /sys/kernel/debug/vgaswitcheroo/switch
[   87.414576] vga_switcheroo: client 0 refused switch

If I reboot with parameter radeon.modeset=0 then gnome-shell fails to load and also I get no information on adapter status:

cat /sys/kernel/debug/vgaswitcheroo/switch
cat: /sys/kernel/debug/vgaswitcheroo/switch: No such file or directory

So I can't figure out how to actually use only integrated graphics.

Comment 55 Chris Murphy 2013-10-28 19:29:55 UTC
Created attachment 816881 [details]
dmesg 3.11.2 radeon.modeset=0

Comment 56 Chris Murphy 2013-10-28 19:31:14 UTC
Created attachment 816882 [details]
Xorg kernel 3.11.2 radeon.modeset=0

When Xorg tries to load, it seems like it's confused. Screens are found but no screens are found.

[     5.852] (EE) Screen(s) found, but none have a usable configuration.
[     5.852] (EE) 
Fatal server error:
[     5.852] (EE) no screens found(EE) 
[     5.852] (EE) 
Please consult the Fedora Project support 
	 at http://wiki.x.org
 for help. 
[     5.852] (EE) Please also check the log file at "/var/log/Xorg.0.log" for additional information.
[     5.852] (EE) 
[     5.858] (EE) Server terminated with error (1). Closing log file.

Comment 57 Chris Murphy 2013-10-28 20:38:50 UTC
Giving up on 3.11.2 and switcheroo, and moving to the 3.11.5/3.11.6 problem of blackscreen with F20 beta TC6.

I get the same results out of the box as before:
[root@f20live liveuser]# echo OFF > /sys/kernel/debug/vgaswitcheroo/switch
[root@f20live liveuser]# cat /sys/kernel/debug/vgaswitcheroo/switch
0:IGD: :Off:0000:00:02.0
2:DIS-Audio: :Pwr:0000:01:00.1

[root@f20live liveuser]# echo OFF > /sys/kernel/debug/vgaswitcheroo/switch
[root@f20live liveuser]# cat /sys/kernel/debug/vgaswitcheroo/switch
0:IGD: :Off:0000:00:02.0
2:DIS-Audio: :Pwr:0000:01:00.1

Yet the screen is still black.

radeon.modeset=0 and now I at least have text on the screen, but like with 3.11.2 Xorg fails.

i915.modeset=0 and now I get gnome-shell although it took quite a while, over a minute.

Anyway, there's a regression here somewhere, with a workaround to disable the i915 in kernel parameters. But whether the i915 or radeon should be used by default, at the least the display should not be black by default.

Comment 58 Chris Murphy 2013-10-28 20:41:30 UTC
Curiously, this is only a problem for gnome-shell (Live Desktop media). When I boot from the DVD ISO, I get graphical anaconda which I think uses X but not gnome-shell. So... it seems like the black screen might actually be a gnome anomaly.

Comment 59 kubrick@fgv6.net 2013-12-19 11:07:10 UTC
I confirm this is still not working with up to date f20 kernel. I can't even see the /sys/kernel/debug/vgaswitcheroo/ interface.

I have to boot with modprobe.blacklist=i915, (does that disable vgaswitcheroo?) and then X fails to start. If I try loading fglrx, the screen freezes (it unfreezes when I press the prower button). I think it must be some kind of apple_gmux interaction problem.

Anything I can do to try to fix the problem?

Comment 60 Chris Murphy 2013-12-19 17:08:43 UTC
From stock Fedora 20 I apply i915.modeset=0 as a boot parameter, there are some minor artifacts during boot which clear up once gdm is loaded. The reverse is not true, if I disable Radeon graphics, I get some text during boot and then what appears to be a hang in the text scroll in tty1, but I can change to tty2 and login and reboot fine. So that's a problem with i915 graphics, which is the way to get better battery life at the expense of performance.

What also works is nomodeset, and x can now use the EFI/UEFI basic video modes of UGA and GOP graphics. Gnome Shell uses LLVMpipe in this mode so it's probably quite a bit less power efficient than other options as any screen movement causes a large CPU usage increase for gnome-shell and Xorg.

Comment 61 Michele Baldessari 2014-01-05 22:16:04 UTC
Not 100% if it is related here, but at least some pains of vgaswitcheroo
have been improved with this patch: https://lkml.org/lkml/2013/12/31/162

Comment 62 kubrick@fgv6.net 2014-07-06 13:15:27 UTC
FYI, with recent kernel versions on F20, it's working like a charm. Graphic switching is not working but booting on one or the other chip works well.
Unfortunately, this is still not working "out of the box". Just for reference this is what it takes:

To boot on the discrete chip, I use:

radeon.modeset=1 i915.modeset=0 radeon.dpm=1

and for the intel chip:

copy the folder x86_64-efi from /usr/lib/grub/ to /boot/efi/EFI/fedora/

# cp -R /usr/lib/grub/x86_64-efi /boot/efi/EFI/fedora/

edit /etc/default/grub and add the following line:

Then in /etc/grub.d/10_linux:


echo " outb 0x728 1"
echo " outb 0x710 2"
echo " outb 0x740 2"
echo " outb 0x750 0"

under both 'echo " set gfxpayload=' lines

Then update grub

I have 2 different files under /etc/grub.d/, one that generates the menu entries for Inter, the other one for AMD...

Comment 63 Fedora End Of Life 2015-05-29 08:41:35 UTC
This message is a reminder that Fedora 20 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 20. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as EOL if it remains open with a Fedora  'version'
of '20'.

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 20 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.

Comment 64 Fedora End Of Life 2015-06-29 11:37:32 UTC
Fedora 20 changed to end-of-life (EOL) status on 2015-06-23. Fedora 20 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

Thank you for reporting this bug and we are sorry it could not be fixed.

Comment 65 Chris Murphy 2019-04-15 22:24:51 UTC
Update for posterity, based on Fedora 30 (kernel 5.0.7, and grub2-efi-x64-2.02-75.fc30.x86_64, and accounts for BLS changes). Pretty much everyone with these Macs will sooner or later end up with bad radeon GPU which will basically make you think this laptop is toast. But it is possible to disable radeon graphics, and use only i915 graphics.

First choose 1a. or 1b. (macOS or Linux). All commands assume root user, hence #.

1a. macOS: Set NVRAM to prefer i915 graphics at poweron time
a. Boot with command-s to get to single user.
b. Press <Return> key once
c. Type the commands
# nvram fa4ce28d-b62f-4c99-9cc3-6815686e30f9:gpu-power-prefs=%01%00%00%00
# shutdown -h now

1b. linux: Set NVRAM to prefer i915 graphics at poweron time
a. If using an install stick modify grub.cfg to include boot param `radeon.modeset=0` which prevents the radeon driver from loading, which if it does load has a decent chance of causing a kernel panic
b. Type the command
# printf "\x07\x00\x00\x00\x01\x00\x00\x00" > /sys/firmware/efi/efivars/gpu-power-prefs-fa4ce28d-b62f-4c99-9cc3-6815686e30f9
# poweroff -f

2. Get GRUB to power off the radeon GPU; if you're working headless, you can successfully boot an install stick with `radeon.modeset=0` but the radeon GPU will still draw power.

a. Install grub2-efi-x64-modules which is noarch
# dnf install grub2-efi-x64-modules

b. Copy all, or just iorw.mod, to the EFI system partition
# cp -r /usr/lib/grub/x86_64-efi /boot/efi/EFI/fedora/

c. Add this line to /etc/default/grub

d. Edit /etc/grub.d/10_header as follows

   119	# If all_video.mod isn't available load all modules available
   120	# with versions prior to introduction of all_video.mod
   121	cat <<EOF
   122	  if [ x\$feature_all_video_module = xy ]; then
   123	    outb 0x728 1
   124	    outb 0x710 2
   125	    outb 0x740 2
   126	    outb 0x750 0
   127	    insmod all_video
   128	  else
   129	    outb 0x728 1
   130	    outb 0x710 2
   131	    outb 0x740 2
   132	    outb 0x750 0
   133	    insmod efi_gop
   134	    insmod efi_uga
   135	    insmod ieee1275_fb
   136	    insmod vbe
   137	    insmod vga
   138	    insmod video_bochs
   139	    insmod video_cirrus

e. Recreate the grub.cfg
# grub2-mkconfig -o /boot/efi/EFI/fedora/grub.cfg

3. Optional, but a more long term solution is the physical modifications mentioned here:

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