Re: [PATCH 2/4 v8] i.MX31: Image Processing Unit DMA and IRQ drivers

[Guennadi Liakhovetski <g.liakhovetski@gmx.de>]

On Fri, 23 Jan 2009, Russell King - ARM Linux wrote:

> On Fri, Jan 23, 2009 at 02:12:31PM +0100, Guennadi Liakhovetski wrote:
> > 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?
> 
> Well, the code which runs the initcalls steps through the array of
> function pointers built by the linker one word at a time.  So the
> only way an initcall could be missed in the middle of the array is
> if:
> 
> 1. the linker omitted the call (IOW buggy toolchain)
> 2. something corrupted kernel memory
> 
> I've personally never seen a situation where only some initcalls are
> called, but then I tend to hang on to known reliable toolchains.

The easiest for him is probably just put a printk in the loop in 
do_initcalls(), printing out function addresses.

Thanks
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