On Mon, 2009-03-30 at 14:24 +0200, Matthias Kaehlcke wrote: > linux-next 20090330 causes the following page fault on an edb9302 > (ARM) like board: > > # Unable to handle kernel paging request at virtual address 00535447 > pgd = c56b0000 > [00535447] *pgd=00000000 > Internal error: Oops: 3 [#1] PREEMPT > Modules linked in: > CPU: 0 Not tainted (2.6.29-next-20090330 #6) > PC is at kmemleak_scan+0x158/0x3ac > LR is at find_and_get_object+0xe0/0x104 > pc : [<c00aa5cc>] lr : [<c00a99d8>] psr: 00000013 > sp : c55bff78 ip : c55bff28 fp : c55bffa4 > r10: c0322718 r9 : c035fa6c r8 : c035f048 > r7 : c035f044 r6 : 00005800 r5 : 00004981 r4 : 00093020 > r3 : 00535443 r2 : 414f4c5f r1 : 00000001 r0 : c0400020 > Flags: nzcv IRQs on FIQs on Mode SVC_32 ISA ARM Segment kernel > Control: 0000717f Table: 0567c000 DAC: 00000017 > Process kmemleak (pid: 343, stack limit = 0xc55be268) [...] > the fault is reproducible and happens some seconds after having > finished the boot process. please tell me if you need more information > (like the .config, ...) in order to track this down Yes, the .config would be useful. I'm mainly interested in which slab allocator you are using. I'm testing kmemleak mainly on ARM and haven't seen any issues. Thanks. -- Catalin -- To unsubscribe from this list: send the line "unsubscribe linux-next" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
