Re: 2.6.17-mm4

[Chuck Ebbert <76306.1226@compuserve.com>]

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.

-- 
Chuck
 "You can't read a newspaper if you can't read."  --George W. Bush