From: Alex Thorlton <athorlton@sgi.com>
To: linux-kernel@vger.kernel.org
Cc: Borislav Petkov <bp@suse.de>, Matt Fleming <matt.fleming@intel.com>
Subject: [BUG] Linux 3.14 fails to boot with new EFI changes
Date: Thu, 23 Jan 2014 16:11:08 -0600 [thread overview]
Message-ID: <20140123221108.GL18196@sgi.com> (raw)
We've been hitting the following bug in the latest kernel, during boot:
kernel BUG at arch/x86/mm/init_64.c:351!
invalid opcode: 0000 [#1] SMP
Modules linked in:
CPU: 0 PID: 1 Comm: swapper/0 Not tainted 3.13.0-medusa-04156-g90804ed-dirty #750
Hardware name: Intel Corp. Stoutland Platform, BIOS 2.0 UEFI2.10 PI1.0 X64 2013-09-16
task: ffff88107c96c010 ti: ffff88107c96e000 task.ti: ffff88107c96e000
RIP: 0010:[<ffffffff818aa6d8>] [<ffffffff818aa6d8>] __init_extra_mapping+0x111/0x143
RSP: 0000:ffff88107c96fd18 EFLAGS: 00010206
RAX: 0000000000000e00 RBX: ffff880001c4a018 RCX: 0000000000000002
RDX: ffff88107fcd1e00 RSI: 0000000004000000 RDI: 00000000f8000000
RBP: ffff88107c96fd48 R08: 0000000000000000 R09: 0000000000000000
R10: 00000000007e3b3c R11: 0000000000000000 R12: 00000000f8000000
R13: 0000000004000000 R14: ffff8800f8000000 R15: 0000000080000000
FS: 0000000000000000(0000) GS:ffff880073200000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
CR2: ffff8827fefff000 CR3: 00000000017d7000 CR4: 00000000000006f0
Stack:
80000000000001fb 0000000000000000 0000000000000040 000000000000b018
000000000000b010 000000000000b008 ffff88107c96fd58 ffffffff818aa71d
ffff88107c96fe28 ffffffff818a5e20 00000000000cb748 0000000000000282
Call Trace:
[<ffffffff818aa71d>] init_extra_mapping_uc+0x13/0x15
[<ffffffff818a5e20>] uv_system_init+0x22b/0x124b
[<ffffffff8108b886>] ? clockevents_register_device+0x138/0x13d
[<ffffffff81028dbb>] ? setup_APIC_timer+0xc5/0xc7
[<ffffffff8108b620>] ? clockevent_delta2ns+0xb/0xd
[<ffffffff818a3a92>] ? setup_boot_APIC_clock+0x4a8/0x4b7
[<ffffffff8153d955>] ? printk+0x72/0x74
[<ffffffff818a1757>] native_smp_prepare_cpus+0x389/0x3d6
[<ffffffff818957bc>] kernel_init_freeable+0xb7/0x1fb
[<ffffffff81535530>] ? rest_init+0x74/0x74
[<ffffffff81535539>] kernel_init+0x9/0xff
[<ffffffff81541dfc>] ret_from_fork+0x7c/0xb0
[<ffffffff81535530>] ? rest_init+0x74/0x74
Code: ff ff ff 3f 00 00 48 23 13 48 b8 00 00 00 00 00 88 ff ff 48 01 c2 4c 89 e0 48 c1 e8 12 25 f8 0f 00 00 48 01 c2 48 83 3a 00 74 04 <0f> 0b eb fe 48 8b 45 d0 49 81 ed 00 00 20 00 4c 09 e0 49 81 c4
RIP [<ffffffff818aa6d8>] __init_extra_mapping+0x111/0x143
RSP <ffff88107c96fd18>
I've bisected the issue down to this commit:
commit d2f7cbe7b26a74dbbbf8f325b2a6fd01bc34032c
Author: Borislav Petkov <bp@suse.de>
Date: Thu Oct 31 17:25:08 2013 +0100
x86/efi: Runtime services virtual mapping
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 <bp@suse.de>
Signed-off-by: Matt Fleming <matt.fleming@intel.com>
Running with the efi=old_map does seem to remedy the problem. One
solution, proposed by Mike Travis (travis@sgi.com), is to switch the
behavior over so that you have to provide a command line parameter to
activate the new behavior, instead of one to deactivate it.
Any input on the issue would be greatly appreciated. Thanks!
- Alex
next reply other threads:[~2014-01-23 22:10 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-01-23 22:11 Alex Thorlton [this message]
2014-01-23 22:48 ` [BUG] Linux 3.14 fails to boot with new EFI changes Borislav Petkov
[not found] <52E2ADB1.2030007@zytor.com>
[not found] ` <20140124183730.GC11788@pd.tnic>
[not found] ` <20140124184842.GD11788@pd.tnic>
[not found] ` <20140124191709.GT18196@sgi.com>
[not found] ` <20140127222129.GK6839@pd.tnic>
[not found] ` <20140128110552.GA815@pd.tnic>
[not found] ` <20140128200754.GZ18196@sgi.com>
[not found] ` <20140128225905.GN815@pd.tnic>
[not found] ` <20140128234036.GB18196@sgi.com>
[not found] ` <20140129141822.GC24887@pd.tnic>
2014-01-30 22:19 ` Alex Thorlton
2014-01-30 22:23 ` H. Peter Anvin
2014-01-31 10:07 ` Borislav Petkov
[not found] ` <20140131100722.GA21873-fF5Pk5pvG8Y@public.gmane.org>
2014-01-31 14:02 ` Russ Anderson
2014-01-31 14:02 ` Russ Anderson
[not found] ` <20140131140220.GC22498-sJ/iWh9BUns@public.gmane.org>
2014-01-31 14:23 ` Borislav Petkov
2014-01-31 14:23 ` Borislav Petkov
[not found] ` <20140131142318.GC21873-fF5Pk5pvG8Y@public.gmane.org>
2014-01-31 14:36 ` Borislav Petkov
2014-01-31 14:36 ` Borislav Petkov
2014-02-05 21:45 ` Alex Thorlton
2014-02-05 21:45 ` Alex Thorlton
[not found] ` <20140205214536.GT3034-sJ/iWh9BUns@public.gmane.org>
2014-02-05 23:15 ` Borislav Petkov
2014-02-05 23:15 ` Borislav Petkov
[not found] ` <20140205231540.GB6364-fF5Pk5pvG8Y@public.gmane.org>
2014-02-11 22:19 ` Alex Thorlton
2014-02-11 22:19 ` Alex Thorlton
[not found] ` <20140211221903.GG27648-sJ/iWh9BUns@public.gmane.org>
2014-02-11 22:36 ` Borislav Petkov
2014-02-11 22:36 ` Borislav Petkov
[not found] ` <20140130221950.GJ3105-sJ/iWh9BUns@public.gmane.org>
2014-01-31 8:04 ` Matt Fleming
2014-01-31 8:04 ` Matt Fleming
[not found] ` <20140131080428.GA29136-HNK1S37rvNbeXh+fF434Mdi2O/JbrIOy@public.gmane.org>
2014-01-31 13:53 ` Russ Anderson
2014-01-31 13:53 ` Russ Anderson
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20140123221108.GL18196@sgi.com \
--to=athorlton@sgi.com \
--cc=bp@suse.de \
--cc=linux-kernel@vger.kernel.org \
--cc=matt.fleming@intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.