Re: 2.6.24-rc7-rt2

[Luotao Fu <l.fu@pengutronix.de>]

[-- Attachment #1: Type: text/plain, Size: 2906 bytes --]

Hi Steven,

On Tue, Jan 15, 2008 at 01:06:25PM -0500, Steven Rostedt wrote:
> 
> 
> 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)

will send it later in another private mail, actually nothing spectacular. The
early_printk() is simply missing for 32bit powerpc. The 64bit implementation
puts a dummy for early_printk in setup_64.c:
~ grep -A 4 EARLY_PRINTK ./arch/powerpc/kernel/setup_64.c | head -6
#ifdef CONFIG_EARLY_PRINTK
void notrace early_printk(const char *fmt, ...)
{
        BUG();
	}
	#endif /* CONFIG_EARLY_PRINTK */
;-)
that could be why it works for you.

> 
....
> > 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.
> 

ah, thx for the hint. I took a look in the entry_64.S file. The checking of
mcount_enabled is indeed literally the same as the 32bit architecture.
An important point for the failure on 32bit machines is that due to my bdi the
machine got stuck still before the mmu is running. Hence I get quite funny pc
address like
Current PC        : 0x000135dc
it still lies over on 0x0 as the physical adress of the decompressed kernel in
memory. I think that mcount_enabled is linked somewhere in the virtual addess
space, so that the cmpwi stucks forever for _mcount is called so early, that we
still don't work with virtual addresses. I don't understand enough powerpc
assembler to work out how the LOAD_REG_ADDR() (used in entry_64.S to load
mcount_enabled) of 64 bit powerpcs work around this problem. Anyway, If my guess
is right, we might need something to get or simply ignore mcount_enabled
checking in the _mcount calls during early initialisation.

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

Thanks


cheers
Luotao Fu
-- 
   Dipl.-Ing. Luotao Fu | Phone: +49-5121-206917-3
Pengutronix - Linux Solutions for Science and Industry
Entwicklungszentrum Nord     http://www.pengutronix.de


[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]