Timing problem on mem_fpage_unmap() in the fiasco kernel

[Adam Lackorzynski]

Hi,

On Wed Nov 15, 2006 at 20:53:45 +0900, WanKeun Jo wrote:
> I've been working on porting DROPS to Bulverde board - PXA270. My
> senior already made DROPS work on OMAP board before. He worked with
> L4Linux-2.6.16, but I don't know exact version of fiasco kernel and
> L4Env packages because they are not specified.
> 
> 
> I got all the sources from my senior - not the latest things.. - and
> have tried them work on Bulverde board.
> 
> 
> My status is that I have an unsolvable error in fiasco kernel.
> 
> 
> 
> On L4Linux-2.6.16's booting process, one step is "Freeing INITRD", and
> system halted on that point.
> 
> By tracing codes, I got to know while the mem_fpage_unmap() function
> in l4/kernel/fiasco/src/kern/map_util.cpp executed, the system halted.
> 
> And I put "delay codes" into that function's for() {}, and then the
> system continued to execute and boot succeed. I found this fact after
> I added printf() into that code in order to debug.
> 
> On that point - "Freeing INITRD", whether the boot process goes next
> step or not depends on how much delay time is put on that code,
> mem_fpage_unmap(). If I make the delay time a little bit longer, then
> the system goes to next step at that point, but stops somewhere else
> after that.  If I make the delay time too short, the system never go
> to next step.
> 
> 
> And the mem_fpage_unmap() is called a lot while the system works, but
> only in the "Freeing INITRD" part, the problem appears.
> 
> 
> 
> I think this is a serious timing error, but I can't know what the
> problem is. I already tried all the combinations of kernel and L4Linux
> options before.
> 
> when I tried to install the latest kernel and l4linux-2.6.18, the
> halting problem didn't appear. And I found that the latest kernel's
> mem_fpage_unmap() functions implementation has a lot of changes
> compared to the kernel I work with.
> 
> 
> Could you help me solve this problem??
> 
> Please don't say to me "use the latest one".. My senior already
> succeed on OMAP board with the old versions.

I've never seen this problem personally, so it's hard for me to suggest
any sort of fix.
Except... well, use the latest source as they seem to work. Maybe we
actually fixed the problem with the changes in the kernel.
Where is the problem? Bringing your OMAP modifications to the kernel to
a recent state should not be a hassle as the modification done in
mainline should not overlap with your additions for OMAP. They should
both touch different areas.






Adam
-- 
Adam                 adam at os.inf.tu-dresden.de
  Lackorzynski         http://os.inf.tu-dresden.de/~adam/