Re: 2.6.15-rt4 failure with LATENCY_TRACE on x86_64

[Clark Williams <williams@redhat.com>]

On Sat, 2006-01-14 at 06:12 +0100, Mikael Andersson wrote:
> Steven Rostedt wrote:
> > On Fri, 13 Jan 2006, Clark Williams wrote:
> >>Have you tried booting your system with a up kernel?
> >>
> > Not a x86_64 up.  But serveral up i386 boxes.
> > 
> 
> I had a very similar problem on a x86_64 up. I got a segfault in init 
> with LATENCY_TRACE enabled on 2.6.15-rt2.
> I get it at ffffffff8010fe30, which should be mcount according to my 
> System.map [1]. It seems a bit weird because i have tried to alter 
> mcount somewhat. Initially by removing the initial comparison, but later
> i tried a few other things also. Nothing had any effect at all.

Glad to see that I'm not completely insane :).

> 
> AFAIK glibc also has a mcount symbol, and it's almost as if ld.so would 
> have linked the glibc mcount symbol to the kernel symbol mcount. That
> would naturally lead to a pagefault :)
>   And it would be consistent with the fact that statically linked shells
> works.
> 
> It's probably something completely different, bevause that would be 
> really weird. OTOH, it was really weird that i could change the asm for 
> mcount in entry.S without any effect whatsoever.
> 

Yeah, I don't really see how ld.so would know about the kernel mcount.
AFAIK it only knows about symbols exported from ELF libraries that it
has loaded in user space. 

I'm still trying to figure out if LATENCY_TRACE could effect
do_execve(), since that's the routine that starts the init program. I'm
wondering if do_execve() is doing something that aggrevates ld.so, so
that it loads the program and/or libraries incorrectly.

Guess that's what I'll be doing Monday morning...

Clark

-- 
Clark Williams <williams@redhat.com>

Attachment: signature.asc
Description: This is a digitally signed message part