Re: 2.6.17-mm4

Ingo Molnar
2006-06-30T10:26:58Z

* 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