Bug 119131
| Summary: | amd64 kernel hangs during EFI boot on MacPro 1,1 | ||
|---|---|---|---|
| Product: | EFI | Reporter: | Sergey Menshikov (sergey.menshikov) |
| Component: | Boot | Assignee: | EFI Virtual User (efi) |
| Status: | RESOLVED WILL_NOT_FIX | ||
| Severity: | normal | CC: | ardb, efi, matt, micahbroth, myhateisblind |
| Priority: | P1 | ||
| Hardware: | x86-64 | ||
| OS: | Linux | ||
| Kernel Version: | 3.19.1+ | Subsystem: | |
| Regression: | Yes | Bisected commit-id: | |
| Attachments: | skip SetVirtualAddressMap() | ||
|
Description
Sergey Menshikov
2016-05-26 15:25:20 UTC
Could you try reverting the suspected commit on top of 3.19.1 and see whether that results in a booting kernel? That will at least prove/disprove your hypothesis. Good idea, will do. Meanwhile the workaround seems to be to use "noefi" kernel parameter at boot. I've built 2 kernels using Ubuntu .config : 3.19.1 as is and 3.19.1 with "Avoid triple faults during EFI mixed mode calls" patch reverted. "as is" 3.19.1 kernel does not boot without noefi parameter 3.19.1 compiled with the patch reverted boots just fine. Created attachment 219991 [details]
skip SetVirtualAddressMap()
Could you try applying the attached patch to 3.19.1 and see if your machine boots or at least if you get *some* output on the screen. There have been reports that some Macbooks do not like it when EFI services are accessed via the 1:1 mapping that we setup, and it's possible that that is the issue here. The attached patch skips the call to SetVirtualAddressMap() when in mixed mode. I tested the patch and it works. I booted: * 3.19.1 stock with skip SetVirtualAddressMap() patch only and it worked * for control - 3.19.1 stock, and it did not work, as expected * for control - 3.19.1 with efi patch reverted, and it worked, as expected sorry it took a while This problem used to be avoidable with the kernel command line option "noefi", but this is no longer working reliably since 4.9 Problem persists with kernels 4.13 and 4.14 Problem persists with kernel 4.15 macpro1,1 with original firmware and SMC coding, upgraded processors from macpro2,1 (dual qc 3.0ghz procs) - don't think any of that matters, but just so you know what i'm running this on the noefi kernel parameter is working for me. tested a debian 9 multiarch installer, elementary 5 standard installer with 32bit bootia32.efi added to /efi/boot/ folder, and now running happily on kubuntu 18.04 prepared and installed the same way; i just had to add the noefi perameter to the kernel line. i'm pretty stoked this is working now, have been posting in various places for guidance on how to pull out what might have been happening for a while now. i might have spoken too soon. i had an existing install of kubuntu that was able to boot using the noefi option, but now i can't get anything to finish installing, failing on grub-install with an error: "grub-installer: EFI variables are not supported on this system." installing ubuntu 14.04 worked first time, now going through upgrades to see if the noefi parameter works on later kernel versions for me. dist upgrade to 18.04 worked fine starting from 14.04 *or* 16.04, and i have a bootable 18.04 w/kernel 4.15 by passing the noefi option or the noexec=off option. dist upgrade from 16.04 to 18.04 printed the same errors but since it's not also crashing the installer, the upgrade completes successfully and end up with a system that just needs one of the parameters passed. |