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: 14+ 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
2014-01-31 14:02 ` Russ Anderson
2014-01-31 14:23 ` Borislav Petkov
2014-01-31 14:36 ` Borislav Petkov
2014-02-05 21:45 ` Alex Thorlton
2014-02-05 23:15 ` Borislav Petkov
2014-02-11 22:19 ` Alex Thorlton
2014-02-11 22:36 ` Borislav Petkov
2014-01-31 8:04 ` Matt Fleming
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 a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).