Macbook Pro 7.1 (mid 2010), nvidia blob,efi and hybrid mbr,gpt

JohnWinkerbelt · 2013-05-09 16:59:19

Thank you for pointing out the errors. The post is already updated with this facts. If there are more errors, I want to correct it as right as possible.

And yeah, I don't think about to redo it, it works just fine now. (and even so, I redone and experimented this steps several times to fix this annoying "no device per UUID found" error, without harm, well, it even fixed this problem)
This will be something like a memento for others, who just want to install their system in CSM-mode in the most working and "clean" way as this non-standard mode can provide (any maybe for me, as I plan to buy a ssd in the near future, which results in a reinstall of everything).

I think this can be marked as "half"-solved? The other half depends on nvidia or (with luck equal to the chance, that the moon will fall upon us) Apple themself.

Last edited by JohnWinkerbelt (2013-05-09 17:00:48)

hungerfish · 2013-05-11 11:19:39

So, I actually went ahead and removed the hybrid mbr by creating a protective mbr in its place. As expected, I could no longer boot via syslinux in csm mode, presumably as has been pointed out before, because there no longer was a 'bootable' entry in the mbr.
I've since reverted back to my hybrid mbr, which basically mirrors my gpt layout + 1 small 0xEE partition.

I guess the case is closed for now, thank you all for your constructive input. Marking thread as solved.

Refer to wiki

otonvm · 2013-05-24 15:47:55

I didn't want to start a new thread since I followed this one and then this wiki to this point.
I had the same problem with EFI etc. so I made the hybrid MBR as described. I have a bootable system in EFI mode through refind and I think syslinux works as well but I get the "unable to find root" error.
I did rebuild initramfs with libata and ext4 and they are loaded (lsmod in the recovery shell).

My partitions are as follows:

in GPT:
1: 200MB EF00 (EFI system partition)
2: 430GB AF00 (Mac OS)
3: 35GB 8300 (Arch)

in hybrid MBR (in gdisk recovery menu):
1: 1-39 sectors 0xEE
2: 0xEF
3: 0xAF
4: 0x83 (marked as bootable)

I mount the EFI partition as /boot and it contains initramfs-linux.img, vmlinuz-linux and the syslinux folder.
I installed syslinux with -i -a -m with no errors and this is my cfg:

LABEL arch
	MENU LABEL Arch Linux
	LINUX ../vmlinuz-linux
	APPEND root=/dev/sda3 ro vga=865
	INITRD ../initramfs-linux.img

I also tried sda1, sda2 but no difference.

Any ideas?

hungerfish · 2013-05-24 17:43:57

Well the only difference I can see is that you chose 'sda3' to be marked bootable. I don't see how this matters though, but I myself set the '/boot' partition (so the EFI part, sda1 to be bootable (the 2nd. part in the hybrid mbr), you could try that, but it shouldn't matter.
You could also try adding the 'ahci' module to the initramfs, or some other fs / block device related modules.If you could supply the complete list, I can offer to compare it to my running system.

EDIT:
Try booting with the fallback image. That was what worked for me initially!

Last edited by hungerfish (2013-05-24 17:47:26)

JohnWinkerbelt · 2013-05-26 09:10:46

Funny, I really thought I were the only one with this strange problem. But well.

For me, this "unable to find root" problem happens everytime I reinstall arch on my system after repartitioned it again.
First, it really helps to start with the "fallback image", like hungerfish said and I discovered. I assume that this starting mode is scanning all the available partition and actually search for the root, rather then just look for the specific label or UUID like the normal mode. Well, the official description for this "fallback" is, that initramfs will skip the autodetect hook unlike the normal initramfs and will load the full range of modules available. Either way, it will find your root.

Obviously, neither Grub nor Syslinux will boot the first entry in the beginning.
The "solution" I did is just to redo the making of "hybrid partition" and rebuild the initramfs with "mkinitcpio -p linux"
again and again, I claim that this won't do any more harm than the "unable to find root" problem. I even did this several time until it works. But I still don't know why it suddenly works

What you don't need to but can try to redo as last resort is

