From: Ingo Molnar <mingo@elte.hu>
To: Jeremy Fitzhardinge <jeremy@goop.org>
Cc: "H. Peter Anvin" <hpa@zytor.com>, Yinghai Lu <yinghai@kernel.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: [crash] Re: Latest brk patchset
Date: Mon, 16 Mar 2009 09:54:02 +0100 [thread overview]
Message-ID: <20090316085402.GC1062@elte.hu> (raw)
In-Reply-To: <49BD8F15.4020301@goop.org>
* Jeremy Fitzhardinge <jeremy@goop.org> wrote:
> Ingo Molnar wrote:
>> * Jeremy Fitzhardinge <jeremy@goop.org> wrote:
>>
>>
>>> Ingo Molnar wrote:
>>>
>>>> * Jeremy Fitzhardinge <jeremy@goop.org> wrote:
>>>>
>>>>
>>>>> H. Peter Anvin wrote:
>>>>>
>>>>>> Well, the semantics are different; the .bss section is zeroed while the
>>>>>> brk isn't, and the brk symbols don't necessarily point to the data
>>>>>> associated with those particular symbols, unlike (of course) the bss.
>>>>>>
>>>>>> It's not a big issue, obviously, it just seems cleaner to me that way.
>>>>>>
>>>>> OK, I just added a couple of changes to:
>>>>>
>>>>> * make the brk reservation symbols have the form ".brk.NAME" to make
>>>>> them inaccessible from C, and to make them look obviously
>>>>> different from normal symbols (more like sections, since it is
>>>>> their size that's more important than their address)
>>>>> * Put all the brk stuff in a .brk section
>>>>> * Mention alignment in the comment for the slop space
>>>>>
>>>>> J
>>>>>
>>>>> The following changes since commit 1e08816af0bc345995c3f26ce4eaba1171ffb531:
>>>>> Ingo Molnar (1):
>>>>> Merge branch 'linus'
>>>>>
>>>>> are available in the git repository at:
>>>>>
>>>>> git://git.kernel.org/pub/scm/linux/kernel/git/jeremy/xen.git push/x86/brk
>>>>>
>>>> the previous kit in tip:x86/setup-memory is causing crashes. One of
>>>> them is:
>>>>
>>>> init_memory_mapping: 0000000000000000-00000000377fe000
>>>> 0000000000 - 00377fe000 page 4k
>>>> Kernel panic - not syncing: Cannot
>>>> find space for the kernel page tables Pid: 0, comm:
>>>> swapper Not tainted 2.6.29-rc8-tip-02516-g83219b0-dirty #35476
>>>> Call Trace:
>>>> [<c0128b7b>] panic+0x4b/0x100
>>>> [<c074a989>]
>>>> init_memory_mapping+0x429/0x430
>>>> [<c0cde790>] setup_arch+0x430/0x890
>>>> [<c0148f4e>] ? lockdep_init_map+0x2e/0x150
>>>> [<c036f392>] ?
>>>> __spin_lock_init+0x32/0x60
>>>> [<c01298d0>] ? printk+0x20/0x30
>>>> [<c0cdc966>] start_kernel+0xc6/0x330
>>>> [<c0cdc321>]
>>>> i386_start_kernel+0x41/0x50
>>>>
>>>> full crashlog below, config attached.
>>>>
>>> What branch is this? I'm trying to build with your config with
>>> current tip/master w/ tip/x86/setup-memory merged into it, but "make
>>> ARCH=i386 oldconfig" is asking me about CONFIG_SMP, which makes me
>>> think the config file is incomplete.
>>>
>>
>> just accept the defaults in 'make oldconfig' and you'll get the right
>> config.
>>
>
> Got some build failures due to warnings treated as errors.
Sorry - you need CONFIG_ALLOW_WARNINGS=y. Indeed my tests can
emit !CONFIG_ALLOW_WARNINGS configs.
> And the resulting kernel booted fine under qemu with 1Gbyte of
> memory. I'll try on real hardware a bit later, but it doesn't
> seem like something that should be affected by qemu vs native,
> unless it has something to do with the specific e820 map.
Note that the crash was reproducible and it very clearly went
away when i excluded those commits from tip:master.
Ingo
next prev parent reply other threads:[~2009-03-16 8:54 UTC|newest]
Thread overview: 51+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-03-14 23:43 Latest brk patchset H. Peter Anvin
2009-03-15 0:32 ` Jeremy Fitzhardinge
2009-03-15 0:37 ` H. Peter Anvin
2009-03-15 6:09 ` Jeremy Fitzhardinge
2009-03-15 6:29 ` Jeremy Fitzhardinge
2009-03-15 20:38 ` [crash] " Ingo Molnar
2009-03-15 20:42 ` Ingo Molnar
2009-03-15 21:19 ` Jeremy Fitzhardinge
2009-03-15 21:28 ` Ingo Molnar
2009-03-15 23:28 ` Jeremy Fitzhardinge
2009-03-16 8:54 ` Ingo Molnar [this message]
2009-03-16 16:12 ` Jeremy Fitzhardinge
2009-03-16 16:56 ` Yinghai Lu
2009-03-16 17:20 ` Jeremy Fitzhardinge
2009-03-16 17:54 ` Jeremy Fitzhardinge
2009-03-16 18:15 ` H. Peter Anvin
2009-03-16 18:17 ` Yinghai Lu
2009-03-16 18:22 ` H. Peter Anvin
2009-03-16 18:31 ` Yinghai Lu
2009-03-16 18:17 ` H. Peter Anvin
2009-03-16 19:25 ` Jeremy Fitzhardinge
2009-03-16 19:34 ` H. Peter Anvin
2009-03-16 19:48 ` Yinghai Lu
2009-03-16 20:00 ` Jeremy Fitzhardinge
2009-03-16 20:26 ` H. Peter Anvin
2009-03-16 20:59 ` Jeremy Fitzhardinge
2009-03-16 21:14 ` H. Peter Anvin
2009-03-16 21:31 ` Jeremy Fitzhardinge
2009-03-16 22:35 ` H. Peter Anvin
2009-03-17 2:26 ` Yinghai Lu
2009-03-17 4:00 ` H. Peter Anvin
2009-03-17 5:07 ` Jeremy Fitzhardinge
2009-03-17 16:04 ` H. Peter Anvin
2009-03-17 19:42 ` Jeremy Fitzhardinge
2009-03-17 19:45 ` H. Peter Anvin
2009-03-17 19:59 ` Jeremy Fitzhardinge
2009-03-17 21:19 ` Yinghai Lu
2009-03-17 21:28 ` Jeremy Fitzhardinge
2009-03-17 19:47 ` Jeremy Fitzhardinge
2009-03-22 15:09 ` Ingo Molnar
2009-03-22 17:12 ` Jeremy Fitzhardinge
2009-03-22 17:22 ` Ingo Molnar
2009-03-22 21:48 ` Jeremy Fitzhardinge
2009-03-23 16:39 ` [tip:x86/setup] x86/dmi: fix dmi_alloc() section mismatches Jeremy Fitzhardinge
2009-03-15 1:37 ` Latest brk patchset H. Peter Anvin
2009-03-15 4:43 ` Yinghai Lu
2009-03-15 4:51 ` H. Peter Anvin
2009-03-15 5:33 ` Yinghai Lu
2009-03-15 6:05 ` Jeremy Fitzhardinge
2009-03-15 6:25 ` Yinghai Lu
2009-03-15 6:03 ` Jeremy Fitzhardinge
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=20090316085402.GC1062@elte.hu \
--to=mingo@elte.hu \
--cc=hpa@zytor.com \
--cc=jeremy@goop.org \
--cc=linux-kernel@vger.kernel.org \
--cc=yinghai@kernel.org \
/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.