Bug 119131 - amd64 kernel hangs during EFI boot on MacPro 1,1
Summary: amd64 kernel hangs during EFI boot on MacPro 1,1
Status: RESOLVED WILL_NOT_FIX
Alias: None
Product: EFI
Classification: Unclassified
Component: Boot (show other bugs)
Hardware: x86-64 Linux
: P1 normal
Assignee: EFI Virtual User
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2016-05-26 15:25 UTC by Sergey Menshikov
Modified: 2023-12-21 14:13 UTC (History)
5 users (show)

See Also:
Kernel Version: 3.19.1+
Subsystem:
Regression: Yes
Bisected commit-id:


Attachments
skip SetVirtualAddressMap() (381 bytes, patch)
2016-06-14 15:26 UTC, Matt Fleming
Details | Diff

Description Sergey Menshikov 2016-05-26 15:25:20 UTC
amd64 kernels starting with 3.19.1 do not boot on Apple MacPro 1,1 with EFI32 (mixed-mode EFI)

Everything up to 3.19.0 is bootable (tested several kernels from 2.6.31 to 4.5.1)

Attempt to boot results in no messages from kernel or any other activity after [bzImage xxx] and fakebios-related lines.

Steps to reproduce:

* USB Stick formatted with GPT, bootable flag set
* Extract contents of http://blog.christophersmart.com/2009/12/22/updated-efi-grub2-tarball-including-64bit/ - GRUB with bootia32.efi and several netinstall kernels
* use the following line in grub.cfg to exclude any initrd influence:

menuentry "test kernel 64bit" {
   fakebios
   linux /efi/boot/linux priority=low vga=normal video=efifb noinitrd
}

Looking at 3.19.1 changelist, the suspect change in is "x86/efi: Avoid triple faults during EFI mixed mode calls"

I know MacPro 1,1 is an older machine, but it is affordable, has 4 SATA bays + 2 internal SATA ports, ECC memory, quiet fans and makes a beautiful piece of furniture as a home server.
Comment 1 Matt Fleming 2016-05-26 19:45:18 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.
Comment 2 Sergey Menshikov 2016-05-27 05:34:10 UTC
Good idea, will do. 

Meanwhile the workaround seems to be to use "noefi" kernel parameter at boot.
Comment 3 Sergey Menshikov 2016-05-28 01:52:32 UTC
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.
Comment 4 Matt Fleming 2016-06-14 15:26:29 UTC
Created attachment 219991 [details]
skip SetVirtualAddressMap()
Comment 5 Matt Fleming 2016-06-14 15:28:40 UTC
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.
Comment 6 Sergey Menshikov 2016-07-10 19:49:19 UTC
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
Comment 7 myhateisblind 2017-07-31 14:40:31 UTC
This problem used to be avoidable with the kernel command line option "noefi", but this is no longer working reliably since 4.9
Comment 8 myhateisblind 2017-11-03 17:22:15 UTC
Problem persists with kernels 4.13 and 4.14
Comment 9 myhateisblind 2018-03-24 13:57:16 UTC
Problem persists with kernel 4.15
Comment 10 ndroftheline 2018-12-19 21:19:49 UTC
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.
Comment 11 ndroftheline 2018-12-21 03:30:38 UTC
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.
Comment 12 ndroftheline 2018-12-22 19:40:51 UTC
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.

Note You need to log in before you can comment on or make changes to this bug.