From: Jeremy Fitzhardinge <jeremy@goop.org>
To: Mike Travis <travis@sgi.com>
Cc: Christoph Lameter <clameter@sgi.com>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: [crash, bisected] Re: [PATCH 3/4] x86_64: Fold pda into per cpu area
Date: Fri, 20 Jun 2008 10:25:34 -0700 [thread overview]
Message-ID: <485BE80E.10209@goop.org> (raw)
In-Reply-To: <485BDB04.4090709@sgi.com>
Mike Travis wrote:
> Jeremy Fitzhardinge wrote:
>
>> Mike Travis wrote:
>>
>>> @@ -132,6 +133,12 @@ ident_complete:
>>> #ifdef CONFIG_SMP
>>> addq %rbp, trampoline_level4_pgt + 0(%rip)
>>> addq %rbp, trampoline_level4_pgt + (511*8)(%rip)
>>> +
>>> + /*
>>> + * Fix up per_cpu__gdt_page offset when basing percpu
>>> + * variables at zero. This is only needed for the boot cpu.
>>> + */
>>> + addq $__per_cpu_load, early_gdt_descr_base
>>>
>>>
>> This needs to be rip-relative. An absolute reference here will fail
>> because you're still running in physical addresses.
>>
>> J
>>
>
> Still bombs right at boot up... ;-(
>
Yep. I see the triple-fault at the "mov %eax,%ds", which means it's
having trouble with the gdt. Either 1) the lgdt pointed to a bad
address, or 2) there's something wrong with the descriptor there.
The dump is:
(XEN) hvm.c:767:d14 Triple fault on VCPU0 - invoking HVM system reset.
(XEN) ----[ Xen-3.3-unstable x86_64 debug=n Not tainted ]----
(XEN) CPU: 0
(XEN) RIP: 0010:[<ffffffff80200167>]
(XEN) RFLAGS: 0000000000010002 CONTEXT: hvm
(XEN) rax: 0000000000000018 rbx: 0000000000000000 rcx: ffffffff808d6000
(XEN) rdx: 0000000000000000 rsi: 0000000000092f40 rdi: 0000000020100800
(XEN) rbp: 0000000000000000 rsp: ffffffff80827ff8 r8: 0000000000208000
(XEN) r9: 0000000000000000 r10: 0000000000000000 r11: 00000000000000d8
(XEN) r12: 0000000000000000 r13: 0000000000000000 r14: 0000000000000000
(XEN) r15: 0000000000000000 cr0: 0000000080050033 cr4: 00000000000000a0
(XEN) cr3: 0000000000201000 cr2: 0000000000000000
(XEN) ds: 0000 es: 0000 fs: 0000 gs: 0000 ss: 0000 cs: 0010
I loaded early_gdt_descr+2 into %rcx, which looks reasonable. Hm, but
loading the __KERNEL_DS descriptor into %rdx, which is all zero.
So it seems the problem is that the pre-initialized gdt_page is being
lost and replaced with zero. Linker script bug?
J
--- a/arch/x86/kernel/head_64.S Fri Jun 20 09:50:02 2008 -0700
+++ b/arch/x86/kernel/head_64.S Fri Jun 20 10:19:20 2008 -0700
@@ -213,6 +213,8 @@
* because in 32bit we couldn't load a 64bit linear address.
*/
lgdt early_gdt_descr(%rip)
+ movq early_gdt_descr+2(%rip), %rcx
+ movq __KERNEL_DS(%rcx), %rdx
/* set up data segments. actually 0 would do too */
movl $__KERNEL_DS,%eax
next prev parent reply other threads:[~2008-06-20 17:25 UTC|newest]
Thread overview: 108+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-06-04 0:30 [PATCH 0/4] percpu: Optimize percpu accesses Mike Travis
2008-06-04 0:30 ` [PATCH 1/4] Zero based percpu: Infrastructure to rebase the per cpu area to zero Mike Travis
2008-06-10 10:06 ` Ingo Molnar
2008-06-04 0:30 ` [PATCH 2/4] x86: Extend percpu ops to 64 bit Mike Travis
2008-06-10 10:04 ` Ingo Molnar
2008-06-04 0:30 ` [PATCH 3/4] x86_64: Fold pda into per cpu area Mike Travis
2008-06-04 12:59 ` Jeremy Fitzhardinge
2008-06-04 13:48 ` Mike Travis
2008-06-04 13:58 ` Jeremy Fitzhardinge
2008-06-04 14:17 ` Mike Travis
2008-06-09 23:18 ` Christoph Lameter
2008-06-05 10:22 ` [crash, bisected] " Ingo Molnar
2008-06-05 16:02 ` Mike Travis
2008-06-06 8:29 ` Jeremy Fitzhardinge
2008-06-06 13:15 ` Mike Travis
2008-06-18 5:34 ` Jeremy Fitzhardinge
2008-06-10 21:31 ` Mike Travis
2008-06-18 17:36 ` Jeremy Fitzhardinge
2008-06-18 18:17 ` Mike Travis
2008-06-18 18:33 ` Ingo Molnar
2008-06-18 19:33 ` Jeremy Fitzhardinge
[not found] ` <48596893.4040908@sgi.com>
[not found] ` <485AADAC.3070301@sgi.com>
[not found] ` <485AB78B.5090904@goop.org>
[not found] ` <485AC120.6010202@sgi.com>
[not found] ` <485AC5D4.6040302@goop.org>
[not found] ` <485ACA8F.10006@sgi.com>
[not found] ` <485ACD92.8050109@sgi.com>
2008-06-19 21:35 ` Jeremy Fitzhardinge
2008-06-19 21:54 ` Jeremy Fitzhardinge
2008-06-19 22:13 ` Mike Travis
2008-06-19 22:21 ` Jeremy Fitzhardinge
2008-06-30 17:49 ` Mike Travis
2008-06-19 22:23 ` Jeremy Fitzhardinge
[not found] ` <485BDB04.4090709@sgi.com>
2008-06-20 17:25 ` Jeremy Fitzhardinge [this message]
2008-06-20 17:48 ` Christoph Lameter
2008-06-20 18:30 ` Mike Travis
2008-06-20 18:40 ` Jeremy Fitzhardinge
2008-06-20 18:37 ` Jeremy Fitzhardinge
2008-06-20 18:51 ` Christoph Lameter
2008-06-20 19:04 ` Jeremy Fitzhardinge
2008-06-20 19:21 ` H. Peter Anvin
2008-06-20 19:43 ` Eric W. Biederman
2008-06-20 20:04 ` Mike Travis
2008-06-20 20:37 ` Christoph Lameter
2008-06-20 19:06 ` Mike Travis
2008-06-20 20:25 ` Eric W. Biederman
2008-06-20 20:55 ` Christoph Lameter
2008-06-23 16:55 ` Mike Travis
2008-06-23 17:33 ` Jeremy Fitzhardinge
2008-06-23 18:04 ` Mike Travis
2008-06-23 18:36 ` Mike Travis
2008-06-23 19:41 ` Jeremy Fitzhardinge
2008-06-24 0:02 ` Mike Travis
2008-06-30 17:07 ` Mike Travis
2008-06-30 17:18 ` H. Peter Anvin
2008-06-30 17:57 ` Mike Travis
2008-06-30 20:50 ` Eric W. Biederman
2008-06-30 21:08 ` Jeremy Fitzhardinge
2008-07-01 8:40 ` Eric W. Biederman
2008-07-01 16:27 ` Jeremy Fitzhardinge
2008-07-01 16:55 ` Mike Travis
2008-07-01 16:56 ` H. Peter Anvin
2008-07-01 17:26 ` Jeremy Fitzhardinge
2008-07-01 20:40 ` Eric W. Biederman
2008-07-01 21:10 ` Jeremy Fitzhardinge
2008-07-01 21:39 ` Eric W. Biederman
2008-07-01 21:52 ` Jeremy Fitzhardinge
2008-07-02 0:20 ` H. Peter Anvin
2008-07-02 1:15 ` Mike Travis
2008-07-02 1:32 ` Eric W. Biederman
2008-07-02 1:51 ` Mike Travis
2008-07-02 2:50 ` Eric W. Biederman
2008-07-02 1:40 ` H. Peter Anvin
2008-07-02 1:44 ` Mike Travis
2008-07-02 1:45 ` H. Peter Anvin
2008-07-02 1:55 ` Mike Travis
2008-07-02 22:50 ` Mike Travis
2008-07-03 4:34 ` Eric W. Biederman
2008-07-07 17:17 ` Mike Travis
2008-07-07 19:46 ` Eric W. Biederman
2008-07-08 18:21 ` Mike Travis
2008-07-08 23:36 ` Eric W. Biederman
2008-07-08 23:49 ` Jeremy Fitzhardinge
2008-07-09 14:39 ` Mike Travis
2008-07-25 20:06 ` Mike Travis
2008-07-25 20:12 ` Jeremy Fitzhardinge
2008-07-25 20:34 ` Mike Travis
2008-07-25 20:43 ` Jeremy Fitzhardinge
2008-07-25 21:05 ` Mike Travis
2008-07-09 14:37 ` Mike Travis
2008-07-09 22:38 ` Eric W. Biederman
2008-07-09 23:30 ` Mike Travis
2008-07-10 0:04 ` Eric W. Biederman
2008-07-02 2:01 ` H. Peter Anvin
2008-07-02 3:08 ` Eric W. Biederman
2008-07-01 21:11 ` Andi Kleen
2008-07-01 21:42 ` Eric W. Biederman
2008-07-01 18:41 ` Eric W. Biederman
2008-07-01 12:09 ` Mike Travis
2008-07-01 11:49 ` Mike Travis
2008-06-30 17:43 ` Jeremy Fitzhardinge
2008-06-04 0:30 ` [PATCH 4/4] x86: Replace xxx_pda() operations with x86_xx_percpu() Mike Travis
2008-06-09 13:03 ` Ingo Molnar
2008-06-09 16:08 ` Mike Travis
2008-06-09 17:36 ` Mike Travis
2008-06-09 18:20 ` Christoph Lameter
2008-06-09 23:29 ` Jeremy Fitzhardinge
2008-06-10 10:09 ` Ingo Molnar
2008-06-10 15:07 ` Mike Travis
2008-06-04 10:18 ` [PATCH] x86: collapse the various size-dependent percpu accessors together Jeremy Fitzhardinge
2008-06-04 10:45 ` Jeremy Fitzhardinge
2008-06-04 11:29 ` Ingo Molnar
2008-06-04 12:09 ` Jeremy Fitzhardinge
2008-06-10 17:21 ` Christoph Lameter
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=485BE80E.10209@goop.org \
--to=jeremy@goop.org \
--cc=clameter@sgi.com \
--cc=linux-kernel@vger.kernel.org \
--cc=travis@sgi.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.