early_initcall

early_initcall

[Stanislaw Skowronek]

What the hell is that? Nowhere declared and dead as a doornail in 2.6.5.

Stanislaw Skowronek

--<=>--
  Paranoid: one who is truly in touch with reality.

early_initcall

[Yoichi Yuasa]

Hi,

Since early_initcall is not defined in generic 2.6.10-rc3,
MIPS has a problem in generic kernel.

I investigated why early_initcall is not defined in generic kernel.
I found a following mail in LKML.

We need to move early_initcall to MIPS-specific header file.
Where do you think is a suitable header file for it?

Yoichi

---- Andrew's comment ----
From: Andrew Morton <akpm@osdl.org>
To: Samium Gromoff <deepfire@sic-elvis.zel.ru>
Cc: linux-kernel@vger.kernel.org, Ralf Baechle <ralf@linux-mips.org>
Subject: Re: [2.6.5][MIPS] oneliners somehow not made it into mainline [3/3]
Date: 	Mon, 12 Apr 2004 14:06:28 -0700
Sender: linux-kernel-owner@vger.kernel.org
X-Mailer: Sylpheed version 0.9.7 (GTK+ 1.2.10; i586-pc-linux-gnu)

Samium Gromoff <deepfire@sic-elvis.zel.ru> wrote:
>
> Without this one it fails to run the earlyinitcall stuff, and hence
> explodes at some point.
> 
> diff -urN -X './#cdiff.pattern' ./linux-2.6.5/include/linux/init.h ./mc-2.6.5/include/linux/init.h
> --- ./linux-2.6.5/include/linux/init.h  2004-04-12 16:07:45.000000000 +0400
> +++ ./mc-2.6.5/include/linux/init.h     2004-04-12 18:05:28.000000000 +0400
> @@ -83,6 +83,7 @@
>         static initcall_t __initcall_##fn __attribute_used__ \
>         __attribute__((__section__(".initcall" level ".init"))) = fn
> 
> +#define early_initcall(fn)             __define_initcall(".early1",fn)
>  #define core_initcall(fn)              __define_initcall("1",fn)
>  #define postcore_initcall(fn)          __define_initcall("2",fn)
>  #define arch_initcall(fn)              __define_initcall("3",fn)

early_initcall() is a mips-specific thing.  If we add this macro to
<linux/init.h> then someone will use it in generic code and all the other
architectures explode.

We need to either make this entirely mips-private, or rework the mips code
to not use it at all, or justify its introduction and then introduce it for
all architectures.

early_initcall

[Ashlesha Shintre]

Hi,

I m using the 2.6.14.6 tree and trying to get the kernel running on the
Encore M3 board.  

The kernel crashes during the boot process at the early_initcall.  This
function doesnt seem to be defined anywhere.  Which is the last version
of the 2.6 tree that still supports the early_initcall?

Thanks,
Ashlesha.

RE: early_initcall

[Kaz Kylheku]

 
> Ashlesha Shintre wrote:
> 
> Hi,
> 
> I m using the 2.6.14.6 tree and trying to get the kernel 
> running on the
> Encore M3 board.  
> 
> The kernel crashes during the boot process at the 
> early_initcall.

What is the exact output from the crash?

> This function doesnt seem to be defined anywhere.

It's not a function, but a macro. The macro is used to annotate a
function as being among the list of functions that are called at startup
by the "initcall" mechanism: a big loop that sweeps over a symbol table
of registered initialization functions and calls them. E.g.

  #include <linux/init.h>

  /* ... */

  int __init my_initialization_function(void)
  {
    printk(KERN_INFO "Hello, world\n");
  }

  early_initcall(my_initialization_function);

The __init tells the kernel build system that your function is not
needed after initialization and its memory can be thrown away. The
early_initcall arranges for the initialization call. Early means that
it's in the first group of functions.

If you suspect your kernel is dying during the calling of the initcall
functions, you can turn on initcall debugging. Add these parameters to
your kernel command line:

   debug debug_initcall

Hope this helps.

RE: early_initcall

[Kaz Kylheku]

 
> Ashlesha Shintre wrote:
> 
> Hi,
> 
> I m using the 2.6.14.6 tree and trying to get the kernel 
> running on the
> Encore M3 board.  
> 
> The kernel crashes during the boot process at the 
> early_initcall.

What is the exact output from the crash?

> This function doesnt seem to be defined anywhere.

