On Fri, 23 Jan 2009, Valentin Longchamp wrote:

Well no miracle is taking place (And I have checked, the kernel I am
running is the correct one according to the build date tag with uname).
For me the initcalls are:

c0019390 <__initcall_misc_init4>:
c0019394 <__initcall_ipu_init4>:
c0019398 <__initcall_proto_init4>:

(Not exactly the same addresses as before because I add some pr_debug
calls for debug). But none of them are called. And all of them are
subsys_initcall. Do I have to enable something in my configuration so
that these initcall actually get called ?

Let's say, this is the first time that I run into a situation when some 
initcalls do not get called, and I never bothered setting any special 
config variable for that, and it would surprise me a _lot_ if such a 
variable existed... What kernel version is this?

However, they all have the same "look" so to say: no real ARM assembly
instruction but only addresses as Russel pointed it before:

quoted

c0019390 <__initcall_misc_init4>:
c0019390:       c001349c        .word   0xc001349c

c0019394 <__initcall_ipu_init4>:
c0019394:       c0014258        .word   0xc0014258

c0019398 <__initcall_proto_init4>:
c0019398:       c00143e4        .word   0xc00143e4

This may be the reason why these initcall are not actually called:
Guennadi's ones had a real ARM assembly instruction.

No, they are just addresses.

To solve all my
problems I need to understand why my subsys_initcall do not get called.

Good luck... Try the same with older kernels - even without ipu, just your 
regular kernel, maybe bisect since when your initcalls do not get called? 
Or compare to some running kernel's configuration...

Cheers
Guennadi
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer

------------------------------------------------------------------------------
This SF.net email is sponsored by:
SourcForge Community
SourceForge wants to tell your story.
http://p.sf.net/sfu/sf-spreadtheword