hybrid-graphics-linux team mailing list archive
-
hybrid-graphics-linux team
-
Mailing list archive
-
Message #02165
Re: Macbook Pro graphics switching
Hi Peter,
I blacklisted both nvidia and nouveau during boot and did exactly these eight steps. I used dd to save the config space, if that is of any importance (e.g. "dd if=/sys/bus/pci/devices/0000:01:00.0/config of=7-restored").
Because I'm not sure wether the pci_save/restore_state functions work I did the test twice. You can find the results for the run with pci_save/restore_state at http://andreas.meetr.de/nouveau/pcs/ and the one without at http://andreas.meetr.de/nouveau/pcs-2.
Both lead to the same result, the vbios is not accessible. http://andreas.meetr.de/nouveau/nouveau.dmesg shows how a normal boot with nouveau looks like.
Cheers,
Andreas
Am 08.03.2012 um 21:31 schrieb Lekensteyn:
> Hi Andreas,
>
> What about nouveau? The blob sometimes do not get completely unloaded (/dev/nvidia* devices then still
> exist).
>
> What if the following steps are followed:
>
> 1. ensure that the blob has not been loaded (reboot if necessary)
> 2. unload nouveau if necessary
> 3. save pci configuration space
> 4. disable card
> 5. save pci configuration space, it should be all 1's (ff in xxd)
> 6. enable card
> 7. save pci configuration space, it should be similar to (3)
> 8. load the nouveau driver, does it work?
>
> Regards,
> Peter
>
> On Thu, Mar 8, 2012 at 7:17 PM, Andreas Heider <andreas@xxxxxxxx> wrote:
> Hi Peter,
>
> I'm already saving the pci configuration space with pci_save/restore_state and I've also tried manually changing it through /sys/bus/pci/..., but I still have the problem that the blob can't load the vbios.
>
> I've uploaded dumps of it, maybe you can spot something thats obviously wrong with it:
> 1. After boot: http://andreas.meetr.de/gmux/nv.config
> 2. After one powercycle: http://andreas.meetr.de/gmux/nv.bad.config
> 3. After one powercycle and copying the first config space back: http://andreas.meetr.de/gmux/nv.bad.config_restored
>
> Unfortunately this still gives me the NVRM: RmInitAdapter failed! (0x30:0xffffffff:858) error.
>
> Thanks,
> Andreas
>
>
> Am 08.03.2012 um 12:38 schrieb Lekensteyn:
>
>> Hi Andreas,
>>
>> I've documented about the PCI configuration space issue on
>> http://wiki.bumblebee-project.org/ACPI-for-Developers. Bumblebee also saves
>> and restores the PCI configuration space before enabling/after disabling.
>>
>> Regards,
>> Peter
>>
>> On Thu, Mar 8, 2012 at 2:47 AM, Andreas Heider <andreas@xxxxxxxx> wrote:
>> Hi everyone,
>>
>> I'll just continue using this mailing list as a blog. After a lot of
>> wild guesses in all directions I now have a setup that could be a base
>> for useful graphics switching on Macbook Pros. It's not completely
>> reliable yet but hopefully that will improve in the future.
>>
>> Switching between two running GPUs works pretty well and just needs a
>> bit more work. But that shouldn't be a big issue.
>>
>> The main problem I fought with is that after powering down the external
>> GPU the vbios vanishes and it's impossible to load the proprietary
>> nvidia driver:
>>
>> [ 214.505208] NVRM: failed to copy vbios to system memory.
>> [ 214.507347] NVRM: RmInitAdapter failed! (0x30:0xffffffff:858)
>> [ 214.507357] NVRM: rm_init_adapter(0) failed
>>
>> The same problem exists with nouveau, after the first power cycle
>> nouveau doesn't load again if I unload it. I guess this is actually a
>> BIOS/EFI/firmware bug, since Apple's switching driver just keeps the
>> driver loaded.
>>
>> So it's necessary to load the driver once and keep it loaded. This works
>> well with nouveau+vga_switcheroo but is a bit problematic with the
>> blob.
>>
>> At the moment I have the blob running with the patch from my first mail
>> and noticed that it survives a powercycle if X _is_ loaded while the GPU
>> is powered down. If I shutdown X I get this error when I try to start it
>> again afterwards:
>>
>> [ 144.390920] NVRM: RmInitAdapter failed! (0x26:0xffffffff:1170)
>> [ 144.390930] NVRM: rm_init_adapter(0) failed
>>
>> I'm not 100% certain that this really works but at the moment it's the
>> only possibility for getting full switching support with the blob.
>>
>> Speaking of nvidia bugs, I also had problems with the blob not reliably
>> loading when I boot with EFI.
>> Luckily it's possible to also enable the integrated card in BIOS
>> emulation mode. After staring a lot at the output of lspci -xxx from
>> both EFI and BIOS boot I noticed that this just requires flipping one
>> bit in the pci configuration space. This can be done by adding "setpci
>> -d 8086:0044 54.b=0b" in grub. This value will most likely only work for
>> this exact model, a MBP 6,2. For more information see
>> http://download.intel.com/design/processor/datashts/322813.pdf page 62.
>>
>> If anyone has some hints how to better deal with the blob that would be
>> greatly appreciated.
>>
>> On Wed, 2012-02-29 at 10:33 +0100, Lekensteyn wrote:
>> > Hi Andreas,
>> >
>> > I'm using nouveau + bbswitch (switcheroo also works, but not after
>> > resume), not on
>> > a mac, but a Clevo B7130 (branded as "BTO P-BOOK 17CL34").
>> >
>> > The restoration of the PCI configuration space is a hack to allow the
>> > driver to load
>> > in case it was accidentally loaded while the card was off. This is
>> > especially necessary
>> > for the nvidia blob driver which loads itself if you try to
>> > access /dev/nvidia* devices.
>> >
>> > In the case of switcheroo, no driver is attempted to be unloaded (see
>> > the second field
>> > of the switching_method struct and line 30 of src/switch/switching.c.
>>
>> Sorry, that was my fault. I changed that for testing purposes and then
>> forgot about it.
>>
>> >
>> > gmux can be integrated into BB. Writing a new switcher module
>> > (src/switch/gmux.c)
>> > which also takes care of loading the switcheroo module (only if that
>> > is a safe operation!)
>> > should do the trick. Just be careful not to conflict with switcheroo.
>> > The other way is leave
>> > BB as it and require users to load gmux before BB.
>>
>> Because of vbios situation and nouveau already working pretty well with
>> switcheroo I'd prefer to keep using that.
>> >
>> > Regards,
>> > Peter
>>
>> Cheers,
>> Andreas
>>
>> >
>> > On Wed, Feb 29, 2012 at 12:25 AM, Andreas Heider <andreas@xxxxxxxx>
>> > wrote:
>> > Hi Peter,
>> >
>> > I took another look at bumblebee today and got it running with
>> > nouveau!
>> > Bumblebee automatically powers the nvidia card down when it's
>> > not in
>> > use and starting programs with optirun works well.
>> >
>> > This required a dirty hack to bumblebee which you can find
>> > here:
>> > https://github.com/ah-/Bumblebee/commit/c5ab6f0e7f841045cee6905bb367c79091b0eb6b
>> >
>> > The problem is that bumblebee wants to save/restore the pci
>> > configuration
>> > space, which is already done by nouveau. (See
>> > https://gist.github.com/1935992)
>> >
>> > It also shouldn't try to unload the driver.
>> >
>> > Do you think this could somehow be integrated into bumblebee?
>> >
>> > Cheers,
>> > Andreas
>> >
>> > On Tue, 2012-02-28 at 16:14 +0100, Lekensteyn wrote:
>> > > Hi Andreas,
>> > >
>> > > vga_switcheroo is a supported method since Bumblebee 3.0,
>> > but I
>> > > assumed that
>> > > it would not be used for the nvidia driver. If you wish to
>> > use the
>> > > nvidia blob with
>> > > switcheroo, you have to recompile Bumblebee and apply commit
>> > > 85636d1f21b0644e7dd47e3931479860c55b7a05 (or use the develop
>> > branch).
>> > > The
>> > > next version will have this change too.
>> > >
>> > > One shortcoming of vga_switcheroo now is that the state is
>> > messed up
>> > > after
>> > > suspend: switcheroo remembered that the card was off, but in
>> > reality
>> > > the card
>> > > is on. The module bbswitch worked around this by enabling
>> > the card
>> > > before
>> > > suspend and disabling the card on resume.
>> > >
>> > > In some cases, while the card was turned off with switcheroo
>> > caused
>> > > the machine
>> > > to lock when the card is tried to be accessed. If switcheroo
>> > is not an
>> > > option for
>> > > Bumblebee, you can write your own switching code. See the
>> > src/switch/
>> > > directory
>> > > for examples.
>> > >
>> > > Regards,
>> > > Peter
>> > > (Bumblebee and bbswitch developer)
>> > >
>> > > On Tue, Feb 28, 2012 at 3:16 PM, Andreas Heider
>> > <andreas@xxxxxxxx>
>> > > wrote:
>> > > Hello everybody,
>> > >
>> > > I'm developing a vga_switcheroo driver for the Apple
>> > Macbook
>> > > Pro models
>> > > with switchable graphics and have a few questions
>> > about how to
>> > > integrate
>> > > it with the current linux hybrid graphics
>> > infrastructure.
>> > >
>> > >
>> > > Apple implemented the switching using a "chip"
>> > dubbed the
>> > > "gmux" (probably short for graphics multiplexer or
>> > something
>> > > similar).
>> > > The gmux can power down the external graphics card,
>> > switch the
>> > > DDC,
>> > > internal and external display connections
>> > (individually)
>> > > between both
>> > > cards and set the backlight brightness. Unlike most
>> > newer
>> > > laptops with
>> > > hybrid graphics, Apple's Macbook Pros use a physical
>> > mux.
>> > >
>> > > Luckily the gmux has remained mostly the same
>> > between all
>> > > models with
>> > > switchable graphics, so it should be possible to
>> > develop one
>> > > driver that
>> > > supports all of them.
>> > >
>> > >
>> > > This driver has actually been lying around in
>> > unfinished state
>> > > for some
>> > > time now, until Seth Forshee from Canonical recently
>> > rewrote
>> > > it into a
>> > > clean, backlight-only driver that will hopefully
>> > find it's way
>> > > into
>> > > mainline soon.
>> > >
>> > > My goal is to use Seth's work as a base and add the
>> > other
>> > > features back
>> > > again and make it work well. A first version is
>> > already
>> > > working and up
>> > > at https://github.com/ah-/gmux
>> > >
>> > > This driver supports all vga_switcheroo operations
>> > (discrete
>> > > power
>> > > on/off, display switching) and they all work on my
>> > MBP 6,2
>> > > using the
>> > > intel and nouveau drivers.
>> > >
>> > > But unfortunately, it doesn't work with bumbleebee
>> > and/or the
>> > > proprietary
>> > > nvidia driver yet.
>> > >
>> > >
>> > > Because I'm using CUDA in other projects, getting
>> > the
>> > > proprietary NVIDIA
>> > > driver running well is very interesting to me. The
>> > setup
>> > > bumblebee plus
>> > > intel + nvidia_current without power management
>> > works well on
>> > > my laptop
>> > > if I switch to the intel card in grub. (It's just
>> > three
>> > > outbs). But that
>> > > breaks suspend and uses 10W more power than
>> > necessary.
>> > >
>> > > Does/should bumblebee work with a vga_switcheroo
>> > driver just
>> > > for ON/OFF?
>> > >
>> > > One thing I stumbled upon is a patch for the
>> > proprietary
>> > > NVIDIA
>> > > driver originally written by "Kayo
>> > <kayo@xxxxxxxxxxxx>" which
>> > > adds
>> > > some kind of vga_switcheroo support to it. I
>> > modified it to
>> > > just register
>> > > with switcheroo (patch is attached), and that part
>> > works well.
>> > > Turning
>> > > off the card works, but turning it on afterwards
>> > doesn't. Any
>> > > Ideas?
>> > >
>> > >
>> > > Ultimately I'd like to get two scenarios/workflows
>> > to work
>> > > well:
>> > >
>> > > 1. Real switching, by disabling one card completely
>> > and only
>> > > using
>> > > the other one, requiring a logout/login.
>> > > Preferably using the NVIDIA driver.
>> > >
>> > > 2. Bumblebee switching with working power management
>> > when the
>> > > NVIDIA
>> > > GPU is not in usw.
>> > >
>> > >
>> > > I'd appreciate any comments and thoughts on how to
>> > implement
>> > > this and
>> > > how to integrate it with the current hybrid graphics
>> > > environment.
>> > >
>> > > Cheers,
>> > > Andreas
>> > >
>> > > _______________________________________________
>> > > Mailing list:
>> > https://launchpad.net/~hybrid-graphics-linux
>> > > Post to :
>> > hybrid-graphics-linux@xxxxxxxxxxxxxxxxxxx
>> > > Unsubscribe :
>> > https://launchpad.net/~hybrid-graphics-linux
>> > > More help : https://help.launchpad.net/ListHelp
>> > >
>> > >
>> >
>> >
>> >
>> >
>> >
>>
>>
>>
>
>
Follow ups
References
