kernel crash and dabt_svc
Hi, I am debugging a kernel crash in arm platform [ 486.447220] [<c000de98>] (__dabt_svc+0x38/0x60) from [<bf05c324>] (ath6kl_deliver_frames_to_nw_stack+0xac/0xf0 [ath6kl_core]) Does dabt_svc is similar to 'EIP' ? ath6kl_deliver_frames_to_nw_stack+0xac points to the exact offset (over gdb) gives the line of crash ? crash log [ 486.447220] [<c000de98>] (__dabt_svc+0x38/0x60) from [<bf05c324>] (ath6kl_deliver_frames_to_nw_stack+0xac/0xf0 [ath6kl_core]) [ 486.458520] [<bf05c324>] (ath6kl_deliver_frames_to_nw_stack+0xac/0xf0 [ath6kl_core]) from [<bf04a184>] (do_recv_completion+0x3c/0x60 [ath6kl_core]) [ 486.471692] [<bf04a184>] (do_recv_completion+0x3c/0x60 [ath6kl_core]) from [<bf04bac0>] (ath6kl_htc_pipe_rx_complete+0x5e0/0x670 [ath6kl_core]) [ 486.484563] [<bf04bac0>] (ath6kl_htc_pipe_rx_complete+0x5e0/0x670 [ath6kl_core]) from [<bf063f2c>] (ath6kl_core_rx_complete+0x10/0x14 [ath6kl_core]) [ 486.497816] [<bf063f2c>] (ath6kl_core_rx_complete+0x10/0x14 [ath6kl_core]) from [<bf08afd4>] (ath6kl_usb_io_comp_work_rx+0x34/0x7c [ath6kl_usb]) [ 486.510691] [<bf08afd4>] ( thanks in advance. regards, shafi
On Thu, Jun 27, 2013 at 1:23 PM, Mohammed Shafi <shafi.kernel@gmail.com> wrote:
Hi,
I am debugging a kernel crash in arm platform
[ 486.447220] [<c000de98>] (__dabt_svc+0x38/0x60) from [<bf05c324>] (ath6kl_deliver_frames_to_nw_stack+0xac/0xf0 [ath6kl_core])
Does dabt_svc is similar to 'EIP' ?
kind of, but not exactly. It is a symbol name...could be a function/procedure etc, but certainly (in most cases I know of) not a macro/inlined function. If you find that name through grepping kernel source tree, you shall find the culprit. The next number "0x38/0x60" AFAIK is the offset that shall point you to more exact location -- regards, Mulyadi Santosa Freelance Linux trainer and consultant blog: the-hydra.blogspot.com training: mulyaditraining.blogspot.com
On Thu, 27 Jun 2013 18:29:48 +0700, Mulyadi Santosa said:
On Thu, Jun 27, 2013 at 1:23 PM, Mohammed Shafi <shafi.kernel@gmail.com> wrote:
[ 486.447220] [<c000de98>] (__dabt_svc+0x38/0x60) from [<bf05c324>]
If you find that name through grepping kernel source tree, you shall find the culprit. The next number "0x38/0x60" AFAIK is the offset that shall point you to more exact location
To be more specific, the function is 0x60 (decimal 96) bytes long, and the pointer is at 0x38 (decimal 56) bytes into it. So even without a disassembly, you know its somewhere between 1/2 and 2/3 of the way through the code.
On Thu, Jun 27, 2013 at 9:11 PM, <Valdis.Kletnieks@vt.edu> wrote:
On Thu, 27 Jun 2013 18:29:48 +0700, Mulyadi Santosa said:
On Thu, Jun 27, 2013 at 1:23 PM, Mohammed Shafi <shafi.kernel@gmail.com> wrote:
[ 486.447220] [<c000de98>] (__dabt_svc+0x38/0x60) from [<bf05c324>]
If you find that name through grepping kernel source tree, you shall find the culprit. The next number "0x38/0x60" AFAIK is the offset that shall point you to more exact location
To be more specific, the function is 0x60 (decimal 96) bytes long, and the pointer is at 0x38 (decimal 56) bytes into it. So even without a disassembly, you know its somewhere between 1/2 and 2/3 of the way through the code.
thanks Prasad, Mulyadi, Valdis (ath6kl_deliver_frames_to_nw_stack+0xac/0xf0 [ath6kl_core]) with the arm gdb, am able to find the exact line and based on the test engineers inputs, found the fix for crash. seems fuzzy testing sends a destination mac address as zero, while we initialize the list with mac address as zero, and memcmp returns a pointer, which inturn de-references to an uninitialized pointer. below is the fix :-) » if (is_zero_ether_addr(node_addr))66 » » return NULL;
participants (3)
-
Mohammed Shafi -
Mulyadi Santosa -
Valdis.Kletnieks＠vt.edu