Re: JFFS2 directory copy problem

[Cmmn Ml <cm...@ya...>]

Hi all,

I tried with turning off the CONFIG_SH_DSP option, but didn't solve the problem.

Further more to find out more about the problem, I did following hack and got some information which might be useful to identify where the real problem is.

( 1 ). I put a printk inside the "static irqreturn_t tmu_timer_interrupt(int irq, void *dummy)" function in arch/sh/kernel/timers/timer-tmu.c file like below.

...
...
        /*
         * Here we are in the timer irq handler. We just have irqs locally
         * disabled but we don't know if the timer_bh is running on the other
         * CPU. We need to avoid to SMP race with it. NOTE: we don' t need
         * the irq version of write_lock because as just said we have irq
         * locally disabled. -arca
         */

        printk("Cmmn\n");

        write_seqlock(&xtime_lock);

...
...

( 2 ). Replaced the /sbin/init with a statically linked executable which has only a while loop as below.

#include <stdio.h>

int main()
{
        while(1)
        {
                // do nothing
        }

        return 0;
}

( 3 ). Put printk messages at the end of the init_post() function in init/main.c file as below.

...
...
printk("Debug: calling /sbin/init\n");
run_init_process("/sbin/init");
printk("Debug: calling /etc/init\n");
...
...


I tested this with both 2.6.16.9 (with sh--stable--2.6.16--base-0 patch) and 2.6.21-rc7 (with sh: Solution Engine SH7705 board and CPU updates (http://git.kernel.org/?p=linux/kernel/git/lethal/sh-2.6.git;a=commit;h=5452d25e28f365938b36f3a972fe2a1bb69a4c3e) added by Nobuhiro Iwamatsu to the sh-2.6.git) kernels. As expected for 2.6.16.9 kernel I'm getting the printk message continuously for each timer interrupt, but for 2.6.20-rc7 kernel, after the run_init_process("/sbin/init") function is called, I'm not getting the printk messages from timer interrupt. In other words once it tries to start the sbin/init process, the kernel hangs itself and even timer interrupt is not handled. So this means that the kernel fails to start a user space process and puts it self to a not running state.

According to above observation, I doubt this may be due a problem in the area where the kernel tries to start a user space process. Can it be a possibility ? If any one can give me some thoughts, it will be a great help.

Thank you

Cmmn



Paul Mundt <le...@li...> wrote: On Sun, May 06, 2007 at 11:26:12PM -0700, Cmmn Ml wrote:
>    I was using 32KB cache option, but removing that option didn't solve
>    the problem. Following is the content of my configuration file (.config
>    file). If I have missed any thing here,  and if any one can show me the
>    correct path, that will be a great help.

[snip]
>    #
>    # Processor features
>    #
>    # CONFIG_CPU_LITTLE_ENDIAN is not set
>    CONFIG_CPU_BIG_ENDIAN=y
>    # CONFIG_SH_FPU_EMU is not set
>    CONFIG_SH_DSP=y

Try turning off CONFIG_SH_DSP?


 
---------------------------------
Never miss an email again!
Yahoo! Toolbar alerts you the instant new Mail arrives. Check it out.