Created attachment 166851 [details] Upper half of the screen during hang I'm the owner of a 15-inch late 2011 MacBook Pro. If I boot the system in the default setup, it completely hangs shortly after starting the X server (at least, AFAICT). If I boot with "nomodeset" appended to the kernel parameters, then the system boots fine. This has happened for a long time now, so it's not a recent regression or anything. I'm on Debian Unstable, with an untainted kernel installed from experimental. I will attach all relevant logs. All logs are from a boot with "nomodeset" appended. I'll also attach photos of the logs that appear on the screen at the time of the hang. These photos are from a slightly different kernel, but the symptoms are the same. I'm comfortable applying patches and building the kernel from source. $ uname -a Linux caught-sigsegv 3.18.0-trunk-amd64 #1 SMP Debian 3.18.6-1~exp1 (2015-02-07) x86_64 GNU/Linux $ cat /proc/sys/kernel/tainted 0
Created attachment 166861 [details] Lower half of the screen during hang
Created attachment 166871 [details] sudo lspci -vvv
Created attachment 166881 [details] cat /proc/cpuinfo
Created attachment 166891 [details] cat /proc/iomem
Created attachment 166901 [details] cat /proc/ioports
Created attachment 166911 [details] cat /proc/modules
Created attachment 166921 [details] cat /var/log/Xorg.0.log
I neglected to mention that I've also filed this bug downstream as Debian bug #778441[1]. [1]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=778441
Looks like this should be reassigned to the Intel component.
You have a muxed hybrid laptop with multiple GPUs. IIRC, Macs require a special driver and probably special handling to switch the mux between the AMD and the Intel GPUs.
FWIW I've got the same notebook and I can confirm the gmux is problematic (the apple-gmux driver should support it in theory). Though I don't think it ever hanged for me, but you can easily lose the display on bootup depending on how you boot - there's essentially 3 different methods: 1) via CSM bios emulation. In this case you will get working AMD graphics, with no ability to switch to the intel one (it does not even appear in the pci device list). 2) via direct efi boot (refind or similar). This will get you working AMD graphics like the above, with the theoretical ability to switch to the intel one with vgaswitcheroo as it is now properly enumerated and the apple-gmux driver used, however switching does not actually work (it seems the intel graphics only works if it was active on boot in my experiments). (*) 3) via grub-efi (looks like this is what you do?). Unfortunately this will not work without extra grub parameters, because the radeon graphics bios cannot be retrieved (though last I looked there was some discussion about fixing this in grub, so it may work with a newer grub version). The grub parameters are to force the mux to switch to intel graphics, in which case you get working intel (but not amd) graphics, though you won't see initial bootup messages before kms is loaded. (Note that after suspend/resume, the AMD chip will be powered on but unused again for some needlessly higher (IIRC over 5W) power consumption, though you can write a hack app to force it off again.) This page has some information on this - in particular the 4 outb commands for the grub config: http://blog.tkassembled.com/364/intel-graphics-on-a-2011-macbook-pro-in-linux/ (*) I actually got switching graphics to work as a proof-of-concept by using direct efi boot and forcing the gmux to intel by using the efi console, though halfway through you will lose the screen in there and have to remember what keystrokes are needed to select the right boot entry in the refind menu...
(In reply to Roland Scheidegger from comment #11) > 3) via grub-efi (looks like this is what you do?). Yeah, this is what I do. Apple EFI loads, loads GRUB by default (can't remember the exact magic incantation of Apple `bless` I used to make this work), and then GRUB loads the Linux kernel. $ apt show grub2 | grep Version Version: 2.02~beta2-21 That *should* correspond to the version of GRUB installed in the drive? > http://blog.tkassembled.com/364/intel-graphics-on-a-2011-macbook-pro-in- > linux/ Thanks, I'll take a look.
(In reply to Alex Jordan from comment #12) > (In reply to Roland Scheidegger from comment #11) > > 3) via grub-efi (looks like this is what you do?). > > Yeah, this is what I do. Apple EFI loads, loads GRUB by default (can't > remember the exact magic incantation of Apple `bless` I used to make this > work), and then GRUB loads the Linux kernel. > > $ apt show grub2 | grep Version > Version: 2.02~beta2-21 > It is quite possible this was never actually fixed (you should get some "radeon 0000:01:00.0: Invalid ROM contents" and "[drm:radeon_get_bios] *ERROR* Unable to locate a BIOS ROM" if it doesn't work due to this). There's plenty of bugs filed all around (here's another one: https://bugzilla.redhat.com/show_bug.cgi?id=765954) with various obscure workarounds all boiling down to pretty much the same (I never tried those suggesting disabling kms, as I wouldn't describe a ums setup as "working" in any case even if you can get some display output) and I haven't seen anyone claiming it is really working now. Might be worth asking the grub guys again. Though presumably this would not fix the problem that switching soesn't work if not booted with the intel gpu active, which I presume is a problem with the i915 drm driver (but of course can be more easily "fixed" by those outb commands in the grub config).
Macs apparently only make the vbios image available during the pre-OS EFI environment. Once the OS loads, the image is no longer available so the boot loader needs to grab it and stash it somewhere so that the OS can access it once it as taken over. https://bugs.freedesktop.org/show_bug.cgi?id=26891 "As stated above, you cannot use grub to load the firmware as the information is only accessible before you exit the boot services in EFI. The kernel must be booted using EFI stub booting (that's where the code for getting the bios image is). I use rEFInd as this now automaigcally passes the initramfs location to the kernel." Someone would probably need to port the relevant code from rEFInd for grub.
So sorry, I don't know why I never followed up on this. If I understand correctly, I need to file a bug against GRUB, right?