[Bug 215003] New: apple_gmux fails to initialize and iGPU unclaimed on MacBook Pro 16" 2019
https://bugzilla.kernel.org/show_bug.cgi?id=215003
Bug ID: 215003 Summary: apple_gmux fails to initialize and iGPU unclaimed on MacBook Pro 16" 2019 Product: Drivers Version: 2.5 Kernel Version: 5.14.y Hardware: Intel OS: Linux Tree: Mainline Status: NEW Severity: normal Priority: P1 Component: Video(DRI - non Intel) Assignee: drivers_video-dri@kernel-bugs.osdl.org Reporter: dreifachstein@gmail.com Regression: No
MBP2019 can be tricked into booting with the iGPU enabled (https://github.com/0xbb/apple_set_os.efi) but i915 does not claim the iGPU after booting.
I have tracked down the direct cause but do not how to fix it.
When booting with the iGPU enabled `apple_gmux_present` returns true because GMUX_ACPI_HID ("APP000B") is present in the ACPI tables. Because apple_gmux fails to initialize with "Failed to find gmux I/O resource" and never registers with vgaswitcheroo the i915 probe routine always bails out after `vga_switcheroo_client_probe_defer` lefting the device unclaimed.
https://bugzilla.kernel.org/show_bug.cgi?id=215003
--- Comment #1 from Xiaolei Yu (dreifachstein@gmail.com) --- Commenting out the `vga_switcheroo_client_probe_defer` lines make the iGPU usable but gpu switching is still not working.
https://bugzilla.kernel.org/show_bug.cgi?id=215003
Lukas Wunner (lukas@wunner.de) changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |lukas@wunner.de
--- Comment #2 from Lukas Wunner (lukas@wunner.de) --- vga_switcheroo_client_probe_defer() only returns true if invoked by the *inactive* GPU's driver. (That's the "pdev != vga_default_device()" condition.) In other words, you've enabled the iGPU but it's not the *active* one. You need to use the gpu-switch utility (https://github.com/0xbb/gpu-switch) to tell the EFI BIOS that it should switch to the iGPU on next boot. That should resolve the issue.
Unfortunately we don't support GPU switching for retina MBPs in the kernel yet, hence have to rely on the EFI BIOS to do that for now. (We do support GPU switching for *pre-retina* MBPs in the kernel since early 2016.)
However, I'd like to know why apple_gmux fails to probe with "Failed to find gmux I/O resource". Could you attach an ACPI dump to this bugzilla? Thanks!
https://bugzilla.kernel.org/show_bug.cgi?id=215003
--- Comment #3 from Xiaolei Yu (dreifachstein@gmail.com) --- Created attachment 299561 --> https://bugzilla.kernel.org/attachment.cgi?id=299561&action=edit acpidump
https://bugzilla.kernel.org/show_bug.cgi?id=215003
--- Comment #4 from Xiaolei Yu (dreifachstein@gmail.com) --- gpu-switch does not work because `EFI runtime services are disabled`.
[ 0.371791] ------------[ cut here ]------------ [ 0.371822] [Firmware Bug]: Page fault caused by firmware at PA: 0xffffb6ee80068000 [ 0.371872] WARNING: CPU: 0 PID: 75 at arch/x86/platform/efi/quirks.c:734 efi_crash_gracefully_on_page_fault+0x49/0xc0 [ 0.371942] Modules linked in: [ 0.371963] CPU: 0 PID: 75 Comm: kworker/u24:4 Not tainted 5.14.17+ #9 [ 0.372006] Hardware name: Apple Inc. MacBookPro16,1/Mac-E1008331FDC96864, BIOS 1554.120.19.0.0 (iBridge: 18.16.14663.0.0,0) 05/07/2021 [ 0.372083] Workqueue: efi_rts_wq efi_call_rts [ 0.372114] RIP: 0010:efi_crash_gracefully_on_page_fault+0x49/0xc0 [ 0.372154] Code: 48 89 fd e8 09 8d 02 00 48 81 fd ff 0f 00 00 76 08 48 3d 50 a0 61 b1 74 02 5d c3 48 89 ee 48 c7 c7 40 bf 6c b0 e8 f5 22 7e 00 <0f> 0b 83 3d 7e 0e fa 01 0a 0f 84 17 1e 7e 00 e8 53 19 00 00 48 8b [ 0.372271] RSP: 0000:ffffb6ee8033ab30 EFLAGS: 00010086 [ 0.372305] RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffffffffb0cb4a08 [ 0.372350] RDX: 0000000000000000 RSI: 00000000ffffefff RDI: ffffffffb0c5ca00 [ 0.372395] RBP: ffffb6ee80068000 R08: 0000000000000000 R09: ffffb6ee8033a958 [ 0.372440] R10: ffffb6ee8033a950 R11: ffffffffb0ccca48 R12: ffffb6ee8033abc8 [ 0.374667] R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000 [ 0.376933] FS: 0000000000000000(0000) GS:ffff9fc8aea00000(0000) knlGS:0000000000000000 [ 0.379162] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 0.381422] CR2: ffffb6ee80068000 CR3: 00000001001a8006 CR4: 00000000003706f0 [ 0.383698] Call Trace: [ 0.385899] page_fault_oops+0x9c/0x240 [ 0.388141] exc_page_fault+0xcc/0x150 [ 0.390313] asm_exc_page_fault+0x1e/0x30 [ 0.392540] RIP: 0010:0xfffffffeefc440c5 [ 0.394703] Code: 31 c9 48 29 f9 48 83 e1 0f 74 0c 4c 39 c1 49 0f 47 c8 49 29 c8 f3 a4 4c 89 c1 49 83 e0 0f 48 c1 e9 04 74 2c f3 0f 7f 44 24 18 <f3> 0f 6f 06 66 0f e7 07 48 83 c6 10 48 83 c7 10 e2 ee 0f ae f0 66 [ 0.397081] RSP: 0000:ffffb6ee8033ac78 EFLAGS: 00010286 [ 0.399456] RAX: fffffffeefc921e5 RBX: ffffffffb0709ce2 RCX: 0000000000000035 [ 0.401753] RDX: ffffb6ee80067d48 RSI: ffffb6ee80067ff3 RDI: fffffffeefc92490 [ 0.404119] RBP: ffffb6ee8033ad00 R08: 000000000000000c R09: ffffb6ee8006834e [ 0.406426] R10: 0000000000000000 R11: 00000000005ef3bd R12: 0000000000000000 [ 0.408788] R13: ffffb6ee80067dd0 R14: ffffb6ee80067d01 R15: 0000000000000607 [ 0.411101] ? __efi_call+0x28/0x30 [ 0.413426] ? switch_mm_irqs_off+0x19a/0x3b0 [ 0.415753] ? efi_call_rts+0x17c/0x6c0 [ 0.418001] ? process_one_work+0x1ec/0x390 [ 0.420289] ? worker_thread+0x53/0x3e0 [ 0.422515] ? process_one_work+0x390/0x390 [ 0.424780] ? kthread+0x127/0x150 [ 0.426991] ? set_kthread_struct+0x40/0x40 [ 0.429254] ? ret_from_fork+0x22/0x30 [ 0.431488] ---[ end trace d9718208699f023a ]---
https://bugzilla.kernel.org/show_bug.cgi?id=215003
--- Comment #5 from Lukas Wunner (lukas@wunner.de) --- Hm, why are runtime services disabled? Are you using "noefi" or "efi=noruntime" on the command line or is this perhaps an RT kernel? Could you attach full dmesg output?
Looking at the ACPI dump I notice that GMUX only has an 8 byte Memory32Fixed region:
Name (_CRS, ResourceTemplate () // _CRS: Current Resource Settings { Memory32Fixed (ReadWrite, 0xFE0B0200, // Address Base 0x00000008, // Address Length ) })
On my pre-retina MacBookPro9,1 it's a 256 byte Decode16 region:
Name (_CRS, ResourceTemplate () // _CRS: Current Resource Settings { IO (Decode16, 0x0700, // Range Minimum 0x07FF, // Range Maximum 0x01, // Alignment 0xFF, // Length ) })
Apple already changed the I/O interface once when they switched to retina displays in 2012: Before, registers where accessed directly. After, registers where accessed through a mailbox interface which required 3 32-bit registers for communication. It looks like they changed the interface again, however now there's only a memory region with 8 bytes, so only 2 32-bit registers. It will be necessary to reverse-engineer the new interface (again) to get support for GMUX working on these newer machines.
https://bugzilla.kernel.org/show_bug.cgi?id=215003
--- Comment #6 from Xiaolei Yu (dreifachstein@gmail.com) --- (In reply to Lukas Wunner from comment #5)
Hm, why are runtime services disabled? Are you using "noefi" or "efi=noruntime" on the command line or is this perhaps an RT kernel? Could you attach full dmesg output?
EFI runtime service is disabled after a firmware page fault during boot. I pasted the trace in #4.
https://bugzilla.kernel.org/show_bug.cgi?id=215003
--- Comment #7 from Lukas Wunner (lukas@wunner.de) --- The gpu-switch utility I've linked to above has macOS and Windows versions. You could try using it from one of those OSes to switch to the iGPU on next boot, then boot into Linux.
Perhaps you could add a few debug printk's to find out which runtime services call causes the crash.
In summary, there are two issues here: The EFI issue which prevents you from switching to the iGPU on Linux, and the GMUX incompatibility. You may want to open a separate bug for the former and assign it to the "EFI" Product so that Ard Biesheuvel and others can take a look.
dri-devel@lists.freedesktop.org
-
bugzilla-daemon＠bugzilla.kernel.org