Re: How to analyze kernel Oops dump

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Tue, Feb 05, 2013 at 06:57:29PM +0530, Manavendra Nath Manav wrote:
> I am running Linux 3.4.0 on embedded ARM target and getting following
> Oops every-time. I am not able to pin-point the reason for crash and
> which driver module triggered it. How can I decode the values in the
> registers at the time of crash. It's showing all in hex.
> 

It has the call tree as well.

> [  492.713897] ------------[ cut here ]------------
> [  492.718841] WARNING: at mm/slub.c:3415 ksize+0x70/0xc4()
> [  492.725311] ---[ end trace 90a5ae2bdb3ab657 ]---
> [  492.915618] ------------[ cut here ]------------
> [  492.920593] WARNING: at mm/slub.c:3415 ksize+0x70/0xc4()
> [  492.927032] ---[ end trace 90a5ae2bdb3ab658 ]---
> [  493.113464] Unable to handle kernel paging request at virtual

[ snip ]

> [  494.068664] Backtrace:
> [  494.071289] [<80109434>] (__kmalloc_track_caller+0x0/0x1ec) from
> [<80335ec0>] (__alloc_skb+0x60/0xfc)
> [  494.081085] [<80335e60>] (__alloc_skb+0x0/0xfc) from [<80336530>]
> (__netdev_alloc_skb+0x2c/0x54)
> [  494.090423] [<80336504>] (__netdev_alloc_skb+0x0/0x54) from
> [<7f078788>] (stmmac_poll+0x590/0x794 [stmmac])
> [  494.100738]  r4:ed0b84c0 r3:00000000
> [  494.104553] [<7f0781f8>] (stmmac_poll+0x0/0x794 [stmmac]) from
> [<8033f23c>] (net_rx_action+0x88/0x1f0)
> [  494.114440] [<8033f1b4>] (net_rx_action+0x0/0x1f0) from
> [<80045fb4>] (__do_softirq+0x12c/0x260)


So it's the something in net/core/skbuff.c

   186          /* We do our best to align skb_shared_info on a separate cache
   187           * line. It usually works because kmalloc(X > SMP_CACHE_BYTES) gives
   188           * aligned memory blocks, unless SLUB/SLAB debug is enabled.
   189           * Both skb->head and skb_shared_info are cache line aligned.
   190           */
   191          size = SKB_DATA_ALIGN(size);
   192          size += SKB_DATA_ALIGN(sizeof(struct skb_shared_info));
   193          data = kmalloc_node_track_caller(size, gfp_mask, node);
   194          if (!data)
   195                  goto nodata;
   196          /* kmalloc(size) might give us more room than requested.
   197           * Put skb_shared_info exactly at the end of allocated zone,
   198           * to allow max possible filling before reallocation.
   199           */
   200          size = SKB_WITH_OVERHEAD(ksize(data));
                                         ^^^^^^^^^^
It doesn't like "data" for some reason.  It might be interesting to
know how big size is as well.

I have no idea though what the problem is though.

   201          prefetchw(data + size);

regards,
dan carpenter


_______________________________________________
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxx
http://driverdev.linuxdriverproject.org/mailman/listinfo/devel


[Index of Archives]     [Linux Driver Backports]     [DMA Engine]     [Linux GPIO]     [Linux SPI]     [Video for Linux]     [Linux USB Devel]     [Linux Coverity]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [Yosemite Backpacking]
  Powered by Linux