It's not a function, but a macro. The macro is used to annotate a
function as being among the list of functions that are called at startup
by the "initcall" mechanism: a big loop that sweeps over a symbol table
of registered initialization functions and calls them. E.g.

  #include <linux/init.h>

  /* ... */

  int __init my_initialization_function(void)
  {
    printk(KERN_INFO "Hello, world\n");
  }

  early_initcall(my_initialization_function);

The __init tells the kernel build system that your function is not
needed after initialization and its memory can be thrown away. The
early_initcall arranges for the initialization call. Early means that
it's in the first group of functions.

If you suspect your kernel is dying during the calling of the initcall
functions, you can turn on initcall debugging. Add these parameters to
your kernel command line:

   debug debug_initcall

Hope this helps.

RE: early_initcall

[Ashlesha Shintre]

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


I googled early_initcall and found a patch which basically adds this
line to the /include/init.h file:

#define early_initcall(fn)             __define_initcall(".early1",fn)

I built a kernel image with this new line included and now if I try
executing it, the bootloader YAMON gives an exception error before it
can even begin!  Here is the dump:

************************* User Exception
**********************************
    Exception State 24  Machine check

(((((((((((((((((((( CPU Registers )))))))))))))))))))))))))))))
zr: 00000000  at: 10007c00  v0: 00000003  v1: 00000004
a0: 14000017  a1: 14080017  a2: 50000000  a3: 00000000
t0: 40000000  t1: 01ffe000  t2: 80400000  t3: 80410000
t4: 80400000  t5: fffffffe  t6: ffffffff  t7: 00000010
s0: 10007c00  s1: 80380000  s2: 80400000  s3: 80401c5c
s4: 80400000  s5: 803affc0  s6: 00000000  s7: 00000000
t8: 00000006  t9: 803afde6  k0: 00000000  k1: 00000000
gp: 803ae000  sp: 803aff10  s8: 800e8380  ra: 803f68c0

{{{{{{{{{{{{{{{{{{{{{ CP0 Registers }}}}}}}}}}}}}}}}}}}}}}}}}}}}}
   Index: 00000003        Random: 00000019    EntryLo0: 14000017
EntryLo1: 14080017       Context: 007ffff0   Page Mask: 00000000
Wired NO: 00000004         Reg 7: 00000000       Reg 8: fffffff4
   Reg 9: 4d691cb7      Entry Hi: 50000000      Reg 11: 00000000
  Reg 12: 10007c02        Reg 13: 00808060      Reg 14: 803f0484
Proc ID: 01030200      ERROREPC: 00000000      Config: 80008083
Config 1: 00000000      WatchLo: 00000000     WatchHi: 80000000
    Debug: 00008000         DEPC: 00000000


   STATUS: 10007c02
    CAUSE: 00808060
      EPC: 803f0484
BADVADDR: fffffff4
       LO: 04000000
       HI: 00000000


A machine check means that an exception is generated due to duplicate
TLB entries.  I dont understand why the kernel crashes so early.

Also, what does the ".early1" mean? Is that a definition of a different
segment in the init.h file?

I checked output of the "readelf -a vmlinux" and found that the address
for the early_initcall comes up about 5 times.  I m not sure what each
of the fields mean, so I have attached the above part of the readelf in
a file called readelf.

Thank you!
Ashlesha.



On Fri, 2006-09-01 at 17:50 -0700, Kaz Kylheku wrote:
>  > Ashlesha Shintre wrote:
> > 
> > Hi,
> > 
> > I m using the 2.6.14.6 tree and trying to get the kernel 
> > running on the
> > Encore M3 board.  
> > 
> > The kernel crashes during the boot process at the 
> > early_initcall.
> 
> What is the exact output from the crash?
> 
> > This function doesnt seem to be defined anywhere.
> 
> It's not a function, but a macro. The macro is used to annotate a
> function as being among the list of functions that are called at startup
> by the "initcall" mechanism: a big loop that sweeps over a symbol table
> of registered initialization functions and calls them. E.g.
> 
>   #include <linux/init.h>
> 
>   /* ... */
> 
>   int __init my_initialization_function(void)
>   {
>     printk(KERN_INFO "Hello, world\n");
>   }
> 
>   early_initcall(my_initialization_function);
> 
> The __init tells the kernel build system that your function is not
> needed after initialization and its memory can be thrown away. The
> early_initcall arranges for the initialization call. Early means that
> it's in the first group of functions.
> 
> If you suspect your kernel is dying during the calling of the initcall
> functions, you can turn on initcall debugging. Add these parameters to
> your kernel command line:
> 
>    debug debug_initcall
> 
> Hope this helps.
> 
> 

