Re: imx27 - hanging at freeing init memory -- getting some junk characters here after on console ..

On Fri, Nov 27, 2009 at 11:18 AM, Prabha J <[email protected]> wrote:

> Hi Martin,
> Are you getting any extra output (that you didn't have before patching
> the serial driver)?
> Before applying this patch i was getting Freeing init memory and after some
> time some junk characters.
>
I guess "some time" is ~ 60s?
Try compiling with CONFIG_PRINTK_TIME=y to get timestamps on your debug messages

> I applied your patch.
>
> With this i am getting error like this as before.
> <5>RAMDISK: Compressed image found at block 0
>
> VFS: Mounted root (ext2 filesystem).
> Freeing init memory: 128K
> <6>@HACK@ ignoring imx_setup_ufcr 0
> @HACK@ ignoring imx_setup_ufcr 0
> <3>BUG: soft lockup - CPU#0 stuck for 61s! [swapper:1]
> BUG: soft lockup - CPU#0 stuck for 61s! [swapper:1]
> Modules linked in:Modules linked in:
>

Do you also get this after a pause of about 60s?


>
>
> Pid: 1, comm:              swapper
> Pid: 1, comm:              swapper
> CPU: 0    Not tainted  (2.6.27 #19)
This is a bit old - do you get the same with 2.6.32-rcX?

Also it looks like you've added a printascii to printk.c ?  (doubled
lines - you can probably take it out now)


> [<c0078fa0>] [<c0078fa0>] (setup_irq+0x0/0x28c) (setup_irq+0x0/0x28c) from
> [<c00792f8>] from [<c00792f8>] (request_irq+0xcc/0xf8)
> (request_irq+0xcc/0xf8)
> [<c007922c>] [<c007922c>] (request_irq+0x0/0xf8) (request_irq+0x0/0xf8) from
> [<c0238c14>] from [<c0238c14>] (imx_startup+0xbc/0x188)
> (imx_startup+0xbc/0x188)
> [<c0238b58>] [<c0238b58>] (imx_startup+0x0/0x188) (imx_startup+0x0/0x188)
> from [<c02360c8>] from [<c02360c8>] (uart_startup+0x90/0x194)
> (uart_startup+0x90/0x194)
>  r5:c3ba3800 r5:c3ba3800 r4:00000000 r4:00000000
<snip>
> [<c0028414>] [<c0028414>] (init_post+0x0/0x104) (init_post+0x0/0x104) from
> [<c000893c>] from [<c000893c>] (kernel_init+0xb4/0xd8)
> (kernel_init+0xb4/0xd8)
>  r4:c044bcf8 r4:c044bcf8
>
> [<c0008888>] [<c0008888>] (kernel_init+0x0/0xd8) (kernel_init+0x0/0xd8) from
> [<c004ab48>] from [<c004ab48>] (do_exit+0x0/0x798)
> (do_exit+0x0/0x798)
>  r5:00000000 r5:00000000 r4:00000000 r4:00000000
>

The above shows that the kernel is hanging in setup_irq() called via
request_irq() from the serial driver when the kernel
tries to initialise the console.

I'm pretty sure that the problem was occuring with and without the patch.
Without the patch the UCR register was being written which causes the
baud rate to be wrong
until initialised by set_termios().
However set_termios() was never called (as evidenced by the lack of
the second log added by my patch)
because the thread blocked first.

Then 60s later the soft lockup detector triggers and prints gibberish
(since only UCR has been set)

With the patch the UCR is left at the bootloader initialsed value so
you see the real error.

Since the soft lockup detector triggers that indicates that the kernel
isn't completely dead - just one
thread hung.

So I don't think this is serial port related but something funny in
the interrupt initialisation.
Is this vanila 2.6.27 or do you have other patches on it?

There have been quite few changes to the interrupt code since 2.6.27
your best bet is to try to
reproduce with a recent kernel. Otherwise look what setup_irq() does
on your kernel and see where
it could block - maybe sprinkle a few printk()s there...

Good luck,

Martin