* # genfstab -p /mnt >> /mnt/etc/fstab
* reinstall syslinux or grub
* change UUID by hand
* configure syslinux or grub to use label instead of UUID
* append anything to the kernel

The reason is for the first, the genstab already generates the fstab correctly, even if you alter the partition head with gdisk with hybriding, the UUID stays the same as long as you don't repartition the entire disk. If you did this more than one time, then remember to clean up your fstab (at least).
To reinstall syslinux or grub doesn't affect the detection of the disk at all (I assume).
If the system can't find the disk by UUID, then it shouldn't do it by label neither.
To change the UUID by hand is dangerous, because if the detection suddenly works, it still won't find anything (redo this with genfstab if you forgot the old UUID, and clean up afterwards).
The appending won't work, because if the root can't be found then it won't start the kernel at all.

Hopefully this helps somehow.

hungerfish · 2013-05-26 11:31:33

the official description for this "fallback" is, that initramfs will skip the autodetect hook unlike the normal initramfs and will load the full range of modules available.

The 'cannot find root' error means that the kernel can't handle your partitions, requiring additional modules for it to be able to do so. These modules are placed inside the initramfs by the mkinitcpio tool.
In the case of the 'fallback image', this contains 'all' possible modules unlike the 'normal image' which just contains those picked up by the autodetect hook.
Now I imagine that since the original initramfs was built when the system was running in efi-mode, the autodetect hook only detects what is needed for operating in that mode.
Since apple's firmware changes things around when the system is running in csm-mode its quite logical that additional modules are required, especially since the block device interface gets touched (ahci, ata/ide mode).

This has nothing todo with the bootloader, which is already done running by the time you see this error.

otonvm · 2013-06-06 10:39:13

I'm sorry for not replaying earlier, I've been very busy.

I solved this issue by using ata_generic instead of libata (as described here: https://wiki.archlinux.org/index.php/MacBook_Pro_7,1).

Is there a difference?

EDIT:
Ok, I scraped my first installation and started anew. This time I tried to boot a kernel without any modules explicitly defined and it worked. In lsmod there are both ata_generic and libata so I don't know which does what.
I'd still like to know if using a "generic" module has any deleterious effects on performance but I doubt it.

There is another thing I don't quite understand. I'm terrified of modifying partition tables and I followed the instructions by the letter. I understood most of what was happening except one passage:

Type from one to three GPT partition numbers, separated by spaces, to be added to the hybrid MBR, in sequence

If I understand correctly, I created a "false" partition table in which I chose which "real" GPT partitions I wanted to show as MBR.
So if I had 10 GPT partitions I could then choose only the third and the seventh and in MBR that would be 2 partitions, sda1 and sda2, correct?
Then if I booted arch though syslinux, in the os I would see only those two? And conversely when booted through EFISTUB I could see all 10 partitions?

Last edited by otonvm (2013-06-06 22:03:50)

hungerfish · 2013-11-20 12:01:26

I'm really sorry for not getting back to you otonvm, I just missed that you posted here again!
I'm only back here myself, because I have been running into trouble since I upgraded OSX to 10.9.

The problem was that the osx-installer would not allow me to install on to my hdd. It said something like 'no supported disk'.
I discovered that this was due to the esp/efi system partiton no longer having the correct partition code (EF00). I don't know why or when it changed (it got changed to to 0700), but using gdisk it was easily changed back to the correct setting (EF00). The osx-installer then worked. But because it also upgraded the mbp 7.1 firmware, I had to redo my partitioning/hybridization, hence I came back to this thread!

So if you should have problems upgrading osx, the above is the solution. After install, just reinstall refind (I removed it before upgrading osx), and you'll be set to boot right back into efi-mode linux. From there, use gdisk to re-hybridize the disk as explained in the wiki.
Don't forget to also reinstall syslinux! On reboot you should be able to boot in csm-mode via syslinux like before.

@otonvm:
Regarding ata_generic, I've since also added this to mkinitcpio.conf's modules section. I don't know about performance implications, quite possible I believe, but the nvidia-blob leaves us little choice.

If I understand correctly, I created a "false" partition table in which I chose which "real" GPT partitions I wanted to show as MBR.
So if I had 10 GPT partitions I could then choose only the third and the seventh and in MBR that would be 2 partitions, sda1 and sda2, correct?
Then if I booted arch though syslinux, in the os I would see only those two? And conversely when booted through EFISTUB I could see all 10 partitions

To get a better understanding of the whole hybrid-mbr dilemma, I suggest you look at srs5694's site, where he goes onto great detail explaining everything you could possibly want to know on the matter. (he's the author of refind and gdisk!) Great work by the way, both refind and gdisk are invaluable tools to me!!!

