Re: 2.6.24-rc7-rt2

[Steven Rostedt]

On Tue, 15 Jan 2008, Luotao Fu wrote:
>
> Compiling with tracing function turned seemed still to be broken to me:

Could you email me your config (privately)

> kernel/built-in.o: In function `early_printk_name':
> latency_trace.c:(.text+0x3cd18): undefined reference to `early_printk'
> latency_trace.c:(.text+0x3cd40): undefined reference to `early_printk'
> kernel/built-in.o: In function `early_print_entry':
> latency_trace.c:(.text+0x3cd80): undefined reference to `early_printk'
> latency_trace.c:(.text+0x3cdd8): undefined reference to `early_printk'
> latency_trace.c:(.text+0x3cdfc): undefined reference to `early_printk'
>
> We made a early_printk patch based on the 8250_early for powerpc 32bit here.
> (still absolutely untested and incomplete, we will post it asap). I added
> early_printk() and exported _mcount() and could compile succesfully. However the
> kernel will not boot. I attached a bdi to it and found out that it stucks at
> _mcount in arch/powerpc/kernel/entry_32.S at about line 1080, where the variable
> mcount_enabled is loaded and checked. Obviously the variable is still not valid
> at the time of check. To check this I took out the lines like above
>
> --- arch/powerpc/kernel/entry_32.S.orig 2008-01-15 17:01:25.000000000 +0100
> +++ arch/powerpc/kernel/entry_32.S      2008-01-15 17:17:18.000000000 +0100
> @@ -1075,9 +1075,6 @@
>         stw     r6, 24(r1)
>         mflr    r3      /* will use as first arg to __trace() */
>         mfcr    r4
> -       lis     r5,mcount_enabled@ha
> -       lwz     r5,mcount_enabled@l(r5)
> -       cmpwi   r5,0
>         stw     r3, 44(r1)      /* lr */
>         stw     r4,  8(r1)      /* cr */
>         stw     r7, 28(r1)
>
> After recompiling the kernel started normally and it seems to work. I was even
> able to make a trace with cyclictest. However there were several crashes (which
> might be caused by other problems). I still have to take a closer look.
>
> I am just wondering why the check for mcount_enabled is there at all and I think
> that there due to be some better fixes than just throw it out ;-). On the other
> side, I just can't find in which way mcount_enabled is used in the tracer at
> all. Could you give me some hints on this one?
>

The way we turn on and off mcount function calls at run time is through
mcount_enable.  I'll look into why this is broken for you. I'm able to run
with this. My box is a ppc64, and my ppc32 (powerbook) wont come close to
booting RT (never did).  On boot up it locks up right away and the screen
looks like it starts to melt. No serial, so I don't have much to debug
that with.

Anyway, I'll take a deeper look into this.

Thanks,

-- Steve

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/