From: Jeremy Fitzhardinge <jeremy@goop.org>
To: Andi Kleen <andi@firstfloor.org>
Cc: mingo@elte.hu, tglx@linutronix.de, linux-kernel@vger.kernel.org,
venkatesh.pallipadi@intel.com
Subject: Re: [PATCH] Fix early_ioremap on x86-64 II
Date: Mon, 21 Jan 2008 11:00:34 -0800 [thread overview]
Message-ID: <4794EBD2.6010804@goop.org> (raw)
In-Reply-To: <20080120180431.GA7452@basil.nowhere.org>
Andi Kleen wrote:
>> This patch changes all flushes in init_64.c to be __flush_tlb_all()
>> and fixes the problem here.
>>
>
> Hmm, I see new early crashes with that patch here in some cases unfortunately:
>
> PANIC: early exception 06 rip 10:ffffffff8082df2d error 0 cr2 0
> Pid: 0, comm: swapper Not tainted 2.6.24-rc8-g7ada4254 #39
>
> Call Trace:
> [<ffffffff8082df2d>] free_bootmem_core+0x1a/0x6b
> [<ffffffff8082f143>] free_bootmem_with_active_regions+0x51/0x67
> [<ffffffff8082a0f3>] setup_node_bootmem+0x16b/0x1b3
> [<ffffffff8082b3a4>] acpi_scan_nodes+0x136/0x230
> [<ffffffff8082a6bb>] numa_initmem_init+0x331/0x459
> [<ffffffff80234ef6>] release_console_sem+0x1b4/0x1cd
> [<ffffffff80234ef6>] release_console_sem+0x1b4/0x1cd
> [<ffffffff80355726>] number+0x10e/0x1f9
> [<ffffffff802354d8>] printk+0x4e/0x56
> [<ffffffff80355726>] number+0x10e/0x1f9
> [<ffffffff803563f8>] vsnprintf+0x53f/0x583
> [<ffffffff80355726>] number+0x10e/0x1f9
> [<ffffffff80234ef6>] release_console_sem+0x1b4/0x1cd
> [<ffffffff803563f8>] vsnprintf+0x53f/0x583
> [<ffffffff8022468a>] early_serial_write+0x22/0x32
>
> Not sure what's going wrong. I think the patch is correct, but there
> are probably more bugs around triggered by some change. Perhaps it is
> better to just revert Jeremy's patch (789bad4ca2b604f2f21ae7e3d64b67325ec8f9bb) for now.
>
It's a purely "make things prettier" patch, so I have no problem with
that. If the non-global flags used in early 64-bit pagetables is very
deeply ingrained, I wonder if its worth making a separate set of
explicitly non-global _PAGE_KERNEL flags for its use, so that at least
_PAGE_KERNEL* is consistent between 32 and 64 bits. Otherwise its going
to be the sort of difference which gets increasingly awkward as things
get unified (I guess its mitigated by the fact that 32-bit code can
never assume that global mappings are available and present).
J
prev parent reply other threads:[~2008-01-21 19:00 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-01-20 17:28 [PATCH] Fix early_ioremap on x86-64 Andi Kleen
2008-01-20 17:59 ` Ingo Molnar
2008-01-20 19:12 ` Andi Kleen
2008-01-21 0:20 ` Ingo Molnar
2008-01-20 18:04 ` [PATCH] Fix early_ioremap on x86-64 II Andi Kleen
2008-01-21 19:00 ` Jeremy Fitzhardinge [this message]
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=4794EBD2.6010804@goop.org \
--to=jeremy@goop.org \
--cc=andi@firstfloor.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=tglx@linutronix.de \
--cc=venkatesh.pallipadi@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.