You are correct in the idea that you 'fill' your 'false' (its not false, its very real on the disk!) mbr with some of your gpt partitions, which ones is up to you. To make csm-mode work, one of those also needs to be 'active'. Anyway, they wouldn't necessarily be 'sda1' or 'sda2'.
Using gdisk on /dev/sda (press r, then p, then o) will give you a nice overview. You'll see that the descriptors 'sdaX' are relative to the partition table you're looking at.

The hybrid-mbr (the output from 'o') is NOT your partition table when you boot linux, neither in csm-mode nor efi-mode. We only need to set it up so that apple's firmware will allow us to boot in csm-mode. Once syslinux is loaded, the gpt partition table lays down the law so to speak. Except maybe for gpt-unaware tools, so watch out!

If you later must modify your partitions, you need to make sure that the tools you use can work with gpt, and you also need to make sure that if for instance you resize a partition, or add a new one, the entries in the hybrid mbr don't overlap.
In that case all you need to do is adjust the hybrid mbr, which *should* be no problem.
Obviously, you should plan your partition map before you attempt any of this, precisely because its such a fricking mess! You should be terrified!!

JohnWinkerbelt · 2013-11-21 19:57:19

By the way hungerfish,

did you take the opportunity and retried the EFI + nvidia blob?
Because now the nvidia blob had a lot update number jumps in the past until now (currently 331.20-1).

That would be interesting to know, also because you've mentioned, that with 10.9 OSX the firmware even got upgraded.

I'm also about to update to 10.9, only that I'm afraid of nuking something up again and don't have the time to search for the igniter.

Last edited by JohnWinkerbelt (2013-11-21 19:57:47)

hungerfish · 2013-11-22 16:22:58

Sadly, EFI+Blob still doesn't work. Same black-screen crashed xserver
I didn't bother investigating any further, so maybe error-messages changed, but I couldn't be bothered. But using the described setup, its quite easy to try out after every blob-update for instance.

Regarding the OSX10.9 update: I kinda only did it because I got sucked up in a little bit of hype over 10.9. And as I don't really use osx anymore on the mbp but instead archlinux this now looking back seems even more pointless...
Also, running the new osx, my system seem slightly slower. I don't know of this is down to osx10.9 itself, or because I upgraded from 10.6.8. Either way, I don't really care because its only a second-class citizen on that system anyway.

If you do want to upgrade, make sure that you copy the 10.9 image (the app should download into your Applications folder) to a safe location after it has finish downloading via app-store. It would otherwise be deleted after upgrading, and since you may run into trouble (or you want to do a clean install later on) I recommend you preserve it.
Also, I went ahead and created a bootable usb stick from the downloaded image and used that to install.

As mentioned before, I 'uninstalled' refind before attempting installation. Once the dust settles, just reinstall it, and everything should be back to before you upgraded, because normally the upgrade wont touch your partitions.

JohnWinkerbelt · 2014-03-08 19:37:18

Here I am, with some update around EFI, nvidia and updates.

