analysis of kernel panic logs.

[Dave Hylands]

Hi Sandeep,

On Fri, Sep 2, 2011 at 4:11 AM, sandeep kumar <coolsandyforyou at gmail.com> wrote:
> Logs after enabling the CONFIG_DEBUG_USER and setting user_debug to 255, to
> get more info....(as suggested by Dave..)
>
> <3>[   89.663286] init: [boot time] processing action 0x4c5e8
> (property:init.svc.samsungani=stopped)
> <3>[   89.663988] init: [boot time] processing action 0x4ef20
> (property:init.svc.samsungani=stopped)
> <7>[   89.664049] init: unhandled page fault (11) at 0x00000000, code
> 0x80000007
> <1>[   89.664080] pgd = de370000
> <1>[   89.664110] [00000000] *pgd=5eb83031, *pte=00000000, *ppte=00000000
> <4>[   89.664141]
> <4>[   89.664171] Pid: 1, comm:                 init
> <4>[   89.664202] CPU: 1    Not tainted  (2.6.35.11 #4)
> <4>[   89.664232] PC is at 0x0
> <4>[   89.664232] LR is at 0xc92f
> <4>[   89.664263] pc : [<00000000>]    lr : [<0000c92f>]    psr: 60000010

So the PC is 0, and the LR is C92F. That tells me that the code at
C92F in your init process is trying to call a function through a NULL
pointer. You can try disassembling your init process. Something like

arm-eabi-objdump --disassemble init

You'll need to figure out which toolchain was used to compile the init
process. I'm jjust taking a guess that it was arm-eabi-gcc.

You may need to recompile with debug symbols or dig up the unstripped
executable from your build.

-- 
Dave Hylands
Shuswap, BC, Canada
http://www.davehylands.com