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
[email protected]
http://driverdev.linuxdriverproject.org/mailman/listinfo/devel