Sadly, here we are, March 2014, the combination above still doesn't work. It ends up with a black screen. Well that is to be exptected. Sadly.
I also updated to Mavericks (10.9, which supposed to have a firmware update), but not only that, I also swapped the internal HDD for a SSD. And because I always whip a partition and reinstall everything again (it's a habit since the windows XP time), I used this opportunity and did various tests before getting to a stable running system again.

First, after a clean install of OSX on the HDD, I didn't noticed some surprising speedup, but at least it's still smooth, no slow downs or any problems are found, except the various Wifi problems until sometimes ago.

After this, I started to swap the HDD for the SSD. The little adventure began. To be short and on track with the main topic here, Nvidia and the "EFI" of Apple still aren't the best friends. So I didn't even try to change configuration in X11, nvidia or kernel (if that would even change anything).

So for all, it's still better to make use of the hybrid way (gpt with hybrid mbr). The advantages still outweight.

Note for the following. I leaved out the SSD and trim story for the sake of simplicity and for those, who doesn't have a SSD. For those who has at least one inside the Macbook, don't worry, if you stick on ext4, you'll be fine for now, but remember to lookup for trim.

So, easiest way (assuming you start from scratch) in short:

    1.1. Install MacOS Mavericks (currently newest) per USB or medium you like. 
    1.2. Goto Disk Utility of MacOS and resize (shrink) the one partition,
         so that you have enough space for arch. How much, that's you choice.
    2.1. Or do the partition work with Arch, Ubuntu Live or whatever you like.
         After this you can install Mavericks, the Installer will only ask
         you about an empty partition, which it is allowed to use.
    3. Either way, after partitioning and installing Mavericks, boot from Arch Medium.
    3.1. Use cgdisk (or gdisk) to create a new partition in the empty space
         you created previously with Disk Utility of MacOS.
    3.2. Do create hybrid mbr with gdisk. It's recommended to only mark
         the first partition, the EFI one, that prevents problems with
         MacOS won't find the partition later on.
    3.3. Install ArchLinux on the partition. The fun fact is,
         you can also create the hybrid after installing Arch if you want.
    3.4. Either way, I'll tell you the way, where we run refind in MacOS and
         configure this, that we can choose to start MacOS or ArchLinux.
         hungerfish will tell you in the wiki the way refind running in Arch instead.
    3.5. Make sure hybrid mbr is correctly created and install grub or syslinux.
         I really prefer syslinux (less configs and simpler), but choose what
         you want and need. Only if hybrid is created, grub or especially
         syslinux can be installed correctly without error.
    3.6. With 3.5 the refind config will be overwritten, so that you will boot
         directly to Arch. We want to end the work with arch-chroot or arch
         installation and reboot with the left ALT key, this will activate
         the chooser in the MacBook, we want to choose the one which
         takes us back to the refind starter. With this, just boot into MacOS,
         re-install refind and you're fine.
    3.7. Now a strange part, if you boot into Arch, it can or even will happen,
         that syslinux won't find the root device. So, before trying anything
         strange, boot from the fallback img first, and then reboot normally again.
         In my case, this already solve this strange behaviour.
         If not, stick to the wiki hungerfish created for us.
    4. With this, anything should work now and
       you can start to config you Arch as you like.

Maybe it's redundant, but this shall be a rough guideline for a hopefully stressless coexistence of the newest MacOS and ArchLinux. This shall act as a "one-go-I-don't-want-to-think-but-only-check-what-I've-done" guide.

Last edited by JohnWinkerbelt (2014-09-02 08:40:11)

otonvm · 2014-04-01 06:52:39

It's been a while but I'm still hopefull!

I nuked my linux install because it was just unusable... However I read this today: http://www.phoronix.com/scan.php?page=n … px=MTY0OTI
I'm not sure if it relates to our problem or not, any expert opinions?

danf · 2014-09-02 03:43:46

I'd just like to chip in and say that this problem is effecting me as well (MacBook Pro 6,2 with GeForce GT 330M, Arch-only). I get the black screen/crashed Xorg when trying to use the proprietary nvidia driver. If anyone makes any progress on this, please post an update

letty · 2015-01-03 12:14:49

danf wrote:

I'd just like to chip in and say that this problem is effecting me as well (MacBook Pro 6,2 with GeForce GT 330M, Arch-only). I get the black screen/crashed Xorg when trying to use the proprietary nvidia driver. If anyone makes any progress on this, please post an update

I've managed to get both intel and nvidia sort of working on the MacBookPro 6,2

I did the following:

install arch according to wiki MacBook 7,1 with instructions for CMS mode using syslinux

install grup for EFI and configure the grub.cfg according to this post. This disables the nvidia card

## custom entry to shutdown nvidia gpu
menuentry 'Arch Linux, intel GPU' {

        insmod gzio
        insmod part_gpt
        insmod ext2

        load_video
        set gfxpayload=keep

        outb 0x728 1
        outb 0x710 2
        outb 0x740 2

        # disable nVidia GPU
        outb 0x750 0

        set root='(hd0,gpt1)'
        search --no-floppy --fs-uuid --set=root ec6d-f507

        echo 'Loading Arch Linux...'
        linux /vmlinuz-linux root=UUID=c62660d2-d891-471a-889e-c521b5589d8d ro \
                i915.lvds_channel_mode=2 i915.modeset=1 i915.lvds_use_ssc=0 nvidia.modeset=0 \
                i915.i915_enable_rc6=1 acpi_backlight=vendor libahci.ignore_sss=1 quiet splash

        echo 'Loading initial ramdisk...'
        initrd /initramfs-linux.img
}

boot with grub and install intel driver and xorg and configure it
copy the /usr/lib/xorg/modules folder to another location (like modules-intel)
adjust the xorg.conf to use this folder and copy the config file to something like xorg.conf-intel
install some window manager like awesome and start it to test graphics
reboot with syslinux
install nvidia driver (e.g. nvidia340xx)
again copy the modules folder to something like modules-nvidia, adjust the xorg.conf file and copy it to xorg.conf-nvidia

There are now two xorg.config files for intel and nvidia GPUs and two bootloaders using different GPUs.
Boot with syslinux and use xorg.conf-nvidia to use nvidia with proprietary driver and
boot with grub and use xorg.conf-intel to us the intel graphic chip

Neither an elegant solution nor a very robust one...but it works for me.

A few comments:

I could not make the gnome-shell working with the intel chip (performance?), but it works with nvidia.
After reboot with different reboot you need to adjust the copy the correct xorg.conf file. Maybe its possible to do this somehow automatically with lightDM.

I hope this helps and please post if you make any improvement on this.

fumfi · 2015-04-24 21:30:09

Hi guys,

I have found a working solution to boot my Macbook Pro 7.1 (mid-2010) in EFI mode with Nvidia drivers. SERIOUSLY!

Please review my article including Xorg.0.log and the solution. Enjoy a little taste of AHCI and Powermizer as well as brightness controls...

Feedback appreciated

best regards,
Andreas

hungerfish · 2015-04-26 09:09:17

Hi,
yesterday I tried following along, I created a script with the setpci commands (coincidently our bus identifiers match) and just had systemd load it during boot.
When I check with setpci, the values are what they should be, however I'm still just getting the blackscreen

Before I go and install grub (which I really would like to avoid) do you know how/when grub actually executes its scripts and if this could actually make a difference? From what I understand it uses the os's 'setpci' command just like my shell script does...
I also noticed that after disabling the execution of my script and just booting in efi-mode, the values are still 'correct' when checking with setpci. How can that be? I 'coldbooted' and rebooted to osx and tried again and the values never changed!?

EDIT:
Ok, I went ahead and installed grub and I can confirm that fumfi's trick actually works!
I would still like to know if grub is really needed here though...

Anyway , congratulations for finding this, I'll play around with this a bit more to see if everything works proper, but I think this really does call for a celebration!!
Thanks for pointing this out fumfi!!

Last edited by hungerfish (2015-04-26 09:48:03)

fumfi · 2015-04-26 10:24:14

hungerfish wrote:

I also noticed that after disabling the execution of my script and just booting in efi-mode, the values are still 'correct' when checking with setpci. How can that be? I 'coldbooted' and rebooted to osx and tried again and the values never changed!?
EDIT:
Ok, I went ahead and installed grub and I can confirm that fumfi's trick actually works!
I would still like to know if grub is really needed here though...
Anyway , congratulations for finding this, I'll play around with this a bit more to see if everything works proper, but I think this really does call for a celebration!!
Thanks for pointing this out fumfi!!

Great!!! Just gave it some more tries after your message.

I can confirm that the PCI register values are always set to my values regardless of whether the setpci commands get executed or not. I can only assume that somehow setting the registers explicitly, the bridge and/or VGA card get reset. Don't know about the internals of those registers, though....

Regarding your first tries with doing this using a systemd script during boot, I see a possible explanation that you could try to confirm. My suspicion is that udev loads the nvidia module before your script gets executed and somehow fails to initialize whatever it is trying to do which essentialy leads to black screen during X startup. And that is the major difference to my GRUB approach. GRUB loads and executes the setpci commands before the kernel (GRUB uses an internal setpci module rather than calling the OS tool). My script in /etc/grub.d is btw not explicitly executed during boot, but rather embedded into /boot/grub/grub.cfg by update-grub...

So from my point of view, GRUB is essential here unless you use an EFI shell to boot. If you use an EFI shell, you could also set the PCI registers using the mm command in a startup.nsh script which later boots linux. That's actually the approach the MacRumors forum guys are using.

Anyway, glad you could confirm my trick works.

One odd issue that I'm having, though, is that in EFI mode, wireless works only after closing and reopening the lid (triggering suspend to RAM and wake up, which works like a charm btw). I have tried both, b43 and bcmwl-kernel-source Ubuntu drivers, makes no difference. Anybody got a clue?

Best,
Andreas

Last edited by fumfi (2015-04-26 11:11:08)

hungerfish · 2015-04-26 13:13:07

So, after messing around some more, I can also confirm the wireless's strange behaviour. Like you said, closing the lid and resuming makes it work...
I found that if you remove the b43 module (haven't tried bcmwl yet) and then reload it via modprobe, the wireless starts to work (I can get it to show a list of available networks), but it fails to connect to anything and spams dmesg.

b43-phy0 ERROR: Fatal DMA error: ....

This would be the first issue with 'native-efi' mode.

The second for me is that I can no longer get the display-backlight to work. I have the "EnableBrightnessControl=1" in my xorg conf, and it still works fine when booting in csm-mode, but apparently the /sys/class/backlight interface never gets created when in efi-mode. I suspect that this relates to the following,

Third issue, which is the missing text-console. I'm seeing the 'famous'

NVRM: Your system is not currently configured to drive a VGA console...

message in dmesg and switching to a tty away from Xorg just gives me a black screen. I do see bootmessages before Xorg loads though, and dmesg reports efifb being loaded..

How did you get the backlight working? Does the tty console work for you?

fumfi · 2015-04-26 22:47:47

I am using the Broadcom STA drivers which work fine (after closing and reopening the lid, for once, as said above). The brightness controls I have enabled with the following config file (I have no /etc/X11/xorg.conf at all....). Note that the option itself is called "RegistryDwords".

~$ cat /usr/share/X11/xorg.conf.d/10-nvidia.conf 
Section "Device"
    Identifier     "Device0"
    Driver         "nvidia"
    VendorName     "NVIDIA Corporation"
    BoardName      "GeForce 320M"
    Option         "RegistryDwords" "EnableBrightnessControl=1"
    Option         "NoLogo"
EndSection

And regarding the framebuffer console... I have temporarily managed to get it working by blacklisting the nvidia module. So it doesn't get loaded during boot, but only upon start of X. Then one can normally switch with CTRL+ALT+Fx to a text console. *BUT*.... after blacklisting the module, the machine doesn't re-enable the display after suspending to RAM. So it kind of conflicts with the wifi workaround.

hungerfish · 2015-04-27 19:36:46

Strange, I have exactly the same file in my /etc/X11/xorg.conf.d/. Brightness controls do not work for me.
Could you please check your /sys/class/backlight & /sys/devices/virtual/backlight interfaces!?
To get the backlight controls back, I had to install nvidia-bl package from aur, which doesn't work as smoothly, but at least works.. still I'd like this to work 'generically' and I atm. don't understand why this works for you and not for me!

I tried your workaround for the framebuffer, and it did not work for me, but as you've said it isn't really an option anyway.. I guess I can live without the text tty's and it seems unrelated to the backlight issue... but the wireless bug is annoying. I'll look into it some more...

Anything to get away from csm-mode

fumfi · 2015-04-27 20:32:46

hungerfish wrote:

Could you please check your /sys/class/backlight & /sys/devices/virtual/backlight interfaces!?

/sys/class/backlight exists, but is empty. /sys/devices/virtual/backlight doesn't even exist.

Maybe Fn handling of the hid_apple module has something to do with your issues. My fnmode option is set to 1.

~# cat /sys/module/hid_apple/parameters/fnmode 
1

Also, there is a module option equivalent to the xorg.conf option. On my machine it didn't have any effect to set this to the following, but maybe it helps in your case. UPDATE: it works when using the real module name (not the nvidia alias). So either set the module option or include the RegistryDwords option into your xorg.conf.

echo options nvidia_340 NVreg_RegistryDwords="EnableBrightnessControl=1" > /etc/modprobe.d/nvidia-options.conf

Btw, I'm on kernel 3.19 using nvidia drivers version 340. Note that by Ubuntu default, on my machine, specifically modules applesmc and apple_bl are loaded which might also make a difference in behaviour.

~# lsmod | egrep "(nv|apple|mac)"
nvidia              10559488  51 
applesmc               20480  0 
input_polldev          16384  1 applesmc
drm                   344064  3 nvidia
hid_appleir            16384  0 
mac_hid                16384  0 
apple_bl               16384  0 
hid_apple              16384  0 
hid                   110592  4 hid_generic,usbhid,hid_appleir,hid_apple

Last edited by fumfi (2015-04-27 21:18:38)

hungerfish · 2015-04-27 21:27:12

Ok, I was assuming you were also using Arch
If your '/sys/...backlight' folders are empty, how is the backlight controlled? Do you use pommed, or a desktop-environment such as gnome/kde?

When in csm-mode I can either manually set values the /sys/-interface for backlight control or use pommed/gnome/kde. I think pommed also uses the sys-interface, not sure about gnome/kde.
For whatever reason none of this currently works when in efi mode...using the nvidia-bl packages (which adds a new module by the same name to the system) gives me back said interface.

The modules you mention are all present and accounted for on my system. fn mode is also as you've specified (and works fine in csm-mode)
I'll try the nvidia module option next! Sadly it doesn't seem to make a difference

Last edited by hungerfish (2015-04-27 21:53:21)

hungerfish · 2015-04-28 14:15:52

So I've done some more testing and sadly still have no satisfactory solution for the backlight controls.
By default, the apple_bl module handles the backlight controls and this works fine in csm-mode.
When booting in efi-mode however, apple_bl loads but doesn't work. No interface for /sys/class/backlight gets created. It should be /sys/class/backlight/apple_backlight.

By using either nvidia-bl or nvidiabl packages in aur which each provide their own kernel-module for backlight control I can get an interface at /sys/class/backlight/nvidia_backlight,
but both seem to be afflicted by a rather strange bug.
When starting certain apps (firefox, thunderbird, ...) or switching to fullscreen mode (flashplayer, vlc) the backlight's brightness gets reset to its maximum value.
This happens both in efi- and csm-mode when using nvidiabl or nvidia-bl. After doing some digging, it seems that this is a known bug, but I have not found any kind of workaround for it. This of course does not happen when using apple_bl in csm-mode.

So from where I'm standing, apple_bl is broken in efi mode for the mbp7.1/geforce 320m case. From Linux/drivers/video/backlight/apple_bl.c:

/* Check that the hardware responds - this may not work under EFI */

And at least in my case this seems to be true

@fumfi
Could you perhaps investigate a little further how it is that backlight controls work for you. You said that you don't get the /sys/class/backlight interface, if that is the case I am at a loss as to how it can work for you.
Maybe you could provide the complete output of lsmod, kernel version or anything else that comes to mind?!

fumfi · 2015-04-28 14:58:44

hungerfish wrote:

@fumfi
Could you perhaps investigate a little further how it is that backlight controls work for you. You said that you don't get the /sys/class/backlight interface, if that is the case I am at a loss as to how it can work for you.
Maybe you could provide the complete output of lsmod, kernel version or anything else that comes to mind?!

I will not have access to my machine for the rest of the week, but I try to assist with the results of a quick search. As you have noticed, I am on Ubuntu using Unity/GNOME. Anyhow, after having found my trick, I wanted to give back to the Linux community by posting to several actively discussing threads on that EFI issue with nvidia drivers.

Presumably, according to this bug report gnome-settings-daemon handles backlight, to be more specific gsd-backlight-helper. That bug report also confirms that apple_bl has always been broken in EFI mode. So that helper tool obviously uses an alternate approach other than the sysfs interface that I am not aware of. Maybe it's even the setpci call that I linked to (comment #9).

For the remaining details that you asked for I have to ask for your patience.

hungerfish · 2015-04-28 15:13:05

For the remaining details that you asked for I have to ask for your patience.

Will do, in the mean time, I'll fiddle a bit more

Arch Linux

#26 2013-05-09 16:59:19

Re: Macbook Pro 7.1 (mid 2010), nvidia blob,efi and hybrid mbr,gpt

#27 2013-05-11 11:19:39

Re: Macbook Pro 7.1 (mid 2010), nvidia blob,efi and hybrid mbr,gpt

#28 2013-05-24 15:47:55

Re: Macbook Pro 7.1 (mid 2010), nvidia blob,efi and hybrid mbr,gpt

#29 2013-05-24 17:43:57

Re: Macbook Pro 7.1 (mid 2010), nvidia blob,efi and hybrid mbr,gpt

#30 2013-05-26 09:10:46

Re: Macbook Pro 7.1 (mid 2010), nvidia blob,efi and hybrid mbr,gpt

#31 2013-05-26 11:31:33

Re: Macbook Pro 7.1 (mid 2010), nvidia blob,efi and hybrid mbr,gpt

#32 2013-06-06 10:39:13

Re: Macbook Pro 7.1 (mid 2010), nvidia blob,efi and hybrid mbr,gpt

#33 2013-11-20 12:01:26

Re: Macbook Pro 7.1 (mid 2010), nvidia blob,efi and hybrid mbr,gpt

#34 2013-11-21 19:57:19

Re: Macbook Pro 7.1 (mid 2010), nvidia blob,efi and hybrid mbr,gpt

#35 2013-11-22 16:22:58

Re: Macbook Pro 7.1 (mid 2010), nvidia blob,efi and hybrid mbr,gpt

#36 2014-03-08 19:37:18

Re: Macbook Pro 7.1 (mid 2010), nvidia blob,efi and hybrid mbr,gpt

#37 2014-04-01 06:52:39

Re: Macbook Pro 7.1 (mid 2010), nvidia blob,efi and hybrid mbr,gpt

#38 2014-09-02 03:43:46

Re: Macbook Pro 7.1 (mid 2010), nvidia blob,efi and hybrid mbr,gpt

#39 2015-01-03 12:14:49

Re: Macbook Pro 7.1 (mid 2010), nvidia blob,efi and hybrid mbr,gpt

#40 2015-04-24 21:30:09

Re: Macbook Pro 7.1 (mid 2010), nvidia blob,efi and hybrid mbr,gpt

#41 2015-04-26 09:09:17

Re: Macbook Pro 7.1 (mid 2010), nvidia blob,efi and hybrid mbr,gpt

#42 2015-04-26 10:24:14

Re: Macbook Pro 7.1 (mid 2010), nvidia blob,efi and hybrid mbr,gpt

#43 2015-04-26 13:13:07

Re: Macbook Pro 7.1 (mid 2010), nvidia blob,efi and hybrid mbr,gpt

#44 2015-04-26 22:47:47

Re: Macbook Pro 7.1 (mid 2010), nvidia blob,efi and hybrid mbr,gpt

#45 2015-04-27 19:36:46

Re: Macbook Pro 7.1 (mid 2010), nvidia blob,efi and hybrid mbr,gpt

#46 2015-04-27 20:32:46

Re: Macbook Pro 7.1 (mid 2010), nvidia blob,efi and hybrid mbr,gpt

#47 2015-04-27 21:27:12

Re: Macbook Pro 7.1 (mid 2010), nvidia blob,efi and hybrid mbr,gpt

#48 2015-04-28 14:15:52

Re: Macbook Pro 7.1 (mid 2010), nvidia blob,efi and hybrid mbr,gpt

#49 2015-04-28 14:58:44

Re: Macbook Pro 7.1 (mid 2010), nvidia blob,efi and hybrid mbr,gpt

#50 2015-04-28 15:13:05

Re: Macbook Pro 7.1 (mid 2010), nvidia blob,efi and hybrid mbr,gpt

Board footer