On Thu, 2013-03-14 at 11:15 +0000, Mark Jackson wrote: > [ 28.538525] [d08ea004] *pgd=8f045811, *pte=00000000, *ppte=00000000 > [ 28.545173] Internal error: Oops: 7 [#1] ARM > [ 28.549685] CPU: 0 Not tainted (3.8.0-next-20130225-00002-g678576f-dirty #40) > [ 28.557595] PC is at crc32_le+0x50/0x168 > [ 28.561735] LR is at ubi_eba_atomic_leb_change+0x1b4/0x410 > [ 28.567523] pc : [<c01e7244>] lr : [<c026dd9c>] psr: 20000013 > [ 28.567523] sp : cf385de0 ip : 180a985a fp : c054f840 > [ 28.579632] r10: c054f040 r9 : c054fc40 r8 : 158a1232 > [ 28.585141] r7 : 4d506705 r6 : 9324fd72 r5 : 4dc8a10b r4 : 4c162691 > [ 28.592025] r3 : c054e040 r2 : c054f440 r1 : d08ea000 r0 : 4c8ee09f > [ 28.598912] Flags: nzCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment user > [ 28.606439] Control: 10c5387d Table: 8f3b8019 DAC: 00000015 > [ 28.612501] Process mount (pid: 659, stack limit = 0xcf384238) > [ 28.618652] Stack: (0xcf385de0 to 0xcf386000) > [ 28.623254] 5de0: cf2f8554 00000000 d08e6e8c 180a9e88 5a257c4f 58399ee9 c8d98a08 bb0ee864 > [ 28.631886] 5e00: eae10678 c054fc40 c054f040 c054f840 cf2f8000 00000000 d08caffc 00003c00 > [ 28.640517] 5e20: cf2f8000 cf357c00 00000000 0000000c cf2ec000 00000000 0000000c cf2f8554 > [ 28.649148] 5e40: d08cb000 0001e000 00000000 d08cb000 00008000 00000000 00000000 0001e000 > [ 28.657779] 5e60: 00000000 0000000c d08cb000 00000080 0000000c 0000000c 00000000 00000020 > [ 28.666409] 5e80: 00008000 c026c41c 0001e000 cf330000 cf330000 d08cb000 0001e000 c0179b14 > [ 28.675042] 5ea0: 0000000d c0177a68 0001e000 cf330000 00000000 cf330b20 0000000d c0179698 > [ 28.683672] 5ec0: cf330000 00000000 cf330a9c 00000000 cf385f48 c0175170 00000001 60000013 > [ 28.692303] 5ee0: cf32c800 00000000 00000000 00000000 cf385f48 00000000 00000020 c00c9e24 > [ 28.700934] 5f00: 00100100 00200200 cf3a6c80 00008000 cf384000 00208020 00000000 cf01a200 > [ 28.709564] 5f20: cf32c800 c00e3d6c 00000000 0000000c cf32c840 00000000 c0013968 cf31fb80 > [ 28.718195] 5f40: 0000000c 00000000 cf01a210 ce828858 0000000c cf3ac000 000a18b4 00000000 > [ 28.726827] 5f60: 00208020 c0013968 cf384000 00000000 00000003 c00e3e40 00000000 c0071e24 > [ 28.735459] 5f80: 00000000 00000000 cf31fb80 cf31fbc0 a0000010 00000000 bed87b68 b6ff148c > [ 28.744091] 5fa0: 00000015 c00137c0 00000000 bed87b68 000a18b4 000a18c0 000a18c2 00208020 > [ 28.752720] 5fc0: 00000000 bed87b68 b6ff148c 00000015 00000000 00000000 00000000 00000003 > [ 28.761350] 5fe0: b6fa3f48 bed87a64 00042994 b6fa3f58 a0000010 000a18b4 00000000 00000000 > [ 28.769989] [<c01e7244>] (crc32_le+0x50/0x168) from [<cf2f8000>] (0xcf2f8000) > [ 28.777522] Code: e58d8008 0a000026 e1a0c005 e58d2004 (e5916004) > [ 28.784029] ---[ end trace f50f53afffe647f1 ]--- OK, this is an independent problem which, as I think, has nothing to do with the first one. I do not know why crc32 oopses on your system. You need to investigate this. I believe this is not UBI/UBIFS's fault. One theory could be that UBI uses vmalloc'ed buffers for the atomic update operation, and submits the buffer to the MTD layer for the I/O. If your NAND driver is trying to DMA this memory, you may be in trouble, because vmalloced memory is often not DMA-able on many systems, especially ARM systems which do not have coherent cache support. -- Best Regards, Artem Bityutskiy -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
