* analysis of kernel panic logs.
@ 2011-09-02 6:03 sandeep kumar
2011-09-02 7:26 ` Mulyadi Santosa
0 siblings, 1 reply; 10+ messages in thread
From: sandeep kumar @ 2011-09-02 6:03 UTC (permalink / raw)
To: kernelnewbies
Hi,
im working on android, kernel version 2.6.35.11
I got these logs showing kernel panic and the target is rebooting.
>From the logs i understood in init process something is causing kernel
panic.
<3>[ 85.235589] init: [boot time] processing action 0x4c5e8
(property:init.svc.samsungani=stopped)
<3>[ 85.236565] init: [boot time] processing action 0x4ef20
(property:init.svc.samsungani=stopped)
<0>[ 85.236840] Kernel panic - not syncing: Attempted to kill init!
<4>[ 85.236932] [<c01076b8>] (unwind_backtrace+0x0/0x164) from
[<c072436c>] (panic+0x6c/0xec)
<4>[ 85.237023] [<c072436c>] (panic+0x6c/0xec) from [<c01a931c>]
(do_exit+0x70/0x6a0)
<4>[ 85.237115] [<c01a931c>] (do_exit+0x70/0x6a0) from [<c01a99dc>]
(do_group_exit+0x90/0xc0)
<4>[ 85.237176] [<c01a99dc>] (do_group_exit+0x90/0xc0) from [<c01b8fc4>]
(get_signal_to_deliver+0x3e0/0x424)
<4>[ 85.237267] [<c01b8fc4>] (get_signal_to_deliver+0x3e0/0x424) from
[<c01039d8>] (do_signal+0x68/0x640)
<4>[ 85.237359] [<c01039d8>] (do_signal+0x68/0x640) from [<c0103fc8>]
(do_notify_resume+0x18/0x38)
<4>[ 85.237450] [<c0103fc8>] (do_notify_resume+0x18/0x38) from
[<c0100bd0>] (work_pending+0x1c/0x20)
<0>[ 85.237542] Rebooting in 5 seconds..
<2>[ 85.237572] CPU0: stopping
<4>[ 85.237603] [<c01076b8>] (unwind_backtrace+0x0/0x164) from
[<c0100338>] (do_IPI+0xd8/0x154)
<4>[ 85.237695] [<c0100338>] (do_IPI+0xd8/0x154) from [<c0728188>]
(__irq_usr+0x48/0xe0)
<4>[ 85.237756] Exception stack(0xdc18dfb0 to 0xdc18dff8)
<4>[ 85.237817] dfa0: 00000000
0000007c 00000000 4097b240
<4>[ 85.237878] dfc0: 45957cfe 4ba95bd8 4fc24a48 000000f4 80118200
ffffe9f4 00000000 801a6374
<4>[ 85.237939] dfe0: 000000f4 4fc249f8 8011d0a8 8011bf18 20000010
ffffffff
But how to interpret the Exception stack, dfa0 etc., to narrow down what
exactly caused the panic.
And in similer cases when oops happens also we will get the register dump, i
know how to interpret PC, but what about the rest of the registers.
how they are useful in analysing the situation.
--
With regards,
Sandeep Kumar Anantapalli,
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20110902/fba32c07/attachment.html
^ permalink raw reply [flat|nested] 10+ messages in thread* analysis of kernel panic logs. 2011-09-02 6:03 analysis of kernel panic logs sandeep kumar @ 2011-09-02 7:26 ` Mulyadi Santosa 2011-09-02 11:11 ` sandeep kumar 0 siblings, 1 reply; 10+ messages in thread From: Mulyadi Santosa @ 2011-09-02 7:26 UTC (permalink / raw) To: kernelnewbies Hi :) On Fri, Sep 2, 2011 at 13:03, sandeep kumar <coolsandyforyou@gmail.com> wrote: > Hi, > > im working on android, kernel version 2.6.35.11 Briefly checking the dump, looks like it's ARM processor? > I got these logs showing kernel panic and the target is rebooting. > > From the logs i understood in init process something is causing kernel > panic. .....[cut].... > [<c01039d8>] (do_signal+0x68/0x640) > <4>[?? 85.237359] [<c01039d8>] (do_signal+0x68/0x640) from [<c0103fc8>] > (do_notify_resume+0x18/0x38) > <4>[?? 85.237450] [<c0103fc8>] (do_notify_resume+0x18/0x38) from > [<c0100bd0>] (work_pending+0x1c/0x20) with the asumption that Android kernel is just another version of Linux kernel, I think this backtrace shows us that something is wrong with one (or more) work queue (or thread worker? something like that) you or somebody else has made. So, do you recally creating one? > <0>[?? 85.237542] Rebooting in 5 seconds.. > <2>[?? 85.237572] CPU0: stopping > <4>[?? 85.237603] [<c01076b8>] (unwind_backtrace+0x0/0x164) from > [<c0100338>] (do_IPI+0xd8/0x154) > <4>[?? 85.237695] [<c0100338>] (do_IPI+0xd8/0x154) from [<c0728188>] > (__irq_usr+0x48/0xe0) So, rebooting fails? looks like something is clobbering the kernel stack way too much IMHO... > <4>[?? 85.237756] Exception stack(0xdc18dfb0 to 0xdc18dff8) > <4>[?? 85.237817] dfa0:???????????????????????????????????? 00000000 > 0000007c 00000000 4097b240 > <4>[?? 85.237878] dfc0: 45957cfe 4ba95bd8 4fc24a48 000000f4 80118200 > ffffe9f4 00000000 801a6374 > <4>[?? 85.237939] dfe0: 000000f4 4fc249f8 8011d0a8 8011bf18 20000010 > ffffffff I am not familiar with those register names, sorry... -- regards, Mulyadi Santosa Freelance Linux trainer and consultant blog: the-hydra.blogspot.com training: mulyaditraining.blogspot.com ^ permalink raw reply [flat|nested] 10+ messages in thread
* analysis of kernel panic logs. 2011-09-02 7:26 ` Mulyadi Santosa @ 2011-09-02 11:11 ` sandeep kumar 2011-09-02 13:12 ` keshav yadav 2011-09-02 15:13 ` Dave Hylands 0 siblings, 2 replies; 10+ messages in thread From: sandeep kumar @ 2011-09-02 11:11 UTC (permalink / raw) To: kernelnewbies 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 <4>[ 89.664293] sp : bebb5e70 ip : ffffff88 fp : 00000000 <4>[ 89.664324] r10: 0003777c r9 : 00000001 r8 : 00000001 <4>[ 89.664355] r7 : 0003777c r6 : bebb5e94 r5 : 00000000 r4 : 0003777c <4>[ 89.664385] r3 : 00000000 r2 : 0004ef40 r1 : 0004ef50 r0 : 00000033 <4>[ 89.664446] Flags: nZCv IRQs on FIQs on Mode USER_32 ISA ARM Segment user <4>[ 89.664477] Control: 10c57c7d Table: 5e77006a DAC: 00000015 <0>[ 89.664660] Kernel panic - not syncing: Attempted to kill init! <4>[ 89.664721] [<c01076b8>] (unwind_backtrace+0x0/0x164) from [<c072436c>] (panic+0x6c/0xec) <4>[ 89.664782] [<c072436c>] (panic+0x6c/0xec) from [<c01a931c>] (do_exit+0x70/0x6a0) <4>[ 89.664812] [<c01a931c>] (do_exit+0x70/0x6a0) from [<c01a99dc>] (do_group_exit+0x90/0xc0) <4>[ 89.664873] [<c01a99dc>] (do_group_exit+0x90/0xc0) from [<c01b8fc4>] (get_signal_to_deliver+0x3e0/0x424) <4>[ 89.664934] [<c01b8fc4>] (get_signal_to_deliver+0x3e0/0x424) from [<c01039d8>] (do_signal+0x68/0x640) <4>[ 89.664995] [<c01039d8>] (do_signal+0x68/0x640) from [<c0103fc8>] (do_notify_resume+0x18/0x38) <4>[ 89.665056] [<c0103fc8>] (do_notify_resume+0x18/0x38) from [<c0100bd0>] (work_pending+0x1c/0x20) <2>[ 89.665117] CPU0: stopping <0>[ 89.665117] Rebooting in 5 seconds..[<c01076b8>] (unwind_backtrace+0x0/0x164) from [<c0100334>] (do_IPI+0xd8/0x154) <4>[ 89.665178] [<c0100334>] (do_IPI+0xd8/0x154) from [<c0727f4c>] (__irq_svc+0x4c/0xe4) <4>[ 89.665240] Exception stack(0xdc02fd90 to 0xdc02fdd8) <4>[ 89.665270] fd80: c1bd34a0 ffffffff c1bd34a8 40100068 <4>[ 89.665301] fda0: c1bd34a0 dcd060b0 00000008 761945df c1bd34a0 ddd5ac90 00000001 77fa555f <4>[ 89.665362] fdc0: 00000001 dc02fdd8 c0221558 c0213e68 20000113 ffffffff <4>[ 89.665423] [<c0727f4c>] (__irq_svc+0x4c/0xe4) from [<c0213e68>] (put_page+0xc/0x120) <4>[ 89.665453] [<c0213e68>] (put_page+0xc/0x120) from [<c0221558>] (do_wp_page+0x5fc/0x6f4) <4>[ 89.665514] [<c0221558>] (do_wp_page+0x5fc/0x6f4) from [<c0221fe0>] (handle_mm_fault+0x66c/0x718) <4>[ 89.665575] [<c0221fe0>] (handle_mm_fault+0x66c/0x718) from [<c0729e40>] (do_page_fault+0x190/0x35c) <4>[ 89.665636] [<c0729e40>] (do_page_fault+0x190/0x35c) from [<c01004f8>] (do_DataAbort+0x34/0x94) <4>[ 89.665667] [<c01004f8>] (do_DataAbort+0x34/0x94) from [<c07283e0>] (ret_from_exception+0x0/0x10) <4>[ 89.665728] Exception stack(0xdc02ffb0 to 0xdc02fff8) <4>[ 89.665758] ffa0: 00000001 40548448 00000000 4576c008 <4>[ 89.665789] ffc0: 00015a36 00052378 40548448 40548448 00000003 801a6610 80198a08 8018abbf <4>[ 89.665850] ffe0: 801a6828 beb0c340 80151525 8016d202 00000030 ffffffff <3>[ 94.671801] set_dload_mode <0> ( c0171bf8 ) <5>[ 94.671862] Going down for restart now On Fri, Sep 2, 2011 at 12:56 PM, Mulyadi Santosa <mulyadi.santosa@gmail.com>wrote: > Hi :) > > On Fri, Sep 2, 2011 at 13:03, sandeep kumar <coolsandyforyou@gmail.com> > wrote: > > Hi, > > > > im working on android, kernel version 2.6.35.11 > > Briefly checking the dump, looks like it's ARM processor? > > > I got these logs showing kernel panic and the target is rebooting. > > > > From the logs i understood in init process something is causing kernel > > panic. > .....[cut].... > > [<c01039d8>] (do_signal+0x68/0x640) > > <4>[ 85.237359] [<c01039d8>] (do_signal+0x68/0x640) from [<c0103fc8>] > > (do_notify_resume+0x18/0x38) > > <4>[ 85.237450] [<c0103fc8>] (do_notify_resume+0x18/0x38) from > > [<c0100bd0>] (work_pending+0x1c/0x20) > > with the asumption that Android kernel is just another version of > Linux kernel, I think this backtrace shows us that something is wrong > with one (or more) work queue (or thread worker? something like that) > you or somebody else has made. > > So, do you recally creating one? > > > <0>[ 85.237542] Rebooting in 5 seconds.. > > <2>[ 85.237572] CPU0: stopping > > <4>[ 85.237603] [<c01076b8>] (unwind_backtrace+0x0/0x164) from > > [<c0100338>] (do_IPI+0xd8/0x154) > > <4>[ 85.237695] [<c0100338>] (do_IPI+0xd8/0x154) from [<c0728188>] > > (__irq_usr+0x48/0xe0) > > So, rebooting fails? looks like something is clobbering the kernel > stack way too much IMHO... > > > <4>[ 85.237756] Exception stack(0xdc18dfb0 to 0xdc18dff8) > > <4>[ 85.237817] dfa0: 00000000 > > 0000007c 00000000 4097b240 > > <4>[ 85.237878] dfc0: 45957cfe 4ba95bd8 4fc24a48 000000f4 80118200 > > ffffe9f4 00000000 801a6374 > > <4>[ 85.237939] dfe0: 000000f4 4fc249f8 8011d0a8 8011bf18 20000010 > > ffffffff > > I am not familiar with those register names, sorry... > > -- > regards, > > Mulyadi Santosa > Freelance Linux trainer and consultant > > blog: the-hydra.blogspot.com > training: mulyaditraining.blogspot.com > -- With regards, Sandeep Kumar Anantapalli, -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20110902/439d1f5f/attachment.html ^ permalink raw reply [flat|nested] 10+ messages in thread
* analysis of kernel panic logs. 2011-09-02 11:11 ` sandeep kumar @ 2011-09-02 13:12 ` keshav yadav 2011-09-02 15:13 ` Dave Hylands 1 sibling, 0 replies; 10+ messages in thread From: keshav yadav @ 2011-09-02 13:12 UTC (permalink / raw) To: kernelnewbies Hi Sandeep, pls check 0xc92f which function is at this address ? On Fri, Sep 2, 2011 at 4:41 PM, sandeep kumar <coolsandyforyou@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 > <4>[?? 89.664293] sp : bebb5e70? ip : ffffff88? fp : 00000000 > <4>[?? 89.664324] r10: 0003777c? r9 : 00000001? r8 : 00000001 > <4>[?? 89.664355] r7 : 0003777c? r6 : bebb5e94? r5 : 00000000? r4 : 0003777c > <4>[?? 89.664385] r3 : 00000000? r2 : 0004ef40? r1 : 0004ef50? r0 : 00000033 > <4>[?? 89.664446] Flags: nZCv? IRQs on? FIQs on? Mode USER_32? ISA ARM > Segment user > <4>[?? 89.664477] Control: 10c57c7d? Table: 5e77006a? DAC: 00000015 > <0>[?? 89.664660] Kernel panic - not syncing: Attempted to kill init! > <4>[?? 89.664721] [<c01076b8>] (unwind_backtrace+0x0/0x164) from > [<c072436c>] (panic+0x6c/0xec) > <4>[?? 89.664782] [<c072436c>] (panic+0x6c/0xec) from [<c01a931c>] > (do_exit+0x70/0x6a0) > <4>[?? 89.664812] [<c01a931c>] (do_exit+0x70/0x6a0) from [<c01a99dc>] > (do_group_exit+0x90/0xc0) > <4>[?? 89.664873] [<c01a99dc>] (do_group_exit+0x90/0xc0) from [<c01b8fc4>] > (get_signal_to_deliver+0x3e0/0x424) > <4>[?? 89.664934] [<c01b8fc4>] (get_signal_to_deliver+0x3e0/0x424) from > [<c01039d8>] (do_signal+0x68/0x640) > <4>[?? 89.664995] [<c01039d8>] (do_signal+0x68/0x640) from [<c0103fc8>] > (do_notify_resume+0x18/0x38) > <4>[?? 89.665056] [<c0103fc8>] (do_notify_resume+0x18/0x38) from > [<c0100bd0>] (work_pending+0x1c/0x20) > <2>[?? 89.665117] CPU0: stopping > <0>[?? 89.665117] Rebooting in 5 seconds..[<c01076b8>] > (unwind_backtrace+0x0/0x164) from [<c0100334>] (do_IPI+0xd8/0x154) > <4>[?? 89.665178] [<c0100334>] (do_IPI+0xd8/0x154) from [<c0727f4c>] > (__irq_svc+0x4c/0xe4) > <4>[?? 89.665240] Exception stack(0xdc02fd90 to 0xdc02fdd8) > <4>[?? 89.665270] fd80:???????????????????????????????????? c1bd34a0 > ffffffff c1bd34a8 40100068 > <4>[?? 89.665301] fda0: c1bd34a0 dcd060b0 00000008 761945df c1bd34a0 > ddd5ac90 00000001 77fa555f > <4>[?? 89.665362] fdc0: 00000001 dc02fdd8 c0221558 c0213e68 20000113 > ffffffff > <4>[?? 89.665423] [<c0727f4c>] (__irq_svc+0x4c/0xe4) from [<c0213e68>] > (put_page+0xc/0x120) > <4>[?? 89.665453] [<c0213e68>] (put_page+0xc/0x120) from [<c0221558>] > (do_wp_page+0x5fc/0x6f4) > <4>[?? 89.665514] [<c0221558>] (do_wp_page+0x5fc/0x6f4) from [<c0221fe0>] > (handle_mm_fault+0x66c/0x718) > <4>[?? 89.665575] [<c0221fe0>] (handle_mm_fault+0x66c/0x718) from > [<c0729e40>] (do_page_fault+0x190/0x35c) > <4>[?? 89.665636] [<c0729e40>] (do_page_fault+0x190/0x35c) from [<c01004f8>] > (do_DataAbort+0x34/0x94) > <4>[?? 89.665667] [<c01004f8>] (do_DataAbort+0x34/0x94) from [<c07283e0>] > (ret_from_exception+0x0/0x10) > <4>[?? 89.665728] Exception stack(0xdc02ffb0 to 0xdc02fff8) > <4>[?? 89.665758] ffa0:???????????????????????????????????? 00000001 > 40548448 00000000 4576c008 > <4>[?? 89.665789] ffc0: 00015a36 00052378 40548448 40548448 00000003 > 801a6610 80198a08 8018abbf > <4>[?? 89.665850] ffe0: 801a6828 beb0c340 80151525 8016d202 00000030 > ffffffff > <3>[?? 94.671801] set_dload_mode <0> ( c0171bf8 ) > <5>[?? 94.671862] Going down for restart now > > On Fri, Sep 2, 2011 at 12:56 PM, Mulyadi Santosa <mulyadi.santosa@gmail.com> > wrote: >> >> Hi :) >> >> On Fri, Sep 2, 2011 at 13:03, sandeep kumar <coolsandyforyou@gmail.com> >> wrote: >> > Hi, >> > >> > im working on android, kernel version 2.6.35.11 >> >> Briefly checking the dump, looks like it's ARM processor? >> >> > I got these logs showing kernel panic and the target is rebooting. >> > >> > From the logs i understood in init process something is causing kernel >> > panic. >> .....[cut].... >> > [<c01039d8>] (do_signal+0x68/0x640) >> > <4>[?? 85.237359] [<c01039d8>] (do_signal+0x68/0x640) from [<c0103fc8>] >> > (do_notify_resume+0x18/0x38) >> > <4>[?? 85.237450] [<c0103fc8>] (do_notify_resume+0x18/0x38) from >> > [<c0100bd0>] (work_pending+0x1c/0x20) >> >> with the asumption that Android kernel is just another version of >> Linux kernel, I think this backtrace shows us that something is wrong >> with one (or more) work queue (or thread worker? something like that) >> you or somebody else has made. >> >> So, do you recally creating one? >> >> > <0>[?? 85.237542] Rebooting in 5 seconds.. >> > <2>[?? 85.237572] CPU0: stopping >> > <4>[?? 85.237603] [<c01076b8>] (unwind_backtrace+0x0/0x164) from >> > [<c0100338>] (do_IPI+0xd8/0x154) >> > <4>[?? 85.237695] [<c0100338>] (do_IPI+0xd8/0x154) from [<c0728188>] >> > (__irq_usr+0x48/0xe0) >> >> So, rebooting fails? looks like something is clobbering the kernel >> stack way too much IMHO... >> >> > <4>[?? 85.237756] Exception stack(0xdc18dfb0 to 0xdc18dff8) >> > <4>[?? 85.237817] dfa0:???????????????????????????????????? 00000000 >> > 0000007c 00000000 4097b240 >> > <4>[?? 85.237878] dfc0: 45957cfe 4ba95bd8 4fc24a48 000000f4 80118200 >> > ffffe9f4 00000000 801a6374 >> > <4>[?? 85.237939] dfe0: 000000f4 4fc249f8 8011d0a8 8011bf18 20000010 >> > ffffffff >> >> I am not familiar with those register names, sorry... >> >> -- >> regards, >> >> Mulyadi Santosa >> Freelance Linux trainer and consultant >> >> blog: the-hydra.blogspot.com >> training: mulyaditraining.blogspot.com > > > > -- > With regards, > Sandeep Kumar Anantapalli, > > > _______________________________________________ > Kernelnewbies mailing list > Kernelnewbies at kernelnewbies.org > http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies > > ^ permalink raw reply [flat|nested] 10+ messages in thread
* analysis of kernel panic logs. 2011-09-02 11:11 ` sandeep kumar 2011-09-02 13:12 ` keshav yadav @ 2011-09-02 15:13 ` Dave Hylands 2011-09-05 5:51 ` sandeep kumar 1 sibling, 1 reply; 10+ messages in thread From: Dave Hylands @ 2011-09-02 15:13 UTC (permalink / raw) To: kernelnewbies Hi Sandeep, On Fri, Sep 2, 2011 at 4:11 AM, sandeep kumar <coolsandyforyou@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 ^ permalink raw reply [flat|nested] 10+ messages in thread
* analysis of kernel panic logs. 2011-09-02 15:13 ` Dave Hylands @ 2011-09-05 5:51 ` sandeep kumar 2011-09-05 7:56 ` Dave Hylands 0 siblings, 1 reply; 10+ messages in thread From: sandeep kumar @ 2011-09-05 5:51 UTC (permalink / raw) To: kernelnewbies Hi Dave, The problem is solved. But i have one doubt. >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 In this case we came to know the process name 'init'. But in some cases we might just have the link register address, and no process name. say some user-space process has caused the panic. Can u tell me ..how to debug in that case? Thank you so much.. Sandeep On Fri, Sep 2, 2011 at 8:43 PM, Dave Hylands <dhylands@gmail.com> wrote: > Hi Sandeep, > > On Fri, Sep 2, 2011 at 4:11 AM, sandeep kumar <coolsandyforyou@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 > -- With regards, Sandeep Kumar Anantapalli, -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20110905/846c4eeb/attachment.html ^ permalink raw reply [flat|nested] 10+ messages in thread
* analysis of kernel panic logs. 2011-09-05 5:51 ` sandeep kumar @ 2011-09-05 7:56 ` Dave Hylands 2011-09-05 8:37 ` sandeep kumar 0 siblings, 1 reply; 10+ messages in thread From: Dave Hylands @ 2011-09-05 7:56 UTC (permalink / raw) To: kernelnewbies Hi Sandeep, On Sun, Sep 4, 2011 at 10:51 PM, sandeep kumar <coolsandyforyou@gmail.com> wrote: > Hi Dave, > > The problem is solved. > But i have one doubt. > >>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 > > In this case we came to know the process name 'init'. But in some > cases we might just have the link register address, and no process name. > say some user-space process has caused the panic. > > Can u tell me ..how to debug in that case? You should always have a pid & process name if its a user-space app which dies (at least if you enable CONFIG_DEBUG_USER and enabling user_debug) -- Dave Hylands Shuswap, BC, Canada http://www.davehylands.com ^ permalink raw reply [flat|nested] 10+ messages in thread
* analysis of kernel panic logs. 2011-09-05 7:56 ` Dave Hylands @ 2011-09-05 8:37 ` sandeep kumar 2011-09-06 16:44 ` Dave Hylands 0 siblings, 1 reply; 10+ messages in thread From: sandeep kumar @ 2011-09-05 8:37 UTC (permalink / raw) To: kernelnewbies Hi Dave, I want to share what is the problem and how it got fixed. The problem goes like this, The init process(init.c) of ANDROID parses "init.rc" file which specifies the actions to be done on a specific trigger. In our case mistakenly we specified the trigger,but no action. Due to which the parser parsed the action to be NULL, and executed it when the trigger occured. Which caused the NULL dereferencing. We fixed that by doing a NULL check before calling the action. As our analysis for the problem goes, init being the critical process, when killed, platform called a system call to restart the kernel. is it correct or we missd something? I have the following questions also, 1) When we enabled that config option CONFIG_DEBUG_USER, the register dump we got, is of user space application, right? 2) init: unhandled page fault (11) at 0x00000000, code 0x80000007, this is given by the CONFIG_DEBUG_USER, any reference how to analyse the 'code' value? Thank you, Sandeep On Mon, Sep 5, 2011 at 1:26 PM, Dave Hylands <dhylands@gmail.com> wrote: > Hi Sandeep, > > On Sun, Sep 4, 2011 at 10:51 PM, sandeep kumar > <coolsandyforyou@gmail.com> wrote: > > Hi Dave, > > > > The problem is solved. > > But i have one doubt. > > > >>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 > > > > In this case we came to know the process name 'init'. But in some > > cases we might just have the link register address, and no process name. > > say some user-space process has caused the panic. > > > > Can u tell me ..how to debug in that case? > > You should always have a pid & process name if its a user-space app > which dies (at least if you enable CONFIG_DEBUG_USER and enabling > user_debug) > > -- > Dave Hylands > Shuswap, BC, Canada > http://www.davehylands.com > -- With regards, Sandeep Kumar Anantapalli, -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20110905/57f6ed75/attachment.html ^ permalink raw reply [flat|nested] 10+ messages in thread
* analysis of kernel panic logs. 2011-09-05 8:37 ` sandeep kumar @ 2011-09-06 16:44 ` Dave Hylands 2011-09-06 16:56 ` anish singh 0 siblings, 1 reply; 10+ messages in thread From: Dave Hylands @ 2011-09-06 16:44 UTC (permalink / raw) To: kernelnewbies Hi Sandeep, On Mon, Sep 5, 2011 at 1:37 AM, sandeep kumar <coolsandyforyou@gmail.com> wrote: ...snip... > As our?analysis for the problem goes, > init being the critical process, when killed, platform called a system call > to restart the kernel. > is it correct or we missd something? I'm not sure. What exactly do you mean by "platform"? > I have the following questions also, > > 1) When we enabled that config option CONFIG_DEBUG_USER, the register dump > we got, is of user space application, right? Yes - that was a register dump of the init process, which is a user-mode process. > 2) init: unhandled page fault (11) at 0x00000000, code 0x80000007, this is > given by the CONFIG_DEBUG_USER, any reference how to analyse the 'code' > value? You'd probably need to look this up in the ARM ARM. You'll need to know the correct chip number of the ARM processor you're using, so you can figure out which reference manual to use. The ARM ARM is either available at arm.com, or it may be available with ARM development tools. -- Dave Hylands Shuswap, BC, Canada http://www.davehylands.com ^ permalink raw reply [flat|nested] 10+ messages in thread
* analysis of kernel panic logs. 2011-09-06 16:44 ` Dave Hylands @ 2011-09-06 16:56 ` anish singh 0 siblings, 0 replies; 10+ messages in thread From: anish singh @ 2011-09-06 16:56 UTC (permalink / raw) To: kernelnewbies On Tue, Sep 6, 2011 at 10:14 PM, Dave Hylands <dhylands@gmail.com> wrote: > Hi Sandeep, > > On Mon, Sep 5, 2011 at 1:37 AM, sandeep kumar <coolsandyforyou@gmail.com> wrote: > ...snip... >> As our?analysis for the problem goes, >> init being the critical process, when killed, platform called a system call >> to restart the kernel. >> is it correct or we missd something? > > I'm not sure. What exactly do you mean by "platform"? Android guys would have known this but as we can understand this being silly questions doesn't deserve their attention and probably because they have a small team. Anyway platform here means user space.Where init process is running.Sandeep i guess you should see the code as to how they are handling the killing of the core process(critical) in user space. > >> I have the following questions also, >> >> 1) When we enabled that config option CONFIG_DEBUG_USER, the register dump >> we got, is of user space application, right? > > Yes - that was a register dump of the init process, which is a > user-mode process. > >> 2) init: unhandled page fault (11) at 0x00000000, code 0x80000007, this is >> given by the CONFIG_DEBUG_USER, any reference how to analyse the 'code' >> value? > > You'd probably need to look this up in the ARM ARM. You'll need to > know the correct chip number of the ARM processor you're using, so you > can figure out which reference manual to use. The ARM ARM is either > available at arm.com, or it may be available with ARM development > tools. > > -- > Dave Hylands > Shuswap, BC, Canada > http://www.davehylands.com > > _______________________________________________ > Kernelnewbies mailing list > Kernelnewbies at kernelnewbies.org > http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies > ^ permalink raw reply [flat|nested] 10+ messages in thread
end of thread, other threads:[~2011-09-06 16:56 UTC | newest] Thread overview: 10+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2011-09-02 6:03 analysis of kernel panic logs sandeep kumar 2011-09-02 7:26 ` Mulyadi Santosa 2011-09-02 11:11 ` sandeep kumar 2011-09-02 13:12 ` keshav yadav 2011-09-02 15:13 ` Dave Hylands 2011-09-05 5:51 ` sandeep kumar 2011-09-05 7:56 ` Dave Hylands 2011-09-05 8:37 ` sandeep kumar 2011-09-06 16:44 ` Dave Hylands 2011-09-06 16:56 ` anish singh
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.