[MacBookPro8,1] Fails to boot without noefi since linux-image-3.13.0-20-generic

[Michael Gratton]

My MacBookPro 8,1 (Early 2011, 13") will not boot using any trusty kernel linux-image-3.13.0-20-generic or later. I get a grey rectangle displayed, centred, filling most of the screen, and the system hangs. When booting into rescue mode without kernel parameters quiet, splash, vt.redirect, etc., I would see something like:
> Loading vmlinuz-3.13.0-27-generic...
> Loading initrd.img-3.13.0-27-generic...

Then the system hangs. When I reboot I'm dropped into the GRUB menu.
To boot in EFI mode, I keep linux-image-3.13.0-19-generic around - which works fine.

WORKAROUND: Use kernel boot parameter "efi=old_map" to restore booting. The kernel parameter "noefi" works as well, however gfx and disk performance suffers, and features such as the monitor brightness keys fail to work altogether using that.

ProblemType: Bug
DistroRelease: Ubuntu 14.04
Package: linux-image-3.13.0-27-generic 3.13.0-27.50
ProcVersionSignature: Ubuntu 3.13.0-27.50-generic 3.13.11
Uname: Linux 3.13.0-27-generic x86_64
ApportVersion: 2.14.1-0ubuntu3.2
Architecture: amd64
AudioDevicesInUse:
 USER PID ACCESS COMMAND
 /dev/snd/controlC0: mjg 3074 F.... pulseaudio
CurrentDesktop: GNOME
Date: Fri May 30 13:34:24 2014
HibernationDevice: RESUME=UUID=a1bf347c-6af0-4ee2-9091-90d1cf6b93c7
InstallationDate: Installed on 2011-06-03 (1091 days ago)
InstallationMedia: Ubuntu 11.04 "Natty Narwhal" - Release amd64 (20110427.1)
MachineType: Apple Inc. MacBookPro8,1
ProcFB: 0 EFI VGA
ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-3.13.0-27-generic root=UUID=e7b2b4af-7419-44ef-a93d-9b0f59f2d002 ro recovery nomodeset noexec=off noefi
RelatedPackageVersions:
 linux-restricted-modules-3.13.0-27-generic N/A
 linux-backports-modules-3.13.0-27-generic N/A
 linux-firmware 1.127.2
SourcePackage: linux
UpgradeStatus: Upgraded to trusty on 2014-02-28 (90 days ago)
dmi.bios.date: 04/22/11
dmi.bios.vendor: Apple Inc.
dmi.bios.version: MBP81.88Z.0047.B0E.1104221557
dmi.board.asset.tag: Base Board Asset Tag#
dmi.board.name: Mac-94245B3640C91C81
dmi.board.vendor: Apple Inc.
dmi.board.version: MacBookPro8,1
dmi.chassis.type: 10
dmi.chassis.vendor: Apple Inc.
dmi.chassis.version: Mac-94245B3640C91C81
dmi.modalias: dmi:bvnAppleInc.:bvrMBP81.88Z.0047.B0E.1104221557:bd04/22/11:svnAppleInc.:pnMacBookPro8,1:pvr1.0:rvnAppleInc.:rnMac-94245B3640C91C81:rvrMacBookPro8,1:cvnAppleInc.:ct10:cvrMac-94245B3640C91C81:
dmi.product.name: MacBookPro8,1
dmi.product.version: 1.0
dmi.sys.vendor: Apple Inc.

[Brad Figg (brad-figg)]

This change was made by a bot.

[penalvch (penalvch)]

Mike Gratton, thank you for reporting this and helping make Ubuntu better. Could you please test the latest upstream kernel available (3.15-rc7) following https://wiki.ubuntu.com/KernelMainlineBuilds ? It will allow additional upstream developers to examine the issue. Once you've tested the upstream kernel, please comment on which kernel version specifically you tested. If this bug is fixed in the mainline kernel, please add the following tags:
kernel-fixed-upstream
kernel-fixed-upstream-VERSION-NUMBER

where VERSION-NUMBER is the version number of the kernel you tested. For example:
kernel-fixed-upstream-3.15-rc7

This can be done by clicking on the yellow circle with a black pencil icon next to the word Tags located at the bottom of the bug description. As well, please remove the tag:
needs-upstream-testing

If the mainline kernel does not fix this bug, please add the following tags:
kernel-bug-exists-upstream
kernel-bug-exists-upstream-VERSION-NUMBER

As well, please remove the tag:
needs-upstream-testing

Once testing of the upstream kernel is complete, please mark this bug's Status as Confirmed. Please let us know your results. Thank you for your understanding.

[Michael Gratton (mjog)]

Just tried this with 3.15-rc7, with similar effective results: The standard boot results in a kernel oops and hang, adding the noefi kernel param allows the system to get to multiuser, but in a degraded state.

Anything else I can do? Any hints on how to get that oops text without resorting to a photo?

[Michael Gratton (mjog)]

Photo of the call trace attached anyway. Top of the stack is:

efivar_init
efivar_update_sysfs_entries
kset_register
kzalloc.constprop.3
efivars_sysfs_init
leds_init
do_one_initall
etc.

[penalvch (penalvch)]

Mike Gratton, the next step is to fully commit bisect the kernel in order to identify the offending commit. Could you please do this following https://wiki.ubuntu.com/Kernel/KernelBisection ?

[Michael Gratton (mjog)]

Okay, have started bisecting. Will take a few day sat least however since this is my primary machine.

[Michael Gratton (mjog)]

Okay, git bisect says this is the first offending commit:

> dc9c3ed611922e769b1fd595f8f99a93d69c026d is the first bad commit
> commit dc9c3ed611922e769b1fd595f8f99a93d69c026d
> Author: Borislav Petkov <email address hidden>
> Date: Thu Oct 31 17:25:08 2013 +0100
>
> x86/efi: Runtime services virtual mapping
>
> BugLink: http://bugs.launchpad.net/bugs/1297658
>
> We map the EFI regions needed for runtime services non-contiguously,
> with preserved alignment on virtual addresses starting from -4G down
> for a total max space of 64G. This way, we provide for stable runtime
> services addresses across kernels so that a kexec'd kernel can still use
> them.
>
> Thus, they're mapped in a separate pagetable so that we don't pollute
> the kernel namespace.
>
> Add an efi= kernel command line parameter for passing miscellaneous
> options and chicken bits from the command line.
>
> While at it, add a chicken bit called "efi=old_map" which can be used as
> a fallback to the old runtime services mapping method in case there's
> some b0rkage with a particular EFI implementation (haha, it is hard to
> hold up the sarcasm here...).
>
> Also, add the UEFI RT VA space to Documentation/x86/x86_64/mm.txt.
>
> Signed-off-by: Borislav Petkov <email address hidden>
> Signed-off-by: Matt Fleming <email address hidden>
> (cherry picked from commit d2f7cbe7b26a74dbbbf8f325b2a6fd01bc34032c)
> Signed-off-by: Tim Gardner <email address hidden>
>
> :040000 040000 52f7a3e427111f66f65fcb67b1d010cee7e5121f 1200735ebee4c3272d1e3eedfc00c7150d17e276 M Documentation
> :040000 040000 21376a74b6a2dc5dbe5b581677830b90bec72e49 95678fbb2d7178afb7866daf706dd7706d8da7e6 M arch
> :040000 040000 bf1515bb7d32745424abf75d8ce58340f482e88c 59013df8e2ea1c112d96b982105b469917864c8f M include

[penalvch (penalvch)]

Mike Gratton, the issue you are reporting is an upstream one. Could you please report this problem through the appropriate channel by following the instructions _verbatim_ at https://wiki.ubuntu.com/Bugs/Upstream/kernel ?

Please provide a direct URL to your e-mail to the mailing list once you have made it so that it may be tracked.

Thank you for your understanding.