[-- Attachment #2: readelf.doc --]
[-- Type: application/msword, Size: 70144 bytes --]

Re: early_initcall

[Ralf Baechle]

On Wed, Sep 06, 2006 at 11:10:47AM -0700, Ashlesha Shintre wrote:

> I googled early_initcall and found a patch which basically adds this
> line to the /include/init.h file:
> 
> #define early_initcall(fn)             __define_initcall(".early1",fn)

There is more infrastructure needed to get this to work.  And in fact why
are you trying to get it to work at all - a direct call from setup_arch
to your early init function is trivial to do.

> I built a kernel image with this new line included and now if I try
> executing it, the bootloader YAMON gives an exception error before it
> can even begin!  Here is the dump:

Such a dump could be from YAMON or in the very early phase of the kernel
initialization.

> A machine check means that an exception is generated due to duplicate
> TLB entries.  I dont understand why the kernel crashes so early.

There are also other implementation specified reasons that may result
in a machine check exception as well.

> Also, what does the ".early1" mean? Is that a definition of a different
> segment in the init.h file?

Section not segment.  It's just a section name.

> I checked output of the "readelf -a vmlinux" and found that the address
> for the early_initcall comes up about 5 times.  I m not sure what each
> of the fields mean, so I have attached the above part of the readelf in
> a file called readelf.

And if you had not quoted 50 lines of the previous message in this thread
but those lines from the readelf output we might actually tell you.

  Ralf

Re: early_initcall

[Ashlesha Shintre]

Thank you for your email Ralf.  

The kernel now crashes inconsistently.  Firstly when I load the image in
YAMON and issue the go . command, it does not always give a machine
exception.  It seems to be stuck in the  do_fast_cp0_gettimeoffset
function, as the log buffer only contains this line recursively printed
from the printk statement inserted in the function as below: 

static unsigned long cached_quotient=0;
printk("INSIDE DO FAST CP0 GETTIMEOFFSET\n");
tmp = jiffies;


When I step through the dissassembly code, do_fast_cp0_gettimeoffset
function gets executed smoothly and the kernel crashed in the ways
listed below:

1) After the 3rd iteration of the  for (;;) loop in the
parse_cmdline_early file, a machine exception was generated.

-- If I step through the code in the for loop, all the 3 printk
statments that I have put get executed sequentially.  However if I only
introduce one break point at the first printk statement and run through
the loop, none of the statements are executed although control still
comes back to the break point! Also, none of the if conditions in the
for loop are ever satisfied.

2) In the same for loop -- between the 4th and 15th iteration the
breakpoint at  "c = *(from++);" is skipped and again the contents of the
logbuf are bizzarely overwritten by the one printk("INSIDE DO FAST CP0
GETTIMEOFFSET\n"); statement! -- This happened 3 times.

Any pointers?

Thank you,
Ashlesha.
  





On Thu, 2006-09-07 at 05:30 +0200, Ralf Baechle wrote: 
> On Wed, Sep 06, 2006 at 11:10:47AM -0700, Ashlesha Shintre wrote:
> 
> > I googled early_initcall and found a patch which basically adds this
> > line to the /include/init.h file:
> > 
> > #define early_initcall(fn)             __define_initcall(".early1",fn)
> 
> There is more infrastructure needed to get this to work.  And in fact why
> are you trying to get it to work at all - a direct call from setup_arch
> to your early init function is trivial to do.
> 
> > I built a kernel image with this new line included and now if I try
> > executing it, the bootloader YAMON gives an exception error before it
> > can even begin!  Here is the dump:
> 
> Such a dump could be from YAMON or in the very early phase of the kernel
> initialization.

> > A machine check means that an exception is generated due to duplicate
> > TLB entries.  I dont understand why the kernel crashes so early.
> 
> There are also other implementation specified reasons that may result
> in a machine check exception as well.
> 
> > Also, what does the ".early1" mean? Is that a definition of a different
> > segment in the init.h file?
> 
> Section not segment.  It's just a section name.
> 
> > I checked output of the "readelf -a vmlinux" and found that the address
> > for the early_initcall comes up about 5 times.  I m not sure what each
> > of the fields mean, so I have attached the above part of the readelf in
> > a file called readelf.
> 
> And if you had not quoted 50 lines of the previous message in this thread
> but those lines from the readelf output we might actually tell you.
> 
>   Ralf