Closed snaggen closed 7 years ago
It's a Fedora packaging bug, sorry.
Not sure that is is. I run the latest packages that should have this fixed. Now I notice that I don't have a /sys/kernel/debug/vgaswitcheroo directory... lsmod shows the radeon driver is loaded. Shouldn't that support switcheroo? Or how does it work?
Not sure that is is. I run the latest packages that should have this fixed.
You still need to enable the service by hand, as mentioned in the bug.
Now I notice that I don't have a /sys/kernel/debug/vgaswitcheroo directory...
Then that means that the hardware doesn't support switcheroo, or the kernel doesn't support it, or you tried to access it as a normal user, or it's not mounted...
lsmod shows the radeon driver is loaded. Shouldn't that support switcheroo? Or how does it work?
It's possible this hardware doesn't have support for switcheroo at all.
Best off hitting the kernel mailing-lists.
I have debugfs mounted and there wasn't permission problems. So most likely it is not supported by the driver. Anyway, seems like this is not the correct place. Thanks for answering my questions.
The switch
file only shows up in debugfs once apple-gmux, i915 and radeon have loaded. (I think amdgpu now also supports GCN1.0 chips, so amdgpu can probably be used alternatively to radeon.)
On 2013+ MBPs (such as yours) the Intel GPU is powered down by EFI unless the OS identifies as macOS using a custom protocol. In that case i915 can't find the device and won't load, and consequently the switch
file won't show up in debugfs. See here for available solutions.
Thanks for the pointer, https://github.com/0xbb/apple_set_os.efi got this working for me. I then got both GPUs up and running. However, for some reason having the Haswell gpu enabled made Fedora force X11 session, and having switcheroo-control enabled also caused the performance to be horrible. So, there seems to be some issues left to investigate. But thanks for helping out to get this far.
As for performance, on the MBP11,3 an interrupt storm occurs on GPE 0x06 as soon as i915 is loaded. Does this occur on your MBP11,5 as well? Does /sys/bus/acpi/interrupts/gpe06
show high and continuously growing numbers? Does performance improve if you echo disable
to that file? The issue is tracked with this bugzilla entry, feel free to add information on your machine there: https://bugs.freedesktop.org/show_bug.cgi?id=98501
I created a systemd service that run echo disable to /sys/firmware/acpi/interrupts/gpe06 but that did not affect the performance at all. I also verified by cat:ing the file, and it did indeed say disabled. cat on the /sys/firmware/acpi/interrupts/gpe_all doesn't show anything out of the ordinary... so I guess it might not be the interrupt flooding issue... even if it fits the symptoms so close...
Performance aside it would be helpful to know if the MBP11,5 is affected by the interrupt storm as well. If you don't disable GPE 0x06 and call cat /sys/firmware/acpi/interrupts/summary
, do you see this or any other GPE generating an unusually high number of interrupts?
Also, powertop
might help in debugging the performance issue.
I have a MacBook Pro (Retina, 15-inch, Mid 2015) 2.5 GHz with a AMD Radeon R9 M370X, https://support.apple.com/kb/sp719?locale=en_US
I run Fedora 25 Beta with the swicharoo-control installed. However, the swicharoo-control doesn't seem to run after boot. And the Details window show "Gallium 0.4 on AMD CAPE VERDE (DRM 2.46.0 / 4.8.6-300.fc25.x86_64, LLVM 3.8.0)"
Is it supposed to be able to handle this at all? Is there something I can do to help you to debug it, if it is supposed to be possible to get it up and running?