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): Fedora-16-x86_64-DVD.iso 3.1.0-7.fc16.x86_64 How reproducible: Always 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.
Created attachment 544651 [details] dmesg_mbp82_EFI_boot1.txt
Created attachment 544652 [details] dmesg_mbp82_EFI_boot2.txt
Created attachment 544654 [details] photo of display problem
I can confirm that this happens on my mac book to.
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.
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: nomodset radeon.modeset=0 No difference in behavior.
What behaviour do you get if you blacklist the radeon module (or intel) in the kernel arguments?
Would that be rdblacklist=radeon for AMD? I'm not sure what it is for Intel graphics.
Fedora-17-Beta-x86_64-DVD.iso linux 3.3.0-1 rdblacklist=radeon radeon.modeset=1 radeon.modeset=0 nomodeset No difference, garbled screen persists.
Is this related to bug 735860?
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. https://bugzilla.redhat.com/show_bug.cgi?id=751147#c32
Interesting. https://bugzilla.redhat.com/show_bug.cgi?id=746434#c8 Seems like a good bug to keep track of all of these.
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.
I managed to get Fedora 17 installed using VNC, but I still cannot get X to startup. Anybody find a workaround for this yet?
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?
(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...)
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).
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*/
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.
Created attachment 596106 [details] Grub2-efi config for use with kernel-3.5.0-0-rc5.2.git0
Created attachment 596107 [details] Xorg log running kernel-3.5.0-0.rc5.2.git0
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.
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.
(In reply to comment #24) Works in Rawhide you mean?
(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.
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: #!/bin/sh # /usr/local/bin/igd make this file executable: chmod +x /etc/pm/sleep.d/10igd
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.
See bug 837461 for switcheroo, which is working for me now.
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
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?
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?
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.
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.
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 1:DIS:+:Pwr:0000:01:00.0 2:DIS-Audio:+:Pwr:0000:01:00.1 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.
Has there been any update on this? It would be nice to have the intel GPU working, as the radeon is quite "warm".
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.
Chris: Please see comment #35 If you don't mind, can you do a reboot, and then show the contents of /sys/kernel/debug/vgaswitcheroo/switch The temporary work around is to run echo OFF > /sys/kernel/debug/vgaswitcheroo/switch as root at some stage of the boot process.
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 1:DIS:+:Pwr:0000:01:00.0 2:DIS-Audio:+:Pwr:0000:01:00.1
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.
Still no work on getting the i915 to work in a dual gpu setup?
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.
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.
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.
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.
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 1:DIS:+:Pwr:0000:01:00.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.
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.
Created attachment 816621 [details] dmesg blackscreen kernel 3.5.11
Created attachment 816622 [details] Xorg.log blackscreen kernel 3.5.11
Created attachment 816623 [details] dmesg working kernel 3.11.2
Created attachment 816624 [details] Xorg.log working kernel 3.11.2
Created attachment 816625 [details] dmesg blackscreen kernel 3.11.5
Created attachment 816626 [details] Xorg.log blackscreen kernel 3.11.5
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 1:DIS:+:Pwr:0000:01:00.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.
Created attachment 816881 [details] dmesg 3.11.2 radeon.modeset=0
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.
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 1:DIS:+:Pwr:0000:01:00.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 1:DIS:+:Pwr:0000:01:00.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.
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.
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?
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.
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
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: GRUB_PRELOAD_MODULES="iorw" Then in /etc/grub.d/10_linux: add 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...
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.
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 bug. Thank you for reporting this bug and we are sorry it could not be fixed.
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 GRUB_PRELOAD_MODULES="iorw" 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: https://realmacmods.com/macbook-2011-radeon-gpu-disable/