From: Ingo Molnar <mingo@elte.hu>
To: Chuck Ebbert <76306.1226@compuserve.com>
Cc: Andrew Morton <akpm@osdl.org>,
linux-kernel <linux-kernel@vger.kernel.org>
Subject: Re: 2.6.17-mm4
Date: Fri, 30 Jun 2006 12:22:10 +0200 [thread overview]
Message-ID: <20060630102210.GC16567@elte.hu> (raw)
In-Reply-To: <200606300609_MC3-1-C3D7-6B49@compuserve.com>
* Chuck Ebbert <76306.1226@compuserve.com> wrote:
> In-Reply-To: <20060629232739.GA28306@elte.hu>
>
> On Fri, 30 Jun 2006 01:27:39 +0200, Ingo Molnar wrote:
>
> > > +profile-likely-unlikely-macros.patch
> >
> > CONFIG_PROFILE_LIKELY doesnt quite work:
> >
> > Low memory ends at vaddr f7e00000
> > node 0 will remap to vaddr f7e00000 - f8000000
> > High memory starts at vaddr f7e00000
> > found SMP MP-table at 000f5680
> > NX (Execute Disable) protection: active
> > Unknown interrupt or fault at EIP 00000060 c1d9f264 00000002
> > Unknown interrupt or fault at EIP 00000060 c0100295 0000f264
> > Unknown interrupt or fault at EIP 00000060 c0100295 00000294
> > Unknown interrupt or fault at EIP 00000060 c0100295 00000294
> > Unknown interrupt or fault at EIP 00000060 c0100295 00000294
> > Unknown interrupt or fault at EIP 00000060 c0100295 00000294
> >
> > disabling it makes these go away.
>
> Can you find out what source line belongs to c1d9f264?
>
> arch/i386/kernel/head.S::ignore_int(), which produced those messages,
> is horribly broken. The first fault was likely a page fault
> attempting to write to some unmapped area. Since page fault pushes an
> error code onto the stack and ignore_int() doesn't pop it because it
> has no idea whether one is there, it attempts to return to cs:eip
> f264:00000002 which causes segment-not-present for segment index f264
> in the GDT. Same thing then happens when _that_ tries to return to
> 0295:0000f264; now we are into infinite recursion. Eventually the
> stack will overflow and more fun errors will occur...
>
> Is this worth fixing? We could get nice diagnostics for page fault
> here by writing a handler for early init code.
yes, it's worth fixing if it doesnt complicate that code too much - i
run across such early init faults every couple of weeks when hacking
various code. (Maybe just some generic 'dump 64 bytes of the top of the
stack' would be enough too. Early-bootup is fragile enough already.)
Ingo
next prev parent reply other threads:[~2006-06-30 10:26 UTC|newest]
Thread overview: 47+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-06-30 10:07 2.6.17-mm4 Chuck Ebbert
2006-06-30 10:22 ` Ingo Molnar [this message]
-- strict thread matches above, loose matches on Subject: below --
2006-06-29 8:36 2.6.17-mm4 Andrew Morton
2006-06-29 9:44 ` 2.6.17-mm4 Benoit Boissinot
2006-06-29 11:44 ` 2.6.17-mm4 Reuben Farrelly
2006-06-29 11:45 ` 2.6.17-mm4 Reuben Farrelly
2006-06-29 17:52 ` 2.6.17-mm4 Andrew Morton
2006-06-30 7:18 ` 2.6.17-mm4 Reuben Farrelly
2006-06-30 7:33 ` 2.6.17-mm4 Andrew Morton
2006-06-29 17:53 ` 2.6.17-mm4 Jesse Brandeburg
2006-06-29 19:05 ` 2.6.17-mm4 Andrew Morton
2006-06-30 23:53 ` 2.6.17-mm4 Jesse Brandeburg
2006-07-01 0:12 ` 2.6.17-mm4 Andrew Morton
2006-07-01 0:17 ` 2.6.17-mm4 Jesse Brandeburg
2006-07-01 0:31 ` 2.6.17-mm4 john stultz
2006-07-01 17:33 ` 2.6.17-mm4 Jesse Brandeburg
2006-07-01 17:56 ` 2.6.17-mm4 john stultz
2006-07-01 23:57 ` 2.6.17-mm4 Andrew Morton
2006-07-02 2:45 ` 2.6.17-mm4 john stultz
2006-07-02 3:19 ` 2.6.17-mm4 Andrew Morton
2006-07-02 3:37 ` 2.6.17-mm4 john stultz
2006-07-01 0:52 ` 2.6.17-mm4 Andrew Morton
2006-07-01 18:18 ` 2.6.17-mm4 Jesse Brandeburg
2006-07-01 0:22 ` 2.6.17-mm4 Andrew Morton
2006-06-29 20:39 ` 2.6.17-mm4 Michal Piotrowski
2006-06-29 20:43 ` 2.6.17-mm4 Dave Jones
2006-06-29 20:46 ` 2.6.17-mm4 Michal Piotrowski
2006-06-29 20:49 ` 2.6.17-mm4 Dave Jones
2006-06-29 20:57 ` 2.6.17-mm4 Michal Piotrowski
2006-06-29 20:58 ` 2.6.17-mm4 Andrew Morton
2006-06-29 21:41 ` 2.6.17-mm4 Michal Piotrowski
2006-06-29 21:09 ` 2.6.17-mm4 Ingo Molnar
2006-06-29 23:05 ` 2.6.17-mm4 Ingo Molnar
2006-06-30 10:07 ` 2.6.17-mm4 Alan Cox
2006-06-30 9:50 ` 2.6.17-mm4 Ingo Molnar
2006-06-30 9:54 ` 2.6.17-mm4 Arjan van de Ven
2006-06-30 11:01 ` 2.6.17-mm4 Andreas Mohr
2006-06-30 12:14 ` 2.6.17-mm4 Alan Cox
2006-06-30 17:27 ` 2.6.17-mm4 Dave Jones
2006-06-30 17:52 ` 2.6.17-mm4 Alan Cox
2006-06-29 21:40 ` 2.6.17-mm4 Chris Rode
2006-06-29 22:18 ` 2.6.17-mm4 Andrew Morton
2006-06-29 23:27 ` 2.6.17-mm4 Ingo Molnar
2006-06-30 19:20 ` 2.6.17-mm4 Manuel Lauss
2006-06-30 23:26 ` 2.6.17-mm4 Andrew Morton
2006-07-01 7:12 ` 2.6.17-mm4 Manuel Lauss
2006-06-30 20:16 ` 2.6.17-mm4 Rafael J. Wysocki
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=20060630102210.GC16567@elte.hu \
--to=mingo@elte.hu \
--cc=76306.1226@compuserve.com \
--cc=akpm@osdl.org \
--cc=linux-kernel@vger.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox