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