Kernel Crash in local_bh_enable In case of VLAN Tagged ICMP packets

[Gautam Acharya]

Hi Friends,

Linux Version Used Customized Windriver Linux based on main line Linux 2.6.27.18 on mips arch based cavium octeon board .

Getting Kernel Crash in local_bh_enable In case of VLAN Tagged ICMP packets

Kindly help me analyzing the stack trace and finding the issue.
Please find below Kernel Crash Stack trace :

[<ffffffff81154108>] warn_on_slowpath+0x58/0x90

[<ffffffff8115bd20>] local_bh_enable+0x88/0xf8

[<ffffffff81344a44>] dev_queue_xmit+0x144/0x688

[<ffffffff81301f04>] bond_dev_queue_xmit+0x44/0x178

[<ffffffff81302408>] bond_xmit_activebackup+0xb0/0xe8

[<ffffffff81344ea4>] dev_queue_xmit+0x5a4/0x688

[<ffffffff813d59b4>] vlan_dev_hwaccel_hard_start_xmit+0x8c/0xa0

[<ffffffff81344ea4>] dev_queue_xmit+0x5a4/0x688

[<ffffffff81377cbc>] ip_push_pending_frames+0x37c/0x4c0

[<ffffffff813a0768>] icmp_reply+0x170/0x290

[<ffffffff813a0a58>] icmp_echo+0x58/0x68

[<ffffffff813a11b4>] icmp_rcv+0x334/0x390

[<ffffffff813721a4>] ip_local_deliver_finish+0x13c/0x2d8

[<ffffffff813718c4>] ip_rcv_finish+0x134/0x510

[<ffffffff81343af4>] netif_receive_skb+0x41c/0x5d8

[<ffffffff81343d58>] process_backlog+0xa8/0x160

[<ffffffff8134186c>] net_rx_action+0x194/0x2e8

[<ffffffff8115b71c>] __do_softirq+0x114/0x288

[<ffffffff8115b910>] do_softirq+0x80/0x98

[<ffffffff8115bb8c>] irq_exit+0x64/0x78

[<ffffffff81100e40>] plat_irq_dispatch+0xd0/0x1d0

[<ffffffff81120c80>] ret_from_irq+0x0/0x4

[<ffffffff81120ea0>] r4k_wait+0x20/0x40

[<ffffffff81123414>] cpu_idle+0x34/0x60


Regards,
Gautam

 

[ryanvade]

http://lkcd.sourceforge.net/

 

[Gautam Acharya]

http://lkcd.sourceforge.net/

Hi,
Thanx ryanvade
Kernel is running on an embedded system and it is reported from remote site. we don't have crash dump to analyze. Getting dump from there is also not feasible as of now. All we have this kernel stack trace of crash.

Needs Some inputs and pointers based on this stack trace.

Thanks in Advance

 

[flunwyc]

What you've posted is part of a call trace, you will not be able to solve this based on that alone. If you want to run such an old kernel, you will have to be prepared to debug it.