lkml.org 
[lkml]   [2008]   [Jan]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: 2.6.24-rc7-rt2


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



\
 
 \ /
  Last update: 2008-01-15 19:09    [W:1.546 / U:0